The Cone of Uncertainty describes the change of uncertainties during a project. It goes back to research done by NASA which came to the conclusion that in the beginning of the project life cycle (i.e. before gathering of requirements) estimations have in general an uncertainty of factor 4. This means that the actual duration can be 4 times or 1/4th of the first estimations.

This factor can be quite different - depending on the character of the project. The more time the project spends on R&I the higher the factor.

The name "Cone of Uncertainty" comes from the initially fast, but later slow decrease of the uncertainty curve. At the beginning of a project, comparatively little is known about the product or work results. As more research and development is done, more information is learned about the project and the uncertainty then tends to decrease, reaching 0% when all residual risk has been terminated or transferred. This usually happens by the end of the project i.e. by transferring the responsibilities to a separate maintenance group.

The term Cone of Uncertainty comes from software development where the technical and business environments change very rapidly. Two geeks in a garage may redefine the business (ref: Apple Inc., Google). Most environments change so slowly that they can be considered static for the duration of a typical project, and traditional project management methods therefore focus on achieving a full understanding of the environment through careful analysis and planning. Well before any significant investments are made, the uncertainty is reduced to a level where the risk can be carried comfortably. In this kind of environment the uncertainty level decreases rapidly in the beginning and the cone shape is less obvious. The software business however is very volatile and there is an external pressure to increase the uncertainty level over time. The project must actively and continuously work to reduce the uncertainty level.

Consequences from the Cone of Uncertainty

• Estimations (e.g. on duration, costs or quality) are very vague at the beginning of a project
• Estimations and project plans based on estimations are to be redone on a regular base
• Uncertainties can be introduced in estimations and should be visible in project plans

External links

• The NASA Software Engineering Laboratory: Manager's Handbook for Software Development
• Reduced graphic of the Cone of Uncertainty on Microsoft.com