Project Estimates

A common problem I have in a corporate environment is to accurately portray an estimate. We are estimating time and cost for software projects. The key issue is that software development estimates are highly inaccurate in the early stages, with errors of 200-400% quite common and a high degree of positive skew is evident. Overruns are more common than underruns and extreme overruns are alarmingly common.

The main problem is to express the uncertainty as clearly as the expectation, without appearing too elaborate.

In the past, we might say “There is a 90% chance that it will take 1-2 years and cost 5-15 million dollars”. This magically turns into “You said it would take 1 year and cost $5m!”.

We are dealing here with people who have zero statistical sophistication. There is a confounding factor that people want low numbers so their project gets approved over others.

I have some ideas:

1. Plot time or cost by probability.
2. Plot time by cost as a probability density cloud.
3. Express estimates like this (wide range, round numbers)
“
More than $3m
Less than $30m
“

Tim

P.S. I feel someone will suggest “Do better estimates then you won’t have a problem”. The fact is, until you have dug into the technical uncertainties and have defined requirements in detail you are subject to major technical risk and scope screep risk. You also have a serious problem of framing – the number the customer first thought of is likely to be way under the mark.