20.6 Tradeoffs Between Schedule and Effort

Lawrence Putnam's estimation model provides some rules of thumb for schedule compression and expansion, listed in Table 20-4.

Table 20-4: Recommended Tradeoffs Between Effort and Schedule
Schedule Compression/Expansion	Effort Increase/Reduction
-15%	+100%
-10%	+50%
-5%	+25%
Nominal	0%
+10%	-30%
+20%	-50%
+30%	-65%
More than +30%	Not practical
Source: Adapted from data in Measures for Excellence (Putnam and Myers 1992).

Putnam cautions that extending the schedule more than about 30% is likely to begin introducing different kinds of inefficiencies, which in turn begin increasing costs.

Some people have criticized Putnam's model for exaggerating the effect of schedule compression and expansion, but the International Software Benchmarking Standards Group's 2005 data produces very similar results (ISBSG 2005).

Schedule Compression and Team Size

One of the pitfalls of attempting to compress a schedule below the nominal, even if you avoid the Impossible Zone, is that you might increase team size above the economically effective maximum. Lawrence Putnam has conducted fascinating research on the relationship between team size, schedule, and productivity for medium-sized business systems. Figure 20-3 shows his results (Putnam and Myers 2003).

image from book
Figure 20-3: Relationship between team size, schedule, and effort for business-systems projects of about 57,000 lines of code. For team sizes greater than 5 to 7 people, effort and schedule both increase.

Putnam reviewed about 500 business projects that were in the range of 35,000 to 95,000 lines of code (LOC) and which averaged 57,000 LOC. He stratified these projects into 5 groups based on the sizes of the development teams. The average sizes of the projects for each team size were within 3,000 LOC of one another. Putnam found that, as team size increased from the 1.5 to 3 range to the 3 to 5 range, the schedule shortened and effort increased, which is what you would expect. As team size increased from 3–5 to 5–7, the schedule again decreased and effort again increased. But when team size increased from 5–7 to 9–11, both the schedule and effort increased. And when team size increased to 15 to 20, schedule stayed flat but effort increased dramatically.

I suspect (based on nothing but my own judgment) that Putnam's data is showing that software's diseconomy of scale is not a smooth, incremental function but is more like a step function that has large penalties that kick in at certain sizes.

Putnam has not yet generalized his findings to other kinds of software or other project sizes, but for the medium-sized business-systems domain, this is an important finding: A team size of 5 to 7 people appears to be economically optimal for medium-sized business-systems projects. For larger team sizes, both schedule and effort degrade.

Tip #95

For medium-sized business-systems projects (35,000 to 100,000 lines of code) avoid increasing the team size beyond 7 people.