# What is the cone of uncertainty?

The cone of uncertainty is the shape made by graphing the accuracy of estimates against the stage of the project. It embodies the idea that estimates made at the beginning of a project will be limited in their accuracy, and that if you work to reduce uncertainty in the project, the estimates can become more accurate over the course of the project.

By understanding the cone of uncertainty you can understand why your initial project estimates will not be accurate, and how you can improve them. You can also use the cone of uncertainty to defend your estimates if they are called into question at a later date. You can also use the cone of uncertainty to support initial discovery stages of projects, where the project concept, requirements and design are fleshed out to give a better idea of project feasibility, schedule and cost.

The cone of uncertainty shows the best case accuracy of estimates made at different times in the projects life.

Estimates can only be as accurate as the assumptions they are based on. If your project is to build a bridge, but you are not yet sure how many lanes of traffic it will take, your estimates about the bridge cannot be particularly accurate.

Studies of software projects have shown that at the beginning of a project, even the best estimators are commonly mistaken in their estimates by a factor of 4. This means if they estimate the project will take a month, it could take as little as one week, or as much as four months. Later, once detailed design is complete much more accurate estimates can be produced, perhaps with less than a factor of two error.

By the way, this is the best case scenario with very accurate estimators! Most people cannot estimate this well, so estimates will likely be even less accurate.

## Why is this initial estimate so inaccurate?

Because any estimate is based upon assumptions. At the beginning of the project there are many unresolved questions. What are the requirements? How many people will be available to work on the project? What skill level will the people have? and many others.

Each unresolved question must have an assumed answer to produce any kind of estimate. The accuracy of these assumptions directly contributes to the accuracy of the estimate.

Throughout the course of the project many of these assumptions can be replaced with actual answers. Doing so reduces the uncertainty in the project and allows better estimates to be provided.

For instance once it is decided to provide a bridge for two lanes of traffic (instead of a single lane or four) cost and effort estimates can be greatly refined. This is an example of reducing uncertainty by clarifying project requirements.

## When should you commit to estimates?

The cone of uncertainty tells us that any estimates made early in the project will be wildly innacurate in the best case. Thus you should only make commitments based on estimates once you are further through the project.

You should delay committing to estimates as long as possible. Ideally the requirements gathering and design phase should both be complete before committing to estimates. This will produce the most accurate estimates.

Unfortunately clients and project sponsors usually want firm commitments at the very beginning of projects. This is the worst possible time to make estimates. According to the cone of uncertainty, any estimate you give will very likely be off by a factor of 4, which will cause anger and distrust between the project team and the client/sponsor.

If you are under pressure to provide estimates and commitments, attempt to negotiate a discovery phase of the project. During this phase the product definition can be clarified, requirements gathered and high level design sketched out. This gives a much better basis to estimate the project on. The cost of this phase can be charged to the prospective client, or if necessarily absorbed by the project team.

If a customer/sponsor refuses to allow a discovery phase, you should at the very least communicate the uncertainty in your estimates to the customer. The best way to communicate the uncertainty is to give the estimate using a range. For example, instead of estimating 1 month, you can estimate 1 week to 4 months.

By giving an upper and lower bound on your estimate you can clearly communicate the uncertainty inherent in the estimate. If the person receiving the estimate is unhappy with the range given, you can use it to request more time or resources to resolve some of the ambiguity and create tighter estimates.

As you proceed through the project you can reduce uncertainty and thus produce better estimates. However, this does not happen automatically! If you wish to produce better estimates you need to continually work to resolve any assumptions and update estimates to reflect this.

Note that the assumptions are a source of uncertainty, they are often related to a project risk. Thus the project risk register is a good place to track assumptions upon which the projects estimates are based. This also gives a central place to review to find opportunities to improve estimates. This can be performed in the periodic project risk review meetings.

TaskTrakz allows you to express estimates as ranges and track your risks in a centralized risk register. Expressing estimates as a two or three point range for each work item allows an estimate range to be calculated for the whole project. You can accurately communicate the uncertainty inherent in your project to project stakeholders, setting their expectations accordingly.