The cone of uncertainty describes the idea that estimates can become more dependable as scope and delivery evidence improve. It is not a guarantee that uncertainty shrinks with calendar time, nor a universal multiplier. Narrow an estimate by resolving specific unknowns, then show which assumptions and risks remain.
Terms used in this guide. fee: the amount charged to the client; cost: the expense included in the stated project model; margin: revenue left after the included costs; margin percentage = that amount / revenue × 100; baseline: the approved original plan kept for comparison.
In plain words
The cone of uncertainty is a simple idea: at the start of a project an estimate can be far from the truth, and as you learn more it can get closer. It does not narrow by itself with time. It narrows when you answer questions, such as making decisions, finishing design and clearing the main risks.
Who this helps: Project managers, presales consultants and sponsors who ask why estimates change.
Questions this guide answers:
- What is the cone of uncertainty?
- Why do early estimates have a wide range?
- How do you narrow an estimate?
Read first: What is a ROM estimate? explains the basics and the lifecycle this guide builds on.
How do you measure and show a narrowing estimate range?
Revised low effort = revised integration low + unchanged other-work low
Revised high effort = revised integration high + unchanged other-work high
Update the package changed by evidence. A sum of scenario endpoints is not automatically a statistical confidence interval.
What is the cone of uncertainty in project estimation?
The cone of uncertainty is a model of how the range of an estimate narrows as a project learns more. The idea comes from Barry Boehm’s work on software cost estimation and was popularised by Steve McConnell.
Why the range is wide early
- Nobody yet knows which integration design, acceptance rules or operating constraints apply.
- Each unknown allows a different amount of effort, so a wide range is honest.
What narrows it
- Decisions that remove alternatives (the client picks one workflow).
- Tests that replace guesses (a sample API call).
- Evidence that closes a named unknown.
What does not narrow it
- Time alone. A project can spend weeks writing documents and still not have tested its most important interface, while a one-day investigation can resolve a costly unknown.
- New requirements, which can widen the range again.
- A deadline. A range narrowed because the proposal is due tells the buyer nothing about delivery risk.
Do not treat any published multiplier as a guaranteed limit for your engagement: those ranges came from particular software projects. State what your own range means, whether alternative effort scenarios, an expert-judgment range or a statistical interval, because each needs different evidence.
What does a narrowing range look like in numbers?
The usual picture is a funnel that is wide on the left and narrow on the right. Here is the same idea as a table, using Eli’s project from the story below, in hours:
| When | What had been learned | Range | Width |
|---|---|---|---|
| January | Brief only | 600–1,200 | 600 h |
| February | Data reviewed: number of sources known | 700–950 | 250 h |
| March | Design approved, approver named | 780–860 | 80 h |
| Build | Actual cost to date plus remaining plan | Forecast, reviewed each sprint | Remaining exposure often reduces as work completes, but the forecast and its range are reassessed each sprint |
Read the table from left to right: the width falls because questions were answered, not because months passed.
Which decisions and evidence narrow an estimate range?
| Unknown | Useful evidence | Estimate consequence |
|---|---|---|
| Interface complexity | Tested API calls and sample responses | Replace speculative integration hours |
| Data cleanup | Profiling of representative records | Separate migration from remediation |
| User workflow | Approved journey and acceptance scenarios | Remove alternative workflow assumptions |
| Release effort | Environment access and a deployment rehearsal | Estimate the actual release tasks |
| Client response time | Named approver and review calendar | Confirm schedule dependencies |
Give each evidence request an owner and a due point, and give each unknown a specific test: representative calls for an interface, a sampled profile for data, test scenarios and a named reviewer for acceptance. If an unknown barely affects cost or feasibility, it does not deserve an expensive investigation.
Record the before and after: “Integration: 100–300 hours before the API test, 140–180 after supported operations were verified” shows what improved; “more confident after discovery” does not. Some findings also add scope. If the client adds another interface, record a scope increment first and then assess its uncertainty, so nobody concludes that better knowledge always lowers the price.
How should an estimate range change after discovery?
A portal ROM starts at 500–900 hours: integration 100–300 and other work 400–600.
- Test the API. The integration package narrows to 140–180 hours.
- Add the unchanged part. The total is 140 + 400 = 540 to 180 + 600 = 780 hours.
- Explain the movement. The lower end rises because the very cheap integration case is no longer supported; the upper end falls because the hardest case is ruled out.
- Do not over-narrow. Squeezing the whole project to 540–600 hours because one package is now understood would be wrong.
| Hours | Cost | |
|---|---|---|
| Before the API test | 500–900 | USD 30,000–54,000 |
| After the API test | 540–780 | USD 32,400–46,800 |
If discovery changes which roles are needed, re-price their hours individually. These endpoints are scenario sums, not a probability interval; if the high cases are linked (poor data also raises testing), say so. Each update should state the finding, the package affected, the new hours, the cost effect and the question still open.
How do you use an estimate range in a client conversation?
What to tell the client
- What decision the current range supports (for example, approve a budget and fund a short investigation).
- When the next evidence arrives and how the range will move.
Scenario: the sponsor asks for a fixed price after the first range
- The presales lead explains that choosing a price does not remove uncertainty in the work; it moves the risk to whoever signs.
- She asks who will own the remaining risk and what it costs, instead of demanding that the estimate fit a preset percentage band.
- She keeps price sensitivity apart from effort uncertainty: a fee 10% lower changes revenue but does not test the API.
- The proposal review still needs a difficult effort case, a staffed plan and a stated treatment for open dependencies.
Keep every version, compare actuals and remaining work with the approved baseline during delivery, and classify approved changes separately, so the team can learn from how the range moved.
Should every new requirement widen the estimate?
Only if it adds uncertainty or changes the work. A clarified requirement can narrow a range; a new integration can increase both effort and uncertainty. Record the effect at package level so stakeholders can distinguish scope growth from better understanding.
Real example: a project manager explains why the number moved
An illustrative story with invented figures, to show how the idea works in a real office.
Eli, a project manager, tells the sponsor in January: “Between 600 and 1,200 hours.” In February, after the data is reviewed, he says 700 to 950. In March, after the design is approved, he says 780 to 860.
The sponsor asks why the number keeps changing. Eli shows what was learned each time: the number of data sources, which tool would be used and who would approve the design. Each answer removed an unknown.
The range did not shrink because time passed. It shrank because three questions were answered.
Where does the cone of uncertainty show up in an IT project?
The cone is a picture of how estimate ranges tend to narrow as a project learns more. It is a teaching tool, not a law: the range only narrows when someone makes decisions and gathers evidence. Each lifecycle stage has an owner whose job is to produce that evidence.
| Stage | Who produces the evidence | Checkpoint |
|---|---|---|
| Initial idea (ROM) | Presales consultant | Range is wide and says so |
| Scope agreed | Presales lead with the client sponsor | Written scope; major unknowns answered |
| Discovery (narrow the range) | Presales consultant with a delivery lead | Each unknown has a test, an owner and a before-and-after note |
| Design complete | Architect or delivery lead | Integrations and data tested with samples |
| Build under way | Project manager | Forecast uses actual cost to date plus remaining work, reviewed at each sprint or month |
If the range has not narrowed by a gate, the question for the review is what evidence is missing, not who is wrong.
The cone of uncertainty: frequently asked questions
Does reaching a particular project phase guarantee accuracy?
No. The relevant question is whether the drivers of effort and cost have been tested or defined. A formal phase name can help organize review, but it is not evidence that unknowns have been resolved.
Is an early high estimate automatically pessimistic?
It may represent a plausible adverse condition. Evaluate the assumptions and evidence before labeling it. A useful range shows why the outcomes differ and which investigation or scope decision can change them.
Does the range shrink with time?
Not by itself. It shrinks when you resolve unknowns: decisions, discovery, design. Time without progress does not narrow it.
How do you show a narrowing range in Managed Margin?
Keep the integration investigation tied to the affected role allocations. After the API test, create or revise a draft scenario with 140–180 integration hours rather than simply reducing the whole estimate by a confidence percentage. Preserve separate plans when the endpoints represent different effort conditions.
Managed Margin's optional ROM price range keeps the strategy's resource loading unchanged. Use it to inspect margin at alternative fees, while separate strategies represent the revised effort range. Compare those calculations with the earlier version and record the evidence. Finalize only the selected commitment; the baseline should preserve the price, work and assumptions the team actually approved.
Explore the pricing and estimation workflow or review the delivery margin workflow.
Background reading: ROM vs Definitive Estimate and three-point estimating: the PERT method.
Continue the sequence: guides to read next
- What Is a ROM Estimate? Meaning, Cost and Example: the first, widest estimate on the cone
- ROM vs Quote vs Definitive Estimate: What Differs?: the narrow end of the cone
- Three-Point Estimating and the PERT Formula, With an Example: quantifying uncertainty on tasks
- How Much Contingency to Add to a Project Estimate: protecting margin while the range is wide
- ROM Cost Estimate Examples for IT Projects: five worked ROM calculations for services projects
- How to Present a ROM Estimate to a Client Without Anchoring: how to present early numbers so the client does not anchor on one end
- Project Estimation: Process, Methods and What to Consider: five estimation methods and how to choose between them
Sources and methodology
The worked figures are original educational illustrations. The linked references provide background for the estimating and management concepts; they do not establish the example rates or guarantee the outcomes. Product instructions describe the current implementation and are separate from methods the reader performs outside the application.
The examples, templates and calculations are original editorial illustrations, not market benchmarks or customer results. Monetary amounts are in USD, exclude tax unless stated, and use the cost boundaries defined in the article. Validate assumptions against your own delivery history before quoting.
Construx: background on the cone concept. Linked for the specific background concept; the numerical example and workflow are original.
Further background: Steve McConnell: software-estimation principles. The worked arithmetic and scenarios above are original; this reference provides context and is not a source for market rates or the stated example amounts.
The application walkthrough was checked against the current stage, pricing, cost-rule and delivery calculation code on 13 October 2026. Forecasts describe recorded actuals plus the remaining plan, not predicted customer outcomes.