Across 1,471 IT projects studied by Bent Flyvbjerg and Alexander Budzier at Oxford, the average cost overrun was 27%. That sounds survivable. The headline buried underneath is not: one in six of those projects was a "Black Swan" that ran 200% over budget and nearly 70% over schedule. Estimates do not just drift. A meaningful share of them detonate.
So when someone hands you a number for a software project, the honest question is not "is this the right price?" It is "how was this number built, and does it survive contact with reality?" Let us pull back the curtain.
Most estimates are wrong, and the data is brutal about it
The Standish Group's long-running CHAOS research found that only about 16% of software projects are delivered on time and on budget with the agreed scope. Roughly half land in the "challenged" bucket: late, over budget, or quietly missing features. The rest are cancelled outright.
Read that again. The base rate for a software estimate being correct is closer to a coin toss that lands on its edge than to a sure thing. This is not because developers are careless. It is because estimating the unknown is genuinely hard, and human brains are wired to do it badly.
The planning fallacy: your brain is the bug
In 1979, Daniel Kahneman and Amos Tversky named the culprit: the planning fallacy, the systematic tendency to underestimate time, cost, and risk while overestimating benefits. The cruel part is its durability. The bias is robust across cultures, experience levels, and personality types, and it persists even when you know about it. Asking an optimistic developer "are you sure?" does not fix anything; they were sure the first time.
Why does it happen? We estimate the project we imagine, where requirements are clear, nobody gets sick, the API is documented correctly, and the client signs off on the first draft. Reality ships a different project. Staff change, priorities shift, the "simple" integration has three undocumented edge cases. The estimate described a project that no longer exists by week two.
How a real estimate is actually built
A trustworthy estimate is not a single confident number pulled from the air. It is a process that converts four messy inputs into a defensible figure:
- Scope. Every screen, endpoint, and admin flow written down. Vague scope is the single biggest source of overrun, because everything unwritten gets assumed away.
- Unknowns. The honest list of what we do not yet know. A good estimator prices the unknown explicitly instead of pretending it is zero.
- Complexity. A login form and a real-time multi-currency billing engine are not the same line item, even if both are "a feature."
- Risk. Third-party APIs, unclear requirements, and hard deadlines each carry a buffer, sized to the actual risk rather than a flat percentage of hope.
Each feature gets its own range, not a single point. The ranges are added up, the risky items carry their own contingency, and the result is itemised so you can see where every hour goes. When the number is built this way, you can interrogate it. When it is a single round figure with no breakdown, you cannot, and that is usually the tell.
How we do it at True Dev
We have been building software since 1997, and the pattern behind every blown estimate is the same: someone guessed instead of decomposing. So we refuse to guess. Every quote we send is itemised by feature, with scope written down, unknowns named out loud, and risk priced where it actually lives. Then we commit to a fixed quote, so the contingency is our problem to manage, not a surprise we pass to you later.
That is also why our project intake asks the slightly annoying questions up front. Every unknown we resolve before quoting is an unknown that cannot become a 200% Black Swan halfway through. A good estimate is not a promise that nothing will go wrong. It is proof that we already thought about what could. You can see how this plays out across our services, where the work is scoped, transparent, and priced like a process rather than a prayer.
