Effort Estimation as a Process Stage, Not a Line in a Negotiation
At most companies, effort estimation isn't a process stage. It's a line in a conversation: someone asked "how much," someone answered. A line has no input, no owner, no documented output, and no rule for revising it.
The difference shows up the moment there's a conflict. When scope has changed but the number hasn't, the argument is about the parties' good faith — because there's nothing to point to. When estimation was a stage, the argument is about whether scope actually changed, and there's a document that answers it.
An estimate becomes manageable once it has four attributes: an input — a described scope, an owner — a specific person, an output — a documented basis of estimate, and a re-estimation trigger — a rule under which a scope change sends the process back for recalculation. Calculation accuracy is secondary here: how the question is framed affects the outcome more than the calculation method does.
The Four Attributes of an Estimation Stage
You can check whether estimation is a real stage at your company in five minutes — by checking for four things. Missing any one of them means the estimate lives in correspondence, not in a process.
Input: a described scope. You can only estimate what's been described, and the description has to include a list of what's excluded from the work. Exclusions are shorter than inclusions and do more work: they're what determines whether the next clarification is a free add-on or a separate conversation.
Owner: a specific person. Not "the team estimated it," but a specific person — the estimate owner — whose name is on the number and who can answer what it's built from. A collective estimate with no owner removes accountability from everyone at once and strips the organization of any ability to learn from the gaps.
Output: a basis of estimate. Not a number, but a number with composition: what work it's built from, what assumptions were made, what wasn't accounted for. The basis isn't for the client — it's for whoever has to work out, a month later, why the actual diverged from the plan.
Re-estimation trigger. A rule under which a scope change sends the process back for recalculation instead of getting folded into the current work. Without that rule, changes pile up silently, and that's the primary mechanism behind plan-to-actual divergence.
| Attribute | Sign it's present | What breaks without it |
|---|---|---|
| Input: a described scope | There's a list of exclusions | Every clarification is free |
| Owner | The name behind the number is known | No one to explain the gap |
| Output: basis of estimate | The number is broken into composition and assumptions | The cause of a miss can't be reconstructed |
| Re-estimation trigger | A scope change triggers recalculation | Changes pile up silently |
I didn't invent this structure. It's formalized in industry practice standards, and it's worth looking at exactly how.
How the Practice Standard Describes Estimation
The estimation lifecycle is described as four sequential stages: preparing to estimate (building the approach and the inputs), producing the estimate with a documented output called the "basis of estimate," managing the estimate (revising it when scope changes), and improving the estimating process itself based on accumulated variances.
I'll name the limitation directly: this is a normative document, not a measurement, and what I read was the summary of its structure on the organization's website, not the standard's full text. It's useful not as proof but as confirmation that "estimation is a process with an input and an output" is standard practice, not my personal preference. It's worth knowing the counterargument too: the newer international standard ISO 21502:2020 deliberately dropped the tabular input-output model in favor of describing practices.
Question Format Changes the Outcome More Than Method Does
The most unexpected thing about estimation is that the quality of the result depends more on how the question is phrased than on the estimator's skill. That's been tested in the field.
When estimators were asked to give a "from-to" interval at 90% confidence, actual costs fell inside the stated interval only 74% of the time. When the same question was reframed as a probability — "how likely is it that costs will exceed this value" — the hit rate rose to 87%.
The sample is small and limited to two Norwegian companies and software projects — don't carry the percentages into another industry. The practical takeaway does carry over: if you ask "how much," you get a confidence that isn't real. Asking "what's the probability we exceed X" produces a noticeably more honest answer and, more importantly, sets up a format where uncertainty can be discussed without anyone losing face.
What a Formalized Input Buys You
The second effect worth checking is the link between how well scope is worked out before estimating and how predictable the outcome turns out to be. That's been measured in capital construction, where sample sizes are larger and data more complete than in IT.
The quality of front-end scope definition accounts for roughly 23% of the variance in final costs across industrial projects. Better-defined projects consistently showed more predictable cost and schedule than poorly-defined ones.
This is construction, not software development, and it would be wrong to carry the exact percentage over. What does carry over is the mechanism: a formalized input delivers a measurable contribution to predictability — but only a quarter of the variance, not all of it. The other three quarters depend on what happens after the estimate is made, and that's exactly the part the re-estimation trigger covers.
Confidence Doesn't Narrow on Its Own
There's a common belief that uncertainty automatically narrows as a project progresses — the so-called cone of uncertainty. That appealing picture has been tested empirically, and the test doesn't confirm it.
The uncertainty range of estimates stayed roughly constant across every phase of the projects studied — the ratio of the upper to lower bound stayed around 3.25 — instead of the expected narrowing. Median estimate error was 1.8x, and mean error was 2.0x.
This is data from one company — a case that debunks the popular curve, not a final refutation across every context. But the implication for process design is direct: if uncertainty doesn't narrow on its own, the estimation stage can't be a one-time event. It has to repeat with every scope change — which is exactly why the fourth attribute, the re-estimation trigger, matters more than the first three.
How to Build the Stage into an Existing Process
The one genuinely hard part is holding the line on the trigger. Sending the process back to the scope description over a half-hour tweak feels like bureaucracy, which is exactly why the first exception almost always gets made — and after the first, no one's counting anymore. The practical fix is a threshold: changes below an agreed size accumulate in a separate list and get recalculated as a batch; everything else sends the process back to step one. I break down how that kind of list accumulates, and what it costs, on a specific project where the actual came in 2.6x over the estimate.
Four Decisions That Turn Estimation into a Stage
Ban naming numbers before scope is described
For "roughly how much," give an order-of-magnitude range and a date by which the real estimate will be ready.
Ask about the probability of overrun
Not "how long will this take," but "what's the probability we go over X." The question format changes the quality of the answer.
Document the basis, not the number
Scope, assumptions, and what's excluded. Half a page that explains the gap a month later.
Set a re-estimation threshold
A change bigger than the threshold sends the process back to scope description. Smaller changes accumulate in a list and get recalculated as a batch.
If there's no name and no basis behind the number, you don't have an estimate — you have a figure someone once said out loud.
Frequently Asked Questions
What should the basis of estimate include?
Three things: a list of work items with the effort for each, the assumptions made, and what's excluded from the estimate. Length — half a page to one page. The point of the document isn't precision; it's being able to open it a month later and see exactly which assumption didn't hold. Without it, reviewing a variance turns into trading memories.
Who should be the estimate owner?
Whoever will be accountable for delivery — not whoever's running the negotiation. If sales gives the estimate and the team delivers, a gap is guaranteed, and there'll be no one to explain it: the number won't have an author ready to walk through its composition. The workable compromise: the delivery team builds the estimate, and the account manager builds commercial terms on top of it.
How do you estimate when requirements keep changing?
Estimate the iteration, not the project, and make the estimation stage repeatable. The evidence shows uncertainty doesn't narrow on its own as a project progresses, so a single upfront estimate is pointless under those conditions. What works instead: a short horizon with a precise estimate, plus an explicitly stated range for the full scope that gets revised under a stated rule.
Won't formalizing estimation just turn into bureaucracy?
It will, if you document everything. That's exactly what the re-estimation threshold is for: small changes don't trigger the full cycle — they accumulate in a list and get recalculated as a batch. A sign the threshold is set right: the list gets recalculated once or twice a month, not daily and not never.
The stage structure of the process (request → clarification → statement of work → effort estimation → sign-off → execution → delivery → three-day acceptance) comes from Alego.Digital's client engagement policy. This is the author's own company's internal document; it hasn't been independently verified and is presented here as an illustration of the mechanics. The re-estimation threshold and the practice of batching small changes are the author's own practice, developed after reviewing projects where plan and actual diverged; there's no formal written description of this rule in company documents.
- Project Management Institute. Practice Standard for Project Estimating, 2011 (structure summarized on pmi.org). pmi.org
- Jørgensen M. Realism in Assessment of Effort Estimation Uncertainty. IEEE Transactions on Software Engineering, April 2004. simula.no
- Wang Y.-R., Gibson G. E. Jr. Project Definition Rating Index as an Indicator of Project Performance. PMI Research Conference, 2002. pmi.org
- Little T. Schedule Estimation and Uncertainty Surrounding the Cone of Uncertainty. IEEE Software, 2006. researchgate.net