Understanding Estimation Uncertainty
Software development consists of making literally thousands of decisions about how the software will function. Uncertainty in a software estimate results from uncertainty in how the decisions will be resolved. As you make a greater percentage of those decisions, you reduce the estimation uncertainty.
The Cone of Uncertainty (below) shows how estimates become more accurate as a project progresses. The horizontal axis contains common project milestones and the vertical axis contains the degree of error that has been found in estimates created by skilled estimators at various points in the project.
As you can see from the graph, estimates created very early in the project are subject to a high degree of error. Estimates created at Initial Concept have a total range from high estimate to low estimate of 4x divided by 0.25x, or 16x. As you can see from the picture above, estimation accuracy improves rapidly for the first 30% of the project improving from ±4x to ±1.25x. This is because the milestones shown tend to be front-loaded into the project’s schedule.
The more refined the project definition, the more accurate the estimate. The reason the estimate contains variability is that the software project itself contains variability. The only way to reduce variability in the estimate is to reduce the variability in the project. The picture below shows what happens when the project does not focus on reducing variability – the uncertainty is not a Cone but rather a Cloud that persists to the end of the project. The issue is not really that the estimates do not converge, the issues is that the project itself does not converge – that is, it does not drive out enough variability to support more accurate estimates.
The Cone narrows only as you make decisions that eliminate variability. If a project is not well controlled or well estimated, you can end up with a Could of Uncertainty (above) that contains even more estimation error than that represented by the cone.
How Can I Get An Accurate Estimate?
Meaningful estimates are not possible in the early, wide part of the cone. Effective organizations delay their commitments until they have done the work to force the Cone to narrow. Meaningful commitments in the early-middle part of the project (about 30% of the way in) are possible and appropriate.
In short, you need a detailed design before you can get an accurate estimate. This is why we offer our kiosk software design services to ensure that you have a clear blueprint to build from which allows us to in turn create an accurate estimate. This does not mean that the requirements are “set in stone” just that proper forethought has been invested into the project to make it a success. If the requirements change, then we can be flexible and adapt to the changing needs of our client’s organization and revise our estimates accordingly. Spending the upfront time necessary in planning will go a long way to speed up the development timeline and reduce development costs by minimizing the need for rework.
- McConnell, Steve. "Chapter 4 - Where Does Estimation Error Come From?" Software Estimation: Demystifying the Black Art. Redmond, WA: Microsoft, 2006. Print.
- McConnell, Steve. "The Cone of Uncertainty." Construx Software. Web. 16 Dec. 2010.
- Wiegers, Karl Eugene. "Chapter 1 - The Essential Software Requirement." Software Requirements. Redmond, WA: Microsoft, 2003. Print.