Avoiding Pain in Software Estimation: Part 3 – The Cone of Uncertainty

Early on in the life of a project, when it’s only an idea in someone’s head, there is very little information from which to base any meaningful estimate. No details regarding the requirements, no details about the technology selected to best meet those requirements, no architecture, no design, not much at all really to use in any kind of reasonable estimate. The project, at this early stage, contains a lot variability or uncertainty which contributes directly to variability in estimates.

As a project matures, as requirements are gathered, as technology decisions are made, as the architecture is laid out, as designs are documented, these variable factors begin to diminish. This reduced variability can therefore lead to a reduced variability in estimates.

All of this describes the Cone of Uncertainty which is illustrated in the figure below. The horizontal axis represents the passage of time on a project while the vertical axis represents the variability of estimates. Furthermore, you can see that certain milestones common in every project have been shown on the horizontal axis. These milestones were not placed at arbitrary points. Research has shown that at each of these milestones, the variability factor of the project (and thus the variability of estimates) is reduced by the amount shown in the graph.

Also, it is important to note that this graph represents the results of research performed with skilled estimators. In other words, the graph represents a best case scenario and it is possible to have an even greater degree of variability.

The Cone of Uncertainty. Diagram borrowed from Construx Software (http://www.construx.com)

As you can see in the graph, any estimate given very early on will yield almost meaningless estimates. There are some schools of thought that simply do not allow estimates to be even attempted until the Cone is narrowed through some level of design.

Sometimes (quite often actually), estimators will be asked to revisit the estimate, “refine it” or “tweak it”. Sometimes this is an attempt to shorten the estimate. Sometimes this is asked to achieve an increased confidence in the estimate. This, however, is quite impossible. By examining the estimate alone, we have not “moved through the Cone” collecting any more data about the project. Without this data, we cannot narrow the Cone and cannot refine the estimate to provide any greater level of accuracy or predictability.

The manner in which you move through the Cone is important as well. For example, a poor design which is poorly thought through and poorly communicated will usually not narrow the Cone. What makes the Cone narrow is the reduction of unknowns, the variably and the uncertainty in the project. Each milestone, therefore, must achieve this reduction in a project’s variability.

Know where you are in the Cone. This is an important concept when providing estimates. One popular technique in software estimation is to provide ranges in your estimates. “I estimate three to five months for the project completion”. The size of the range is a direct result of knowing where you are in the Cone. Just a word of caution: this may lead to confusion and a misunderstanding with the recipient of this estimate. “It doesn’t sound like you really know” or “Let’s just say three months then”. So this is going to require that you provide some education. Describe the Cone of Uncertainty and where you are in the Cone. Explain the variability in the project at this point in time. And explain that you will be providing more refined estimates as you reduce this variability.

Estimates should always be revisited as you move through the Cone. As you define the project scope (including what you will NOT do), define your requirements, document the architecture, etc., you are adding data to your estimation process. With this new information, the ranges you use to report out your estimates, therefore narrow and your estimates also have more accuracy and predictability.

Probably the most important thing to keep in mind regarding the Cone is where you should feel comfortable giving commitments to your estimates. Remember, the Cone is a best case scenario. You could do worse (especially early on when the Cone is at its widest). Commitments made early in the Cone have significant risk, raise customer expectations to unrealistic levels and generally create an environment of stress and pressure to the point that the project becomes too difficult to manage to a successful outcome.