The dreaded “Cone of Uncertainty”

“There's no sense being exact about something if you don't even know what you're talking about” -- John von Neumann

I read the above quote a few months ago in Steve McConnell’s excellent book on Software Estimation while researching different software estimation methodologies for a new project. I was about to start a new skunk work project and a friend has suggested Steve McConnell’s book along with Mike Cohn’s Agile Estimation and Planning book as an excellent resource for avoiding common mistakes while developing a large and complex project. Now that the project is well underway, this is my reflection on some of the techniques we have applied on the project.

A project is typically a compromise between cost, schedule and feature set. As the project progresses, project lead has to make many decisions about cost, schedule and feature and uncertainty in the project estimate arises from uncertainty in how these decisions will be resolved. The expectation is that as you make a greater number of these decisions, you reduce the estimation uncertainty. Steve McConnel has graphically depicted this as the great “Cone of Uncertainty”. It is based on a very simple but powerful idea that as you make the right decisions at the various stages of the project, the uncertainty decreases as the project progresses.

Once you understand that a project is an exercise in removing uncertainty, the next logical step is to breakdown all the known risks associated with the project. The next challenge after that is to figure out in which order team should remove these risks and uncertainties. This is a crucial decision that can easily cause the project to fail. If your team is asked to demonstrate progress after the end of every sprint, there is a tendency to pick up low risk features early on in the project. This approach is a recipe for disaster as it gives a false sense of progress early on in the project while in reality the cone of uncertainty does not narrow down since the team has not tackle any high risk features. Mike Cohn suggests a better approach to solving this problem. He suggests dividing the risk into following three categories:

• Schedule risk ("We might not be done by October")
• Cost risk ("We might not be able to buy hardware for the right price")
• Functionality risk ("We might not be able to get that to work")

One you have all the known risks categorized, a better sequence of development is to do high-value, high-risk features first. These features will deliver the most value and eliminate significant risks. High-value, low-risk features should be developed next as they are slightly less risky. These features offer as much value as the first set, but they are less risky. Low-value, low-risk features are sequenced third because they will have less impact on the total value of the project. Finally features that deliver low value but are high risk are best avoided till later.



This is a very sensible risk eliminating approach however it is not always easy to follow in practice. For example, it is not always possible to do high-value, high risk features earlier in the project. In my project one of the high-risk, high-value features was to integrate with two other projects that were being developed alongside my project. Since our timelines did not match exactly with their timeline, we got their service contracts much late in our development cycle and it was impossible for us to eliminate the integration risk early on in the project. We tried to mitigate this by mocking their service contracts as best as we could but this was not sufficient to completely eliminate the risk.

Once you have planned out all the known risks, it is important to remember that there may be unknown risks that you are not aware of early on in the project. Since these risks are not known, you won’t be able to plan for them and then you will have to deal with them as you encounter them. If one of these unknown risks is a black Swan event and you encounter it late in the project, there is a very high chance that it will cause the project to fail. Black Swan events are low probability, high risk events that Wikipedia describes as follow:

First it is an outlier, as it lies outside the realm of regular expectations, because nothing in the past can convincingly point to its possibility. Second, it carries an extreme impact. Third, in spite of its outlier status, human nature makes us concoct explanations for its occurrence after the fact, making it explainable and predictable.

If your project is destined to run into a Black Swan type of problem, it is much preferable to encounter that iceberg early on in the project because even if it totally destroys your project, the cost would be low compare to running into it much later in the game.

The unfortunate thing is that even after planning all the known risks and keeping an eye out for unmitigated risks, it is not a guarantee that your project will succeed. The reality is that projects rarely fail due to technical decisions and at the end of the day numerous other factors that are not in your control affect the outcome of the project. Culture of the organization is a key contributing factor to the outcome of the project. A large conservative organization can slow down an agile and nimble team with its bureaucracy and status co. An organization lacking infrastructure to support rapid iterative development can slow down a skilled team. At the end of the day, successful project execution is equally dependent on strategic management, organizational culture and value as it is on technical design choices. The bottom line is that regardless of which project management methodology you use, there are no silver bullets and only way to survive and succeeded is to stay nimble and adapt quickly to challenges your project will face throughout its lifecycle.

This post contains copyrighted material the use of which has not always been specifically authorized by the copyright owner.The material is being made available for non-profit research and educational purposes only.I believe this constitutes a 'fair use' of any such copyrighted material as provided for in section 107 of the US Copyright Law.If you wish to use this copyrighted material for purposes of your own that go beyond 'fair use,' you must obtain permission from the copyright owner.This is a completely non-commercial site for private personal use. No fee is charged, and no money is made off of the operation of this site.