Cone of Uncertainty: Boehm's Curve, and How to Narrow It
The Cone of Uncertainty quantifies how much an estimate at an early project phase can be expected to vary from the final actual cost. Barry Boehm published the original data in 1981; the curve has been refined and challenged since.
The original Boehm cone (software projects)
| Phase | Optimistic multiplier (low) | Pessimistic multiplier (high) | Range |
|---|---|---|---|
| Initial concept | 0.25x | 4.0x | 16x spread |
| Approved product definition | 0.50x | 2.0x | 4x spread |
| Requirements specification | 0.67x | 1.5x | 2.25x spread |
| Product design specification | 0.80x | 1.25x | 1.56x spread |
| Detailed design specification | 0.90x | 1.10x | 1.22x spread |
| Accepted product (delivery) | 1.0x | 1.0x | 0 spread (actual) |
Reproduced from Boehm B. (1981). Software Engineering Economics. Prentice Hall. Figure 21-1.
What the cone is and is not
It is a description of the best achievable estimate accuracy at each project phase, given that the team is actively reducing risk and resolving requirements as the project progresses.
It is not automatic. If the team does not actively work to reduce uncertainty, the cone does not narrow. Laufer (1996) and McConnell (2006) both argued that on poorly run projects the cone stays as wide as the initial concept phase right up to delivery. The cone narrows because the team makes decisions, not because time passes.
How to narrow the cone faster
- Resolve the highest-uncertainty unknowns first. Spike technology risks, validate critical interfaces, prototype the unknown UX.
- Set a fixed scope target with explicit variability. Use MoSCoW (Must, Should, Could, Won't) to make the negotiable scope visible.
- Stage-gate the budget release. Release only the next phase's budget; re-estimate at each gate.
- Use rolling-wave planning. Plan the next horizon in detail and the rest at coarse granularity, re-planning each wave.
- Re-baseline only formally. Re-baselining is legitimate when scope changes; it is a red flag when used to hide overruns.
Sources
- Boehm B. (1981). Software Engineering Economics. Prentice Hall.
- McConnell S. (2006). Software Estimation: Demystifying the Black Art. Microsoft Press.
- Laufer A. (1996). Simultaneous Management: Managing Projects in a Dynamic Environment. AMACOM.