its value. Indeed, the project might actually be going ahead without its funding being reviewed and approved.

The optimal estimate time and cost occurs at the saddle point and we can calculate where that should be. It will not be the same point for the early feasibility assessment of a very large complex system and for late planning of a very small simple system so we need to adjust for different types of projects. NASA’s Deep Space Network (DSN) project1 developed a mechanism for this calculation based on just two simple parameters:

˲ Target Cost of Project. This is the goal cost of the project as first envisaged in the project concept. It is not the estimated cost of the project (which has not been calculated yet). The rationale is, when we expect and plan to spend a lot of money on a project, we should also expect to spend proportionally more for the estimate, simply because more is at risk.

˲ The Business Practice being Supported. Very early in a project, it is normal that the data available is sparse, ambiguous, and of low quality. At this point in time, the business practice being supported is a conceptual one: should we consider this project? If we were to invest in it, would we get a reasonable return? For such estimates, investing too much time and effort is usually not worthwhile. The estimate produced will be (or should be) only used to approve the project for continued analysis or to

table 1. Phase estimation.

Phase Concept Commitment Planning

Expected Precision
order of Magnitude
budgetary estimate
Definitive estimate

value 24 60 115

table 2. Cost estimation.

Estimate type Concept estimate Commitment estimate Planning estimate

Cost of Estimate
$6,764
$16,910
$32,411

table 3. Effort and time estimation.

Estimate type Concept estimate Commitment estimate Planning estimate

Effort 68 Shrs 169 Shrs 324 Shrs

value 6 Days 14 Days 27 Days

reject it altogether. In the latter case, developing a highly detailed and expensive estimate for a project that will not even start is not a good use of resources.

Later in a life cycle, assuming the project has been given the go-ahead, we have better data and we are at the point of committing significant resources to move the project forward. Therefore it is worth spending more time and money to produce an estimate. Here the business practice being supported is one of financial budgeting and resource allocation.

Later still, when the resources have been allocated and the project is ready to launch, we need even more detailed estimates and we often have high-quality data to support them. These estimates will provide the bounding box inside which the project plan will sit and supports the project and manpower planning activity.

The Formula. The formula devised by NASA is a simple one:

 

Cost_of_Estimate = Practice_Parameter * Target_Cost0.35

 

Where the values of Practice_Parameter are related to the estimation phase by Table 1, and the exponent of 0.35 is fixed (for NASA).

Using the Formula. Since the formula only uses two simple parameters, it is easy to apply—a project with a Target Cost of (say) $10m should expect to spend the amounts given in Table 2. Simply by dividing the cost by a personnel rate we can arrive at a simple effort value and using a personnel loading factor we can deduce an approximate schedule to produce the estimate. Using an average personnel rate of $100/ staff hour and three people allocated half time of eight-hour days to producing these estimates, our $10m project estimates would take the effort and time given in Table 3.

Some Caveats

There are some caveats to using this approach intelligently, three of which I will address here. One is that the ef-fort/time ratio is not linear for heavy staff loading—we cannot get the 68 Staff Hour estimate in one hour elapsed time by putting 68 people on the task for instance.

Secondly the calculation is driven by
the Target Cost which is only, well, a tar-
get. What happens if the target is way
off? A common result of producing an
estimate based on the calculated time
and effort determined by this formula
is that we find the Target Cost is actu-
ally not achievable. This is, of course,
the point of creating the estimate. In
this case it is perfectly appropriate to
expend whatever extra time and effort
is indicated by the new (estimated) cost
to further refine the estimate.

the never-Ending Drive-By

After Ben’s boss had taken the ballpark numbers to the CEO they were, quite predictably, cast in concrete and used to fund the project—though only after they were trimmed somewhat to take out the “fat.” The resulting project was a case study in under-resourcing and experienced enormous overruns. Having learned their lesson from this, much greater “accuracy” was demanded of future estimates, to the point that it was decreed that the project manager would be held personally responsible for any variation from the estimate of more than 5%—plus or minus(!). Using these guidelines, producing the “ estimate” on a subsequent project took close to 35% of the expected budget before it was decided it should be canceled. Both extremes, of course, drew the public ire of senior executives.

Clearly, in the business of software, our estimation effort needs to be “just right” if we are not to suffer the anger of Papa Bear.

 

Reference

1. remer, d.s. and buchanan, h.r. a model for the cost of doing a cost estimate. The Telecommunications and Data Acquisition Progress Report 42-110, nasa Jet Propulsion laboratory, Pasadena, Ca (1992), 278–283.

 

Phillip G. Armour ( [e-mail]) is a senior consultant at Corvus International Inc., deer Park, Il, and a consultant at QsM Inc., Mclean, Va.