Cone of Uncertainty: Why Early Estimates Are Wrong

By Tara Minh · Updated Oct 10, 2026

The cone of uncertainty is a model showing that project estimates are least reliable at the start and become more reliable only as unknowns get resolved. Steve McConnell's version puts early software estimates at anywhere from 0.25x to 4x the final outcome, narrowing toward 1.0x as decisions are made.

Key Facts

• 4x either way: Estimates made at the Initial Concept stage can be off by a factor of 4x on the high side or 4x on the low side (0.25x), a 16x spread from lowest to highest, according to Construx's Cone of Uncertainty white paper.
• Best case, not a promise: The cone shows the best accuracy skilled estimators can reach. Doing worse is easy, and being more accurate is only possible by being luckier (same Construx paper).
• Subjective origin: Barry Boehm drew the first version in his 1981 book Software Engineering Economics, and its ranges were set by judgment as 80% confidence limits, not measured from project data (Bossavit, The Leprechauns of Software Engineering).
• Narrowing is work: Most of the narrowing happens in roughly the first 20 to 30% of calendar time, and only because the team makes decisions that remove variability (Construx).

What is the cone of uncertainty?

Picture a funnel lying on its side. On the left, at the start of a project, it's wide. On the right, near delivery, it comes to a point. The vertical axis is how far an estimate of effort, cost, schedule or scope might sit from what you eventually deliver. The horizontal axis is time, marked by milestones: initial concept, approved product definition, requirements complete, design complete, and finished.

The idea is simple. Early in a project you don't know exactly what you're building, who'll build it, which risks will bite, or which requirements will change. Every one of those unknowns adds variation to the estimate. As each gets pinned down, the plausible range of outcomes shrinks.

That's the part people quote. The part they skip is what McConnell says right next to it: uncertainty doesn't shrink because time passes. It shrinks because someone made a decision. Construx's white paper puts it plainly, saying the only way to reduce the variability in the estimate is to reduce the variability in the project itself. Asking a team for "another week to refine the estimate" doesn't work if nothing in the project got defined during that week.

Where the cone came from

Barry Boehm sketched the earliest version in Software Engineering Economics (1981), calling it the funnel curve. At the earliest stage, estimates could miss by a factor of 4 in either direction: McConnell's Construx white paper puts the Initial Concept range at 4x high to 0.25x low, a 16x spread.

Steve McConnell later gave it the name "cone of uncertainty" and built it into his estimation books, including Software Estimation: Demystifying the Black Art (Microsoft Press, 2006). Construx, the firm he founded, still publishes the model as a white paper.

Here's the honest caveat. Laurent Bossavit's analysis of the cone's history found that Boehm's ranges came from judgment, not a measured dataset. Bossavit also points to Todd Little's 2006 data from real project status reports, published in IEEE Software, which didn't match the symmetrical funnel. Real projects run late far more often than they run early, and many sit at "90% done" for a long stretch.

McConnell's answer, in the Construx paper, is that the cone is a best case and that poorly run projects produce a "cloud" of uncertainty that never narrows. So treat the cone as a useful teaching model and a planning discipline, not as a statistical law. Its practical lesson holds either way: early numbers deserve wide ranges.

Cone of uncertainty vs other estimation concepts

The cone isn't an estimating technique. It's a lens for judging how much to trust any technique's output at a given moment. That's why it pairs with, rather than replaces, the methods below.

A useful rule of thumb: pick the method whose precision matches the cone's width. A bottom-up estimate to the nearest hour is false precision at initial concept. A rough analogous estimate is wasteful once the design is done and the scope is locked.

Why early estimates are wrong

It's tempting to blame the estimator. Usually the estimator isn't the problem. Four things widen the cone at the start.

Requirements are vague. "Build a customer portal" can mean a login page and an invoice list, or a full self-service platform with payments. Both are honest readings. The effort difference between them is enormous.

Scope is a moving target. Stakeholders add and remove features once they see something real. This is scope creep in its early form, before there's even a baseline to creep from.

Dependencies are unknown. You don't yet know that the payments team has a six-week queue, or that the legacy system needs a rewrite before you can integrate with it.

The team isn't settled. Skills, availability and velocity are guesses until people have worked together on the real thing.

Then there's the human layer. Optimism is the default, and a number that's said out loud in a meeting tends to become a promise. If a sponsor hears "about four months" at initial concept, that figure gets written into a plan, a budget and sometimes a customer contract. Nobody remembers that it came with a range of "one to sixteen."

Construx names this as the real danger. Organizations that commit while the cone is still wide, in its words, undermine predictability and increase risk. Committing at initial concept or product definition means living with a 2x to 4x estimating error.

How to use the cone of uncertainty (step by step)

You can't make the cone disappear, but you can use it deliberately. Here's a working sequence.

Step 1: Name the stage honestly

Decide where the project sits today: initial idea, approved scope, requirements complete, design complete, or building. Be critical. A project with a signed-off budget and a half-written requirements document is still at the wide end.

Step 2: Give a range, not a point

Convert your best estimate into a low and high value. At initial concept, the Construx model allows 0.25x to 4x, so a 100-day gut estimate becomes 25 to 400 days. That looks absurd on a slide, and that's the point. If the gap alarms people, they'll agree to the work that narrows it.

For task-level ranges, three-point estimation gives you a defensible way to produce the low, likely and high values.

Step 3: List the unknowns that create the width

Write down every open question that moves the estimate: unsettled requirements, unknown integrations, unconfirmed staffing, unproven technology. Rank them by how much range each one adds. This list is also the start of your risk register.

Step 4: Schedule the work that removes unknowns

Treat discovery as deliverables. Define the product vision, including what's out of scope. Complete the requirements. Prototype the riskiest interface. Run a technical spike on the integration nobody's tried. Each of these removes variability, and each should have an owner and a date.

Step 5: Delay the firm commitment

McConnell's guidance is that meaningful commitments aren't possible in the early, wide part of the cone, and that effective organizations wait until they've forced it to narrow. His paper describes commitments made about 30% of the way into a project as possible and appropriate. If the business needs a number sooner, give the range and label it as a range.

Step 6: Re-estimate at each milestone

Re-run the estimate whenever a major unknown is resolved, not on a calendar. Compare each new range with the last one. If it isn't narrowing, you've got a cloud, and the project needs a conversation about scope, staffing or approach.

Step 7: Baseline once the range is tight

When the range is narrow enough for the sponsor to fund and the team to commit, record it as the project baseline. Track variance against that figure from then on.

Ready-to-copy template: estimate range tracker

Copy this table into your project plan and update it at every milestone. The "Width" column is simply high divided by low, which shows at a glance whether the cone is narrowing.

How to fill it in:

1. Low and high come from three-point estimates summed across the work, or from the cone multipliers applied to a single best guess.
2. Unknowns resolved is a plain list of decisions made since the last row. If this cell is empty and the width didn't change, that's expected.
3. Commitment allowed? is a policy column. Agree on it with your sponsor up front so nobody argues about it at the start.

If the width column stops falling for two milestones in a row, escalate. Something in the project isn't converging.

Examples by business function

The cone isn't limited to software. Any work with undefined scope and unfamiliar steps behaves this way. The figures below are illustrative arithmetic applying the cone's early-stage multipliers (0.25x to 4x) to a rough first guess, not benchmarks.

Take the marketing launch. "Eight weeks" feels reasonable until you ask what's included. If the brief isn't signed off, who approves the copy, and whether legal needs to review claims, then "eight weeks" is a hope. Once the brief, sitemap and approval chain are fixed, the same project might honestly be quoted as six to ten weeks.

The same logic applies to an operations rollout. Before process mapping, a $200,000 figure has no more basis than a $600,000 one. After mapping and a vendor shortlist, the range might tighten to something a finance director can sign.

The cone and Agile teams

A common objection: "We're Agile, so the cone doesn't apply." It applies differently, not never.

Construx's own paper says that on iterative projects you pass through a miniature cone in each iteration. Before the requirements work for an iteration, you sit at the approved-product-definition part of the cone. With short iterations, a team can move through requirements and UI design in days, reducing variability from 4x to 1.6x for that slice of work. If the schedule is fixed, that variability shows up as uncertainty about which features fit, not about the end date.

What you give up, the paper notes, is long-range predictability of the combined cost, schedule and features several iterations out. Plenty of teams settle on a middle path: define most requirements up front, then build in short iterations. The paper says that drives variability from the cone down to about plus or minus 25%.

In practice, that means Agile teams still need ranges for roadmaps and release dates, and relative sizing methods like story points work best for near-term work. Far-out items deserve coarse sizing and an honest "we'll know more later."

Cone of uncertainty dos and don'ts

Dos

• Quote ranges early. Say "four to sixteen months" at concept, not "eight months." A range protects you and educates the sponsor.
• Tie narrowing to named decisions. Every row of your tracker should show what got resolved since the last estimate.
• Re-estimate at milestones. A new estimate after requirements are complete is worth more than a monthly refresh that has nothing new in it.
• Use ranges to prioritize discovery. The unknown that adds the most width gets worked first.
• Separate estimates from commitments. An estimate is what you expect. A commitment is a promise. They shouldn't be confused in the same sentence.
• Pair the cone with a quantitative method such as Monte Carlo simulation once you have enough detail to model.

Don'ts

• Don't treat the cone as automatic. Time passing doesn't narrow it. Decisions do, and the Construx paper says the cone can become a cloud when a project isn't controlled well.
• Don't promise accuracy the model can't deliver. Even skilled estimators can't beat the cone. They can only miss by more.
• Don't squeeze the range to please a sponsor. A tighter number with no new information behind it is just a larger risk.
• Don't ignore skew. Real projects slip more often than they come in early, so don't assume the low and high ends are equally likely. Weight your range toward the pessimistic side.
• Don't let a point estimate escape the room. Once "about four months" is in an email without its range, it's a promise.
• Don't use a precise method at a vague stage. Hour-level bottom-up estimates on a one-page concept are theater.

Common mistakes with the cone

Some teams hear "estimates are unreliable early" and conclude that planning is pointless. It isn't. The cone says to plan in proportion to what you know, and to spend the early effort resolving the biggest unknowns instead of polishing a number.

Others take the symmetrical shape too literally. Bossavit's critique is a good reminder that a clean diagram isn't evidence of a clean distribution. Use the multipliers as starting points for a conversation, then adjust for your own history. If your organization's past projects have run 40% over on average, build that in.

A third mistake is using the cone to excuse missing a baseline. Once scope and design are stable, the cone has done its work. At that point, variance from the baseline is a management issue, not an uncertainty issue. Scope, schedule and cost trade-offs become the right conversation.

Key takeaways

The cone of uncertainty gives you a defensible answer to a question every sponsor asks: "How long will it take?" The honest early answer is a range, and the width of that range is information. Narrow it by making decisions, not by waiting. Hold firm commitments until the cone has narrowed. And revisit your numbers each time a real unknown is resolved.