Through the years, I've been fascinated by how difficult it can be to get reliable estimates from an engineering team. Experts would frequently use the analogy of estimating software as if you were estimating building a house. But I found that estimating software is much closer to estimating building a subway in Europe: You never know when you will unearth a Roman ruin, bringing havoc to your plan. So how can you reliably forecast a project, when you know such risks are hiding beneath the surface?

At the heart of the problem is a simple concept known as the “Cone of Uncertainty”.

What is the Cone of Uncertainty?

The Cone of Uncertainty is a concept that was introduced by Barry Boehm in 1981, in his book "Software Engineering Economics" -- see the adapted diagram below. My early experiences mirrored Boehm's findings exactly: The further a project progressed, the more accurate the estimates for the remaining effort and time became.

Why does this happen?

My civil engineering colleagues like to tell me about the unknowns they encounter during construction projects, such as the archaeological finds during projects in Europe. Software projects also face similar risks. A common one is that underlying technologies never work exactly as documented. I've had to pursue Microsoft on several occasions, because some toolkit API had a bug which caused a critical failure in our system. Requirements changes also seem to be commonplace in software projects. But requirements changes are understandable -- customers often don't really know exactly how they need it to be, until they have a version in their hands to play with. In both of these cases, variance reduced as the project progressed because we learned more as the project progressed. In these cases, we learned more about the technology and about the requirements.

What can you do about it?

Improve your risk management processes: Formal risk management is a key tool that I use to expose these project learnings earlier in the cycle, and to reduce the variance in early estimates. Identify your risks (qualitatively and quantitatively), find those which have the highest exposure, and mitigate them early. Prototype high risk features, so you can estimate them with greater confidence. And implement higher priority and higher risk features earlier in the schedule, so that only low priority items are at risk of dropping off the plan at the end of the project.

Create a range of estimates: My teams found the greatest successes when they recognized that they're dealing with a range of estimates, not just a single number. Often, they referred to these as "optimistic", "pessimistic", and "most likely" estimates. We had to make a single commitment to customers, of course, so we would typically commit a more conservative date externally, while tracking a more aggressive schedule internally. Our customers would then push to shorten the conservative estimate, and we could do this, by continuing to aggressively mitigate our risks.

Improve your estimation processes: Usually, when I work with a team, they do not have established tools and techniques to use in their estimation. This leads to a large variability in the accuracy of their estimates. Typically, I ask the question, "Has any team here implemented a similar project in the past?" Often, the answer is yes, and they go to find the data from that project. Use historical data in your estimates. Unless you're doing something very different, your results are likely to be very similar. A more process mature approach is to use a size-based estimation model, such as story points or function points. We'll talk about this in a future article.

Improve your development model: To be honest, most projects I've seen have had requirements "evolution" throughout the life of the project. If you expect this to happen in your projects, then you should consider improving your development model as well. The traditional Waterfall approach is appropriate in some situations, but I've found that other models, such as Agile, Iterative, or Phased approaches allow you to be more responsive to changes from customers. These approaches can allow you to accommodate feature changes while still remaining within the original cost and schedule estimates.

Finally, re-evaluate your estimates throughout the project: I have never worked on a project that had the luxury of changing its project objectives midway through the plan. However, I have frequently recommended that my teams review their estimates throughout the project. This is a very valuable reality check. If an early re-evaluation demonstrates that your original plan is in danger, it gives you time to identify and address the problem, rather than being surprised when the delay exposes itself later in the project.

Lastly

I hope you've found some of these suggestions to be useful. Accurate software estimation is challenging, but it is possible. In my newsletter, we'll investigate these and other software project management techniques in greater detail.

Let me know what you think! I'd like to hear how how you've dealt with uncertainty in your project estimates. As well, if you have any questions, or if you would like more information on how to implement these or other software development processes in your organization, please feel free to contact me at Charles@CharlesConway.com.

If you know of someone who may find this article of interest, please forward it on!

Good luck!
Charles