Someone asks how long a project will take before anyone has written a requirement, and whatever number comes out of that conversation becomes the plan. Steve McConnell's cone of uncertainty explains, with uncomfortable precision, how meaningless that number is: at initial concept, estimates can be wrong by a factor of four in either direction. That's a 16x spread between the low and high ends.
Key Takeaways
- At initial concept, estimates can be off by 4x high or 4x low, a 16x total range (the Cone of Uncertainty).
- The cone narrows as you learn: to roughly 1.6x after requirements, and ±25% after UI design (McConnell).
- Early estimates are guesses about a thing nobody has defined yet.
- Give ranges early and commit to dates only when the cone has narrowed.
What the Cone Says
The cone of uncertainty, a central idea in McConnell's work on software estimation, describes how estimate accuracy improves as a project progresses (Construx). At the very beginning, at initial concept, before requirements exist and before anyone has decided what's actually being built, estimates can be inaccurate by a factor of four in either direction. A "three-month" project could plausibly be three weeks or a year.
As variability gets resolved, the cone narrows. After the product definition is approved, the range tightens; after requirements are complete it's roughly 1.6x; and by the end of user-interface design, roughly 30% into the project, accuracy improves to around ±25% (McConnell on the cone).
| Project stage | Estimate range |
|---|---|
| Initial concept | ~4x either way (16x span) |
| Approved definition | ~4x span |
| Requirements complete | ~1.6x |
| UI design complete | ~±25% |
Why This Matters More Than It Sounds
The cone is really a statement about information. Early estimates are imprecise because the project is imprecise: nobody has pinned down requirements, design, staffing, or scope, so the estimate inherits all of that variability. Precision comes from resolving unknowns, not from thinking harder about the estimate.
Which exposes the standard failure: organizations extract a number at the widest part of the cone, then treat it as a commitment for the rest of the project. The estimate never had the precision the plan assumes. Combined with the planning fallacy, which biases us low, and Parkinson's Law, which consumes whatever slack we add, early numbers become promises nobody could have kept.
A Concrete Version
A founder asks for a timeline on a new integration during a Monday planning call. The team says "maybe six weeks," meaning a rough guess with no requirements yet. By Wednesday, six weeks is in the board deck as a commitment. Requirements land three weeks later and reveal an authentication flow nobody anticipated, which is exactly the kind of thing that lives inside a 4x range. The project takes fourteen weeks. Nobody lied; a widest-point-of-the-cone guess was simply converted into a promise it could never support.
How to Estimate Honestly
Two habits fix most of this. First, give ranges rather than points early on, and say which part of the cone you're in: "somewhere between six and twenty weeks, and we'll know much better once requirements are done" is more useful and more honest than "six weeks." Second, re-estimate at milestones as the cone narrows, and make it normal to update the number when you learn something, rather than treating the first estimate as a contract. Anchoring in your own history helps too, since reference-class forecasting beats fresh guesswork.
The Honest Counterpoint
The cone has real critics, and it's worth knowing them. The most important objection: the cone describes the best case, how much uncertainty can narrow, not how it automatically does. Some analyses of real projects have found that estimate accuracy doesn't reliably improve over time the way a smooth cone implies, because scope keeps changing and teams don't always resolve the unknowns. So the cone is better used as a reminder that early estimates are structurally unreliable than as a precise schedule of how accuracy will improve. Narrowing is something you have to earn by actually resolving uncertainty.
What This Means for Teams
The cone gives leaders language for something engineers feel constantly: the number you want does not exist yet. Communicating that well, with ranges, explicit assumptions, and scheduled re-estimates, is a senior skill, and it's how you avoid the credibility damage of missing a date nobody could have hit. It pairs with measuring actual delivery over estimates and keeping the slack that real projects require. See available engineers.
Frequently Asked Questions
What is the cone of uncertainty?
McConnell's model of how software estimate accuracy improves over a project. At initial concept, estimates can be off by 4x in either direction (a 16x span), narrowing as requirements and design get resolved.
How much do early estimates improve?
Roughly: 4x either way at concept, about 1.6x once requirements are complete, and around ±25% after UI design (typically 30-40% into the project).
Why are early estimates so unreliable?
Because the project itself is undefined. The estimate inherits all the unresolved variability in requirements, design, scope, and staffing. Precision comes from resolving unknowns, not from estimating harder.
Is the cone accepted?
It's widely used but contested. Critics note it describes the best case, how much uncertainty can narrow, and that real projects don't automatically improve if scope keeps shifting. Narrowing has to be earned.
The Bottom Line
The number someone asks for at project kickoff can be off by 4x in either direction, and treating it as a commitment is how teams end up missing dates nobody could have hit. Give ranges, say where you are in the cone, re-estimate as you learn, and remember that accuracy comes from resolving unknowns rather than from estimating harder.
Roberto Espinoza is CEO of Ruzora, which helps US startups hire pre-vetted senior LATAM engineers in 72 hours. See available engineers.
