129 Hours Against 49: Anatomy of an Effort Estimation Error
In our archive sits one seasonal landing page project. We billed 49 hours for it. We actually spent 129. The project shipped, the client was happy, we got paid — and it is the one case where I know both numbers for certain, because both survived in the paperwork.
A gap of 2.6x is not a record and not an exception. In a field study of 52 projects, effort overrun showed up in 76% of cases, with an average overrun of 41%. The question worth asking about effort estimation is not "how many hours" but "at what moment, and on what basis, was this number said."
An estimate goes wrong not because someone counts hours badly. It goes wrong because it gets said before the requirements are fixed, and after that the first number spoken acts as an anchor for every recalculation that follows. The fix is not a more precise formula — it is moving the estimate into its own stage of the process, after the scope is written down and before anyone signs off.
Where the 80 unaccounted hours actually went
"We underestimated the complexity" explains nothing and fixes nothing. What helps is breaking the gap into events, each one nameable and datable. On this project there were five such events, and not one of them looked like a problem at the moment it happened.
The estimate was named before the scope was written down. The number came up on the first call, in answer to "roughly how much would this cost." A ballpark figure was meant to give the client a sense of order of magnitude — and it became the figure in the agreement. Between "roughly" and "agreed" there was no document at all.
Every clarification arrived one at a time. Add a program block. Show prices in two currencies. Make a separate version for the mailing list. Taken alone, each clarification is thirty minutes to an hour, and pushing back on it looks petty. The sum of those half-hours made up most of the gap.
Approval rounds were treated as free. The estimate covered the designer's and the layout artist's work. It did not cover: correspondence, three rounds of copy edits, waiting on materials, rebuilding the layout after the client showed the mockup to a colleague. Those are manager hours and executor hours, and they exist whether or not anyone counted them.
Seasonality ate the buffer. The project was tied to a holiday launch, and the launch date does not move. When the work is running late and the date is fixed, the only resource left is people's evenings and weekends. The buffer that on an ordinary project would show up as a schedule slip showed up here directly as effort.
Nobody recalculated mid-project. The overrun signal appeared roughly halfway through — and never turned into a conversation. A conversation about money when the work is half done is always more uncomfortable than one at the start, so it gets postponed to the end, where it no longer changes anything.
| Event | What gets lost | Who notices |
|---|---|---|
| Estimate named before scope is written down | The right to revise the number without losing face | No one — the number feels like a win |
| Clarifications arrive one at a time | Executor hours, an hour at a time | The executor — and stays quiet |
| Approval rounds excluded from the estimate | The manager's time, in full | No one — these hours are tracked nowhere |
| Fixed date with no buffer | The team's evenings and weekends | The team — as fatigue, not as a number |
| No mid-project recalculation | The chance to renegotiate | The manager — at the end of the month |
Look at the third column. Three of the five events go unnoticed inside the company entirely: no report tracks them, no one owns them, no moment forces them to surface. That is exactly why they keep repeating.
Why the first number named sets every number after it
The estimation gap is not a trait of any particular team. It is a stable pattern, reproduced across different samples and different countries. And it has a mechanism, documented separately.
In a survey of real software projects, effort overrun showed up in 76% of cases, with an average overrun of 41%. Summarizing earlier international surveys, the author cites a typical underestimation range of 30–40%.
The limitation of this data is worth stating myself: the sample is Norwegian, twenty years old, and the actual hours were collected from project managers' recollection rather than from a time-tracking system. The value is not in the precision of the percentage but in the persistence of the fact itself — overrun turns out to be the norm, not the exception.
What comes next is the interesting part. A review of empirical work on expert estimation shows the problem is not arithmetic — it is the order in which numbers appear.
Expert effort estimates systematically drift toward the first number named — the "anchor." An early rough guess, made with minimal information, keeps influencing later recalculations even after more detailed requirements have emerged.
This is a review paper, summarizing other people's experiments, some of them lab studies — it gives no precise figure for how often anchoring kicks in. But the qualitative finding explains our case better than any number could: "roughly 49" on that first call was not an estimate. It was an anchor that every later calculation gravitated toward, including the ones made once the scope was fully understood.
What changed in our process after this project
The conclusion we drew was not about calculation method — it was about process design. Estimation stopped being a line in a conversation and became a distinct stage with its own input and output. The sequence became: intake, requirements clarification, requirements document, effort estimate, sign-off, execution, delivery, a three-day acceptance window.
Two things about this sequence matter. First: the estimate comes after the requirements document, not before it — you can only count what has been written down. Second: sign-off sits between the estimate and execution, a clear point where both sides see the same number and confirm it.
The second part of the fix is financial. We introduced retainer plans with an explicitly named scope and a separate rate for hours beyond it. Not because it's more profitable, but because under this setup the conversation about extra hours happens by rule, not by mood.
How large the typical estimation gap really is
What this comparison leaves out matters most: averages are misleading. The distribution of overruns is skewed — most of the risk sits not in the middle but in the tail, which is exactly why planning to the average does not protect you.
Across a sample of 1,471 IT projects, the average budget overrun was 27%. At the same time, one in six projects turned into a "black swan": an average budget overrun of 200% and a schedule overrun of nearly 70%.
The limitation here is significant: these are large corporate and government initiatives, not a seasonal landing page. What transfers is not the scale but the shape of the distribution. One project in six goes off the rails, and it gets paid for out of the profit on the other five.
What changed by 2026 and what did not
Some work genuinely got faster. A prototype, a first draft of copy, a requirements breakdown, an initial diagram — all of this now happens noticeably quicker, and the temptation to shrink the estimate on that basis is real. What has not changed is where the gap comes from: it comes from scope, not from execution speed.
52% of projects completed in the prior 12 months experienced uncontrolled scope creep. Five years earlier, that figure stood at 43%.
The report rests on practitioners' self-reports and comes from a professional association with an interest in promoting its own standards — worth keeping in mind. But the direction of change is telling: the share of projects with scope creep is rising, not falling, despite two decades of methodology development.
The practical takeaway is simple. If a tool has doubled execution speed but scope is still being clarified one piece at a time and silently, the gap between estimate and actual will persist — it will just be expressed in different units.
Four rules that remove most of the gap
Don't name a number before the scope is written down
To "roughly how much," there is exactly one safe answer: an order-of-magnitude range and a date by which the real estimate will be given. Anything more precise becomes an anchor.
Count more than production work
Approval rounds, waiting on materials, revision cycles, and rebuilds are hours. If they are not in the estimate, they are still in the actuals.
Write down what's out of scope
A list of exclusions is shorter than a list of deliverables and works better than one. It is what turns a clarification into a separate conversation instead of a free add-on.
Recalculate at the midpoint
Set a point where actuals get compared against the estimate, and make it mandatory. An uncomfortable conversation mid-project is cheaper than a silent write-off at the end.
If an estimate shows up in an email thread before the scope has been written down, you are no longer estimating the project — you are haggling over a number that got said by accident.
Questions we get asked most often
How do you estimate project effort when the requirements aren't ready yet?
You don't — and that is the honest answer. Before the scope is written down, what you estimate is not the project but a stage: how long it will take to work through requirements and produce a requirements document. That stage can be estimated precisely, because its content is known. The estimate for the whole project comes after it, and the client gets not one number up front but two, each at a known point.
What do you do when the client demands a number right away?
Give an order-of-magnitude range and name the date by which the estimate will follow. The range needs to be wide enough that it doesn't become an anchor: "two to six weeks, more precisely after the requirements document." A narrow range, named out of a desire to sound confident, functions like an exact number and creates the same problem.
What contingency should you build into an estimate?
A percentage contingency doesn't solve the problem, because the gap comes from scope change, not from calculation error. What works instead: a separate contingency line in the budget for requirements that surface after the first review of the result, with its own owner and its own rule for spending it. Without that line, those requirements get delivered anyway — at the executor's expense.
How representative is a gap of 129 against 49?
It's one project at one company, not an industry benchmark. What's representative about it is not the ratio but the fact that both numbers survived: the actual hours were logged, not reconstructed from memory. At most companies, this comparison simply cannot be made, because actual effort is never tracked anywhere.
The figures "129 hours actual" and "49 hours billed" come from the internal budget for a seasonal landing page project in Alego.Digital's archive. The stage sequence (intake → clarification → requirements document → effort estimate → sign-off → execution → delivery → three-day acceptance window) and the retainer model with a separate rate for extra hours come from the client-engagement policy in effect during the same period. These are the author's company's internal documents; they have not been verified by an independent party and are presented as an illustration of the mechanics, not as an industry benchmark. The list of five events the gap was broken into was reconstructed from project files and correspondence.
- Moløkken-Østvold K. J. Effort and Schedule Estimation of Software Development Projects. University of Oslo, PhD thesis, August 2004. simula.no
- Jørgensen M. A Review of Studies on Expert Estimation of Software Development Effort. Journal of Systems and Software, 2004. simula.no
- Flyvbjerg B., Budzier A. Why Your IT Project May Be Riskier Than You Think. Harvard Business Review, September 2011. hbr.org
- Project Management Institute. Pulse of the Profession 2018 (survey of 5,402 respondents). pmi.org