Staff IT

To be effective as a project manager, you need to control 4 elements: time, scope, cost, and quality. While some of my previous articles have showed you how to effectively size projects and control quality, we have not yet discussed how to properly staff a project in order to meet both your time-to-market objectives and budget constraints.

When staffing software projects, keep the following three rules in mind:

1. Adding more resources to a project does not allow you to indefinitely compress its schedule.
2. Once a project is sufficiently staffed, each additional resource will be less productive than the previous one.
3. The size of the project team should increase from the Description to the Construction phase, stabilize during Construction, and decrease from the Construction to the Verification phase.

Schedule Compression Factor

The Schedule Compression Factor (SCF) explains the degree to which a project schedule has been compressed. Its mathematical formula is:

SCF = S_C/S_N, where

S_C is the compressed schedule
S_N is the nominal schedule

Most researchers have concluded that it is impossible to have an SCF lower than 70% to 80%. In other words, no matter how many resources you add to a project, you will not compress its nominal schedule by more than 20% to 30%.

For example, if your project requires approximately 100 person-months of effort, and you divide the tasks among 7 developers, your nominal schedule would be approximately 14 months. You could potentially reduce that schedule to 10 or 11 months by adding more resources to the project, but no matter how many people you add, the schedule cannot be compressed to 9 months or less.

This can be explained by the law of diminishing return. Every project has a point beyond which each additional resource will be less productive than the previous one.

Figure 1. Schedule Compression Factor and the Law of Diminishing Return.

Naturally, as illustrated in the previous graph, the duration of the project will still be reduced if you keep adding resources, but the decline in duration is less significant with each additional person. As capacity increases, marginal production tends toward 0.

This law occurs for various reasons:

• As the project team increases, communication becomes harder and the individual team members need to attend more meetings in order to overcome this communication barrier.
• The system has to be fragmented in modules, which requires additional time to define and implement interfaces, and integrate the components.
• The additional staff requires more management overhead, which must be accounted for in the overall project cost.

Nominal Schedule

The point at which the law of diminishing return begins to operate is difficult to predict. The following rule of thumb should be used when estimating the location of this point, hence the nominal schedule of any project:

D = K * E ^1/3, where

D is the duration of the project
K is a constant (usually 3, but can range between 2 and 4)
E is the estimated effort for the entire project, in person-months.

For example, the project above was estimated to take 100 person-months to complete. According to the above formula, the time required to complete the release should be 14 months (D=3*100^1/3). Since the overall effort is estimated to take 100 person-months, you should staff your project with approximately 7 developers. Assigning less than 7 developers means you're not optimizing time to market. Assigning more than 7 means you're accelerating the schedule, but not cost-effectively. Each additional resource is relatively less productive than the previous one.

Staffing Profile

Another concept that you must get familiar with is the staffing profile. Projects should not have a static team size. People should be assigned to the project when they are needed, and taken off when they complete their tasks.

The staffing profile usually climbs from the Definition to Construction phase, plateaus for a while, and then drops a bit during the Verification phase as illustrated in the next figure.

Figure 2. Staffing Profile.

Generally speaking, only the more senior designers are involved during the Definition and Design phases of the project. And only once the project is designed should you involve junior and intermediate developers to actually write the software code. Getting junior staff to start implementing code before the system is properly designed is highly inefficient. If the design changes, their code will most likely become obsolete. Not only does this lead to an increased project cost, but also demotivates your team members.

During the Definition and Design phases, junior developers would be better utilized maintaining and fixing defects in previous releases. Once the Construction phase is over and Verification begins, the cycle should start again. The Product Managers, along with the senior designers, should define the next release or iteration and design it while your junior and intermediate developers fix software defects in order to bring the improve the quality of the current release.

We've already determined that the nominal schedule for the sample project described above requires, on average, 7 developers. If you want to adhere to that nominal schedule, you should assign your staff according to the following profile.

	Definition	Design	Construction	Verification
Senior Designers	3	5	5	2
Junior/Intermediate Designers	0	0	4	4

Table 1. Staffing Profile for Nominal Schedule.

In the event that you must compress the nominal development schedule, you should slightly increase the staff at each phase of the product lifecycle. For example, if your company determines that it’s strategically critical to gain a first-mover advantage even though the development cost will increase, you could change your staffing profile to look like the following.

	Definition	Design	Construction	Verification
Senior Designers	4	5	5	2
Junior/Intermediate Designers	0	2	6	6

Table 2. Staffing Profile for Compressed Schedule.

Keep in mind however that you cannot compress the schedule by more than 70% to 80%. Consequently, you should not increase the resources at any given phase by more than a third.

Conclusion

As time goes on, programming languages and development practices will improve. In 10 to 20 years from now, developers will certainly be able to develop software at a much faster pace than they are capable of today. Nevertheless, the following 3 principles will always be true:

1. Adding more resources to a project does not allow you to indefinitely compress its schedule.
2. Once a project is sufficiently staffed, each additional resource will be less productive than the previous one.
3. The size of the project team should increase from the Description to the Construction phase, stabilize during Construction, and decrease from the Construction to the Verification phase.

(1) Although these periods are referred to as “phases”, I do not recommend that your software development process follow a “phased” waterfall approach.

---

This article was originally published on www.gantthead.com.