Why Everything Takes Twice as Long: IT Estimation That Survives Contact with Reality
Ask a delivery team how long something will take and you will get a number. Ask them three months later why it took twice that, and you will get reasons: the requirement changed, the interface was undocumented, the key person was on leave, the test environment arrived late. All true. All predictable. None of them in the estimate.
After thirty years of watching plans meet reality, we have stopped believing that estimation fails because people are bad at maths. It fails because of how estimates are produced, negotiated and then never touched again. Each of those is fixable.
Why estimates go wrong in the same ways
The failure modes repeat across sectors and decades:
- Estimates are produced from the inside view. Teams estimate the work they can see and skip the work that always appears: integration surprises, environment delays, rework after review, coordination overhead. The visible tasks are maybe 60 percent of a real project.
- Estimates are negotiated, not calculated. Someone senior hears “nine months”, frowns, and the estimate becomes six. Nothing about the work changed. This is the same disease we described in status reporting that executives trust: when honesty is punished, numbers stop meaning anything.
- A single number pretends to be certainty. “Four months” communicates false precision. The honest answer at the start of most projects is “three to seven months”, and everyone hates hearing it, which is why nobody says it.
- Nobody re-estimates. The original guess, made at the moment of maximum ignorance, is defended for the rest of the project as if it were a contract clause. Often it literally is one, which is a problem we covered in managing fixed-price integrator contracts.
What actually works
None of this is exotic. It is discipline, applied early.
Use reference classes, not optimism. The best predictor of your next project is your last five projects, not the plan for this one. If your organisation’s integrations have historically taken four months, the new one will not take six weeks because this time everyone is motivated. Keep a simple log of estimated versus actual per project type. Within a year you own a calibration table nobody can argue with.
Estimate in ranges, commit in milestones. Give leadership a range with an honest confidence level, then convert it into commitment gradually: a firm date for the next milestone, a provisional one for the next quarter, a range for the end. Precision should grow with knowledge, not precede it.
Make contingency visible and owned. Hidden padding gets stripped in the first negotiation. A named contingency line, owned by the project manager and spent against a log, survives scrutiny because it can be defended: this is what unknowns historically cost us.
Re-estimate at every gate. An estimate is a forecast, and forecasts get better with data. At each phase gate, re-run the numbers with what you now know and report the trend openly. A completion date that moves early is a planning tool. One that moves in the final month is a crisis.
Estimate the whole system, not the build. Environments, data migration, security review, training, hypercare. On enterprise projects the code is often the minority of the effort. Most of the failed projects we analysed in why IT projects fail blew their dates on everything around the software, not the software.
The conversation that changes everything
The single highest-leverage moment is the first estimate conversation with the sponsor. The version that fails: “How long? Four months? Make it three.” The version that works: “Based on our last four comparable projects, this class of work takes five to eight months. Here is what would need to be true to hit five. Which of those conditions will you help me secure?”
That framing turns the sponsor from a negotiator into a stakeholder in the assumptions. When one of the conditions fails later, the schedule conversation is already half done.
We set up estimation discipline, gates and honest reporting as part of our IT project management services. It is unglamorous machinery, and it is most of the difference between projects that surprise everyone and projects that merely finish.
Frequently Asked Questions
Why are IT project estimates always too low?
Because they are built from the visible tasks only, then negotiated downwards. Coordination, integration, environments and rework are systematically excluded, and optimism does the rest.
What is reference class forecasting?
Estimating a new project from the actual outcomes of similar past projects rather than from a bottom-up task list. It corrects for the things bottom-up estimates always miss.
How much contingency should an IT project carry?
Whatever your own history says unknowns cost, typically 20 to 40 percent for projects with integration or migration risk. The amount matters less than making it visible and owned rather than hidden as padding.
Editorial note: This article was researched and drafted with the assistance of Claude (Anthropic), and reviewed and approved by Amazing Projects before publication.
