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.
What is Boehm's curve?
Boehm's curve refers to one of two figures Barry Boehm published in Software Engineering Economics (1981). Most often it means the Cone of Uncertainty (which Boehm originally called the “Funnel Curve”), where an estimate at the initial concept phase can be off by a factor of about 4x in either direction, narrowing to roughly 1.25x by detailed design. The same term is sometimes used for Boehm's separate cost-of-change curve, which shows the cost to fix a defect rising steeply the later it is found. This page covers the Cone of Uncertainty; for the cost-of-change curve see Boehm's cost-of-change curve.
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.
Related
Frequently Asked Questions
What is Boehm's curve?
Boehm's curve refers to one of two figures Barry Boehm published in Software Engineering Economics (Prentice Hall, 1981). Most commonly it means the Cone of Uncertainty, which Boehm originally called the Funnel Curve: at the initial concept phase an estimate can be off by a factor of about 4 in either direction (0.25x to 4.0x), and that range narrows to roughly 1.25x (0.90x to 1.10x) by the detailed design phase. The same term is sometimes used for Boehm's cost-of-change curve, a separate 1981 figure showing that the cost to fix a defect rises steeply the later in the lifecycle it is found. This page covers the Cone of Uncertainty.
What are the Cone of Uncertainty multipliers by phase?
Boehm's 1981 data gives an estimate range at each phase: initial concept 0.25x to 4.0x (a 16x spread), approved product definition 0.50x to 2.0x (4x spread), requirements specification 0.67x to 1.5x (2.25x spread), product design specification 0.80x to 1.25x (1.56x spread), detailed design specification 0.90x to 1.10x (1.22x spread), and accepted product at delivery 1.0x (the actual). The low multiplier is the optimistic case and the high multiplier is the pessimistic case relative to the final actual cost.
Does the Cone of Uncertainty narrow automatically over time?
No. The cone describes the best achievable estimate accuracy at each phase only if the team is actively reducing risk and resolving requirements. Laufer (1996) and McConnell (2006) both showed that on poorly run projects the cone stays as wide as the concept phase right up to delivery. The cone narrows because the team makes decisions, not because time passes.