Why software projects run 45% over budget, and how shops quote

Overrun is the baseline, not the exception

McKinsey's work on thousands of large IT projects found an average cost overrun around 45 percent, and the tail is brutal: a meaningful slice of big projects run so far past budget and schedule that they endanger the company funding them. Surveys of software teams tell the same story from the inside - most projects exceed their original budget, and almost none finish meaningfully under.

That one-sidedness is the tell. If estimation error were honest noise, projects would come in under about as often as over. They do not, which means the problem is not variance. It is missing information. You priced the project the requirements doc describes, and then you built the project that actually exists. The gap between those two projects has a name, and it is not the one you think.

Half of scope creep was in the scope all along

Ask a founder why the last project ran over and the answer is usually scope creep: the client kept adding things. Sometimes that is true. But run the audit on your own overruns - go through the unbilled hours and tag each one either 'the client added this later' or 'this was always required and nobody wrote it down.' Shops that do this consistently find that about half of what got blamed on scope creep was hidden initial scope: work the project contained from day one that never made the requirements doc.

• Edge cases. The spec covers the user who uploads a clean CSV. It says nothing about the 2 GB file, the duplicate rows, or the upload that dies at 91 percent.
• Integrations. 'Syncs with their CRM' is five words in the proposal and three weeks of auth flows, rate limits, pagination quirks, and a sandbox that behaves nothing like production.
• Data migration. Nobody scopes ten years of the old system's data: undocumented fields, orphaned records, three formats for phone numbers, and all of it expected to import cleanly on day one.
• Error states and unhappy paths. Expired sessions, failed payments, permission denials, offline behavior. The happy path is often a third of the surface you actually ship.

The client is not hiding this work. They do not know it exists. Which means an estimate built from what a client can articulate on a sales call is always an estimate of a smaller project than the one you are about to build.

The discovery phase is the estimate

The fix is not estimating harder. It is refusing to price undiscovered scope. Shops that run a structured discovery phase before quoting the build - working sessions with the people who will use the system, a walk through the real data, a written spec that names the edge cases, integrations, and migration work - routinely land within about 10 percent of their estimates. Shops that quote off a feature list and a demo call typically run 40 to 60 percent over.

That gap is the entire game. Discovery is not preparation for the estimate. Discovery is the estimate. Everything you produce before it is a guess with a dollar sign attached.

How to sell paid discovery

Founders resist charging for discovery because it feels like billing the client for your own quote. Reframe it: discovery is the first engagement, not part of the sales process. Keep it fixed-price and short - one to three weeks, priced around 5 to 10 percent of the expected build - and make it produce deliverables the client owns outright, whether or not they hire you for the build.

1. A written spec that names the edge cases, integrations, data migration, and error states - the half of the project that never survives a sales call.
2. An architecture outline and a prioritized backlog, sized in ranges.
3. A firm quote for the build, priced on discovered scope instead of guessed scope.

The pitch is short: 'We do not quote a six-figure build off a one-hour call, because that number would be fiction and you would end up paying for the fiction. Discovery is two weeks at a fixed price. You get the full spec, the architecture plan, and a real quote. If you take that package to another shop instead, it will save you money there too.' That last line does the selling. A deliverable the client owns either way is not a sales cost. It is a small, de-risked first purchase - and the clients who refuse to pay for it are showing you exactly how they will treat change orders later.

The pricing-model decision rule

A fixed price on undiscovered scope is an insurance policy you sold for free: the client is fully protected from uncertainty and you absorbed all of it, with no premium charged. After discovery, fixed price is fair - both sides are pricing the same known project. When the client wants to iterate, or discovery keeps surfacing new territory, time and materials with a cap is the honest structure: they pay for what gets built, the cap gives them a ceiling to budget against, and for the first time the incentive to control scope sits on both sides of the table.

Quote in ranges, re-quote at checkpoints

Even on discovered scope, a single-number estimate is a lie of precision. Quote a range with a confidence level attached: the build is $80,000 to $95,000 and we are 80 percent confident in that range. Said out loud, it tells the client the truth about uncertainty before the contract is signed, which makes the conversation easy when reality moves. A single number makes every deviation feel like a broken promise, no matter how reasonable the cause.

Then put re-quote checkpoints in the contract and honor them: end of discovery, end of each milestone, and any moment an assumption behind the range breaks - a new integration appears, the migration data samples dirtier than expected, a stakeholder adds a workflow. At each checkpoint the estimate is reconfirmed or re-issued in writing. Eating drift silently feels generous in the moment, but it teaches the client that the original number was real and every hour past it is your problem. Shops rarely go broke on one bad estimate. They go broke re-honoring it for eight months.

Start with one number this quarter: quoted hours versus delivered hours on every project, each overage hour tagged hidden scope or client-added. Two or three projects of that data will show you exactly where your quoting leaks. It will almost never say your developers are slow.