'Accurate estimates' is an oxymoron?
If you're asked to estimate the time it will take you get from somewhere you've never been to another place you've never been either, how accurate would your estimate be? So it is with many project estimates - they're based on too little knowledge and too much uncertainty.
Any later adjustments to your estimate would be as you increase your knowledge of the challenge you've been asked - they would not be testaments to your estimating incompetence!
Estimates are dependent on the 'Uncertainty principle' that illustrates why initial estimates tend to be inaccurate and only become more accurate as the project progresses
Failure to recognise the Uncertainty Principle leads to a lot of misunderstanding about estimates (and therefore budgets and timescales). The Uncertainty Principle makes sense of a perplexing subject - estimating - as estimates are key determinants of project success.
The Uncertainty Principle
How long does it take you to get to work? Let's say it's 40 minutes.
So, most days it's 40 minutes give or take a few minutes. Some days it is quicker - nearer 30 minutes - other days it takes longer, say over 50 minutes. On a few occasions it can take 90 or so minutes due to accidents, road-works and alike.
So tomorrow you have an important meeting with 'the big boss' at 8am. What time will you leave home - 7.20? Unlikely. There is enough uncertainty in your journey time for you to 'allow' for delays, bad weather, etc. You'd probably leave at, say, 7am. This is a 50% allowance for 'uncertainty'.
The 'uncertainty principle' is the level of uncertainty that exists when making an estimate - the level of unknowns.
To illustrate. Take a journey between two points you've never been to. How would you estimate that journey time? To do this you'd have to seek out as much information about the journey, roads, form of transport, likely impediments, weather conditions, etc.
As you get more information you'll be able to give a better estimate of the journey time. The earlier you're asked for a 'final' estimate the more inaccurate it will be, as your level of uncertainty (unknowns) will be high.
So it is with project estimating. The more unknowns, the more the uncertainty, the less accurate the estimates. As you progress through the project the more the unknowns will become knowns and the more accurate the estimates will be.
By the end of the project's solution-design stage the estimates should be fairly robust. But before that any estimates range from wild guesstimates to only partly-informed estimates.
However, when do most organizations expect a business case with fixed cost and time estimates? Often before even the requirements have been done! IE when the level of uncertainty is still very high.
No wonder these estimates are so often wrong.
Under v Over Estimating
"But," you may ask, "why are estimates always 'under estimated' even when contingency and 'padding' is included?" There are three principal answers to this question.
When estimates are over-estimated this means they'll be surplus funds. Now, rather than return the funds or deliver early, what tends to happen is that work expands to the funds available. A key governance team accountability is to see the funds allocated to the project as the maximum to be spent, not the target to be spent
Then there's people's optimism. Most people naturally under-estimate. They identify the obvious activities but usually don't foresee all of the glitches, problems, delays or special events that will occur. To illustrate this, I have found that a carefully compiled workload estimate, including contingency allowances for things going wrong, delays, etc, must still be multiplied by FOUR to be accurate!
Management cannot take the real answer. The team works out the estimates and finds the true total estimate to be an answer that is too high, one that the management won't accept. So, rather than present the true total figure, the team presents a reduced estimate so as to get the project approved. Then, as the project progresses, the estimate is 'adjusted' up to the full figure.
One Project Investment Committee member recently observed that he automatically doubled the costs and halved the benefits on any proposal presented. (Unfortunately, in his organization, this was usually very accurate.) Although extreme, he was in effect applying 'the uncertainty principle' to project estimates. However, there is a better way.
Best - Worse - Most likely
When estimates are uncertain, three different estimates should be given - best case, worst case and most likely. The range between these three figures should narrow as the project progresses and the level of uncertainty is reduced.
What these three estimates are saying is, "If you are not willing the spend the best case estimate, don't start. However, the project should never exceed the worst-case estimate. At this time our most likely estimate is this..."
However, the 'uncertainty principle' dictates that the earlier you ask for estimates, the less reliable they are. So if you go to your investment committee with a funding request based on highly uncertain estimates (that you've demanded from your project team) you've only got yourself to blame for any subsequent increase in the estimates and the blame that comes with it.
