Why software projects go over budget

Software projects go over budget in five places, and engineers working slowly is not one of them. In rough order of how much money each moves: scope that grew without anyone calling it growth, integrations against systems nobody could see before signing, data that was dirtier than described, a decision the client owed that arrived three weeks late, and rework caused by feedback that landed after the thing was built rather than while it was being built.

Four of those five are decided before a line of code is written, which is why most advice on overruns misses. It tells you how to manage a build. The number was set during the sale.

We sell fixed scope, so we carry the estimation risk on our own quotes. That gives us a specific view of where the money goes and a specific bias. Both are declared below.

1. Scope that grew without anyone calling it growth

The largest source and the least visible, because nobody proposes it. It arrives as clarification.

“Users can export a report” is a line both sides read and neither side priced. The vendor priced one CSV of one table. Over six weeks it becomes a date range, a column chooser, an exclusion for test accounts, an emailed file for row counts that time out in the browser, and a layout matching the one finance uses. Nobody asked for a new feature. Every request is a defensible reading of the original sentence.

The mechanism is a mismatch of altitude: a requirement written at one level of abstraction gets implemented at another, and the gap is real work with no name. Work with no name never reaches a change order.

How it gets priced. Under fixed price it is absorbed, because invoicing for forty minutes costs more goodwill than it collects, and absorption eats the contingency. Once that is gone the vendor refuses things, including reasonable things, and a client who heard yes for two months reads the first no as bad faith. Under time and materials it is billed at full rate and surfaces in a burn report weeks after the conversation that caused it.

Who pays. Fixed price: the vendor first, the relationship second. Time and materials: you, quietly enough that you find out at the invoice. The countermeasure is not vigilance but a written exclusion with a price on it, which we take apart in fixed price versus time and materials.

2. Integrations against systems nobody could see before signing

The endpoint is documented. Your instance is not.

The docs describe the API. They cannot describe whether your sandbox behaves like your production tenant, whether the rate limit on your plan matches the reference, what a token refresh does when two workers race for it, whether the field called status holds the six values in the schema or the nineteen an operations team has typed into it since 2019, or what happens when three calls in five succeed.

An integration described in prose is priced as risk. One whose sandbox the estimator has opened is priced as work, and the distance between those two numbers is the entire contingency on that line. The rest of what sits between an endpoint and a working integration is in why a quick integration is never quick.

Who pays. The clearest case where fixed price costs a well-prepared buyer money: if the integration turns out clean, the contingency was never spent and you funded it anyway. The fix is not arguing the buffer down but handing over sandbox credentials before the quote is written.

3. Data that was dirtier than described

Third by frequency, and on a migration capable of moving more than the other four combined. “We have about forty thousand customer records in a spreadsheet” is an accurate sentence that predicts almost nothing. Those rows hold duplicates that are not exact duplicates, four date formats, a notes column carrying two unrelated meanings depending on who typed it, and referential integrity that lives only in one person’s head. That is what data looks like after a decade of being useful to humans rather than a database.

Migration effort is a function of variance rather than volume, and variance cannot be estimated from a description. It can be estimated from a sample in two hours. A vendor quoting a migration without opening a real extract is quoting the average of everything that sentence could mean, which is how moving a spreadsheet process into an application goes wrong.

How it gets priced. Usually excluded, or carved out as hourly work inside an otherwise fixed contract. An exclusion is the vendor deciding you will pay for this one: defensible when they have not seen the data, not defensible once you offer a sample and they decline to look.

4. A decision the client owed that arrived three weeks late

The one entirely inside your control, and cheapest to fix.

The cost is not the three weeks of waiting. A team that cannot idle gets moved to other work, and when the answer lands they return to a half-built feature they must reload into memory, having made provisional choices that now need unpicking. A one-week delay rarely costs one week. It costs the swap out, the swap back, and whatever got built on the assumption in between. The expensive version is a stakeholder with veto power who has not seen anything yet: their first review is a re-specification, and it arrives in the week reserved for polish.

How it gets priced. Competent fixed bids price the client, not just the software, and our contingency is wider when a brief arrives with no named approver. A well-drafted agreement turns client-caused idle time into a schedule extension or a cost, and most buyers skim that clause. Under time and materials no clause is needed: you pay for the weeks at partial productivity, invisible because the team was busy.

5. Rework, because feedback arrived after the build

Feedback given while a thing is being built is design. The same feedback once it is finished is rework. The difference is when it was spoken.

The mechanism is dependency, not calendar time. Turning a free-text field into a controlled list costs minutes in week one. In week nine it touches a migration, a validation rule, three screens, an export, and whatever rows already exist in production. Nothing about the request changed. Everything about the blast radius did.

Other articles quote a hundred to one here. We will not: the data behind that multiplier is thinner than its popularity. Trust the direction, not the number.

What the published research says, and what it does not

Two studies and one model. Both studies cover programmes far larger than anything on our rate card, so read the mechanism and discount the magnitude. Flyvbjerg and Budzier, in the Harvard Business Review in September 2011, analysed 1,471 IT projects. Average cost overrun was 27 percent, which is not the finding. The finding is the tail: one in six was a black swan, averaging a 200 percent cost overrun and a schedule overrun of almost 70 percent. McKinsey, with the BT Centre for Major Programme Management at Oxford, studied more than 5,400 IT projects in 2012 and found large ones (initial budget above $15 million) ran 45 percent over budget and 7 percent over time while delivering 56 percent less value than predicted. That last number is the interesting one: schedule slipped least, budget more, value most. On projects our size the real overrun is more often measured in value than on the invoice, and nobody sends a variance report for it.

The model is Boehm’s cone of uncertainty, from Software Engineering Economics in 1981 and later popularised by Steve McConnell: at initial concept an estimate carries an uncertainty of roughly a factor of four in each direction. Not a margin of error, a factor. The cone narrows as decisions get made, not as time passes, which is why published MVP prices disagree by a factor of fifty.

The buffer, and what happens to it when nothing goes wrong

A fixed bid contains contingency. Our own working bands, stated as ours rather than as an industry standard: roughly 10 to 15 percent on work we have shipped many times with settled inputs, and 25 to 40 percent where an unseen production dataset, an undiscovered integration surface or an unnamed compliance reviewer sits inside the scope.

When the project runs clean, that money is not returned. We keep it. That is the product rather than a loophole: you bought a number that does not move, the risk did not land, and the premium was the price of not carrying it. Said plainly, a fixed price on a well-prepared project that goes smoothly costs more than time and materials would have, and that is the expected case rather than the exception.

The second-order effect is worse and less discussed. A vendor who absorbs three bad estimates in a row prices the next quote defensively, so the next client funds the previous one’s surprise. We have done this. The only defence we have found is keeping contingency visible to ourselves as a separate line rather than blended into the total.

Where our own estimate has been wrong

Not scope growth, not a late client, not dirty data. Us, estimating badly. Four recurring patterns.

The operations half of a feature. Every customer-facing capability implies an internal screen for the day it goes wrong: somebody has to refund, reassign or unstick a record. We have priced the visible half and found the admin half in week six.

Estimating an import from a schema. A schema describes what the data was supposed to look like. We have quoted from one, then opened the extract. Two hours of looking would have changed the number, and we skipped them because the client was ready to sign that week.

Treating revision rounds as a formality. Where a client had genuinely not seen a screen before kickoff, the first review is a design exercise, and pricing two rounds there prices the wrong activity.

Assuming a reviewer would be available. A plan needing a named person two hours a week depends on somebody who never agreed to it. We wrote that schedule without confirming the cadence.

We absorbed all four under fixed price, which is what we sold. The model only looks generous there because the client had already paid for the possibility.

Four things a client can do to keep a number honest

Decide fast, and name who decides

One approver with real authority, not a committee and not whoever emailed most recently. Put a clock on blocking questions, 48 hours as a norm, and treat “we are still discussing it internally” as a decision to spend a week. The best predictor of a project landing on its number is whether one person can say yes and make it stick.

Supply access early, before the quote rather than after

Sandbox credentials for every system the build must talk to, and a real data extract with real rows, anonymised if it has to be. That is the only reliable way to convert priced risk into priced work. Then ask for a re-quote on the same scope. If the number does not move, the contingency was never contingency. It was margin.

Review weekly, on staging, for thirty minutes

Not a status call and not a demo at the end of a phase. Open the thing and use it. Weekly review converts rework back into design, because it moves feedback from after the build to during it. A client who reviews weekly and one who reviews at acceptance get different invoices for the same scope.

Write down what is out of scope, with a price on it

A catch-all exclusion decides nothing, because the argument you will actually have is whether a thing was covered. A specific one ends it first: authentication is email and password with a reset flow, SSO and directory sync are excluded, and if you want them they are a change order at the attached rate card adding two to three weeks. Do the same for the browser matrix, data volumes, copywriting and licence fees. Getting inputs into a shape a vendor can price is the subject of writing a spec a developer can quote.

What removing the unknowns costs here

Our published scoping sprint is $3,500 for one week, credited in full against a build that starts within thirty days. It exists for the five sources above: it opens the sandboxes, reads a real extract, names the approver and writes the exclusions list, after which a fixed number estimates known work. Our minimum for a build is $7,500, most projects land between $18,000 and $45,000, and we bill half on contract and half on delivery, moving to milestones above $30,000. Those figures are estimates in US dollars, not quotations; the quote that follows scoping is fixed in writing before kickoff.

The argument against buying it from us is real: the artefacts are the point, not the invoice, and a contractor can produce them in a fortnight. So can you.

There is also a case where a fixed price from us is the wrong instrument. If the work is research-shaped, meaning the goal is to find out whether something is possible rather than to build a decided thing, no honest fixed number exists. We would be pricing our ignorance and charging you for it, and creating a vendor motivated to read every ambiguous line narrowly at the moment you need it read generously. Buy a bounded experiment with a cap instead.

The compressed answer

Overruns come from unnamed scope growth, unseen integrations, dirty data, late decisions and late feedback, in that order of cost. Under fixed price the vendor absorbs the first wave and the relationship absorbs the second. Under time and materials you absorb all of it and find out at the invoice. The contingency in a fixed bid is ours to keep when the project runs clean, so a smooth project cost more than it needed to.

What holds a number still is deciding fast, supplying access before the quote, reviewing weekly, and writing the exclusions down with prices on them. If you have a quote and want to know which parts are contingency, send us the scope and the number. We will tell you where we would have put the buffer, including when the bid you already hold is the more honest one.