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.
order of Magnitude
table 2. Cost estimation.
Cost of Estimate
table 3. Effort and time estimation.
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
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.
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.
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 ( email@example.com) is a senior
consultant at Corvus International Inc., deer Park, Il,
and a consultant at QsM Inc., Mclean, Va.