In the mid-1970s my project team was asked to estimate how much disk space our new system would require (when disk space was expensive!). Our incumbent consultants were to produce the final figure so I sat down with their project manager to do the estimates. If I saw 120 bytes, I said, "150 bytes", he wrote down "200 bytes" and his manager upped this to "300 bytes" and so on. By the time we'd finished our system's disk requirements exceeded the whole organization's existing disk usage! (We had to do it again, accurately.)
Inexperienced estimators tend to be overly optimistic and assume that everything will go right. More experienced estimators tend to assume everything will go wrong and so pad their estimates accordingly
Our estimating skills are usually dependent on our experience. Inexperienced estimators tend to be overly optimistic and assume that everything will go right. More experienced estimators tend to assume everything will go wrong and so pad their estimates accordingly. But, in the planning process, this padding can become cumulative (as above) resulting in poor overall estimates. And, as the estimates drive the costs, this can unnecessarily increase the cost of the project.
Poor estimating is also encouraged by a project's culture.
If you're asked to estimate how a long a task will take and say, "Five days" and have it ready in two days, you're seen as an unreliable estimator. So, rather than saying, "Great, we're three days ahead" the project manager is more likely to say, "Gee, he/she's pretty poor at estimating". So, next time, rather than being seen as a poor estimator, the project team member is likely to sit on or otherwise hold on to the work until the five days are up.
Poor estimating is also encouraged by most organization's culture.
Senior management conveniently forgets the meaning of the word "estimates" and assumes they should be accurate, "If you know what you're doing." But management ask for too much accuracy too soon.
As we saw earlier in this series, when "final" estimates are required too early in the project delivery process (before the requirements, let alone the solution have been defined), the level of reliable information required for estimating is too low for accurate estimates. However, any subsequent revision is then seen as "increasing time and budget". Senior management have to be reminded occasionally what the word "estimate" means and the need for information!
Estimating behaviours are driven by information (or the lack of information).
If someone asked you how long it would take to get from Sydney to Melbourne you'd need to know a lot of detail to answer accurately — day, time of day, mode of transport, funds available, departure time flexibility, etc. The more detail you have, the more accurate your estimation.
Even so, if you were required in Melbourne at 9am for a critical meeting, you could catch an early flight that morning from Sydney and "hope" all goes well; or you'd take an evening flight the previous day to ensure your timely arrival. So if the task is critical by a certain date, you'll add more padding to ensure you have the time to complete.
Goldratt, in his book, Critical Chain, recommends that all "allowances" in estimates be grouped together at the centre and halved. So, a five day estimate becomes, say, 2 days plus 3 contingency, and these three days are taken off the estimate and halved, creating a "bucket of contingency" of, in this case, one-and-a-half days. This central contingency is then allocated out when the tightened estimate is not met. Reportedly, this has a significant impact on projects, shortening their time (and cost) significantly — but is a very different way of managing estimates.
Overall, under and over estimates should even out. Few tasks will take exactly the time estimated; some will go well and fast, others will hit unforeseen snags — but nett out in the end.
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.