Fixed price or hourly, and who is carrying the fat tail

Both models get defended with the same word, which should be the first clue that the word is doing no work. Fixed price is safer, says the buyer. Hourly is fairer, says the supplier. Neither statement is about the rate. Both are claims about who absorbs it when the project costs more than anyone thought, and that is the only question worth arguing over.

What makes it decidable rather than a matter of taste is that the shape of software overrun risk has been measured, repeatedly, on large samples. Once you know what that distribution looks like, the choice stops being a negotiating position and becomes arithmetic about who can survive the bad case.

What each model actually transfers

Strip the language away and a fixed price contract is an insurance policy. You pay a premium, built into the quote, and in exchange the supplier carries the cost of being wrong about the estimate. An hourly contract is the opposite: no premium, and you carry it.

That framing settles a lot of confused argument. A fixed price is not cheaper, and anyone comparing a fixed quote against an hourly estimate as though they were the same number has already made an error. The fixed quote contains a risk premium and the hourly estimate does not. If the project runs clean, you overpaid for insurance you did not need. That is how insurance works and it is not a scandal.

It also explains the behaviour each model produces. A supplier carrying overrun risk defends scope, because every change is a claim against their own margin. A supplier billing hours has no such pressure, which is comfortable right up to the point where nobody is incentivised to finish. Neither behaviour is bad faith. Both are what the contract pays for.

The research on what overruns actually look like

Here is where intuition fails. Most people model project risk as symmetric: it might come in a bit over, it might come in a bit under. The data says otherwise. Flyvbjerg, Budzier, Lee, Keil, Lunn and Bester studied 5,392 IT projects in The Empirical Reality of IT Project Cost Overruns and found that overruns follow a power-law distribution: many projects with small overruns, and a fat tail of projects with extreme ones.

Their conclusion is blunt. IT projects are far riskier in terms of cost than normally assumed, and a manager who assumes a normal distribution will badly underestimate how often a very large overrun happens. They attribute the shape to interdependency: components in a software system are coupled, so a problem in one can cascade into others rather than staying local.

The companion study is just as useful because it describes the ordinary case. In Overspend? Late? Failure?, Budzier and Flyvbjerg examined 1,355 public sector IT projects and report that the typical project had no cost overrun at all, while taking on average 24% longer than expected. Then the sentence that matters: a staggering 18% of all projects are outliers with cost overruns above 25%.

Put the two together and the practical picture is clear. Most software projects land near budget. A meaningful minority do not, and when they miss they can miss enormously. Schedule slips in the typical case; cost explodes in the tail. Any contract is a bet on which of those two worlds you end up in, and the tail is where all the money is.

Why fixed price is not the protection it looks like

A buyer reads the above and concludes they want fixed price, since the tail becomes somebody else's problem. That is right in principle and often wrong in practice, for a reason that has nothing to do with contract law.

A fixed price is only as good as the supplier's ability to absorb the bad case. If a small studio quotes a fixed price and lands in the 18%, the money to finish does not exist. What follows is not a cheerful absorption of loss. It is a change request argument, a quality collapse, a team quietly moved onto a better paying project, or an insolvency. You have transferred the risk to a party that cannot carry it, which means you have not transferred it.

The second problem is upstream. A fixed price requires a specification detailed enough to price, which means the expensive discovery work happens before anyone is committed to anything, usually unpaid, usually rushed, and usually by the party least incentivised to find the hard parts. Fixing that sequence is most of what we wrote about in how to scope a software project before anyone writes code.

And a fixed price prices the specification, not the outcome. Every discovery that the specification was wrong becomes a commercial event rather than an engineering one. On a project where the requirements are genuinely understood, that is fine. On one where they are not, you have bought a year of negotiation. The reasons requirements turn out to be wrong mid-build are set out in why software projects take so long.

Where hourly stops being fair

Hourly billing has the honest structure: you pay for work done, and nobody needs to guess. Its failure is not dishonesty, it is the absence of any party whose interest is in the project ending.

The practical fix for hourly is not a different contract, it is instrumentation. A burn rate the buyer can see weekly, a scope list with items that get closed rather than extended, and a standing right to stop at the end of any sprint. If a supplier resists all three, the objection is worth taking seriously, because those are the controls that make hourly safe and none of them cost anything to give.

The structure that actually works

Neither pure model fits the risk shape, because the risk is not uniform across a project. The unknowns cluster. Integration with a system nobody has documented, a migration from data nobody has audited, a performance requirement nobody has tested: that is where the tail lives, and it is usually a minority of the work.

So split the contract along that line:

• Pay hourly, capped, for a short discovery phase whose only deliverable is a specification good enough to price. Two to four weeks, and you keep the output whoever builds it.
• Fix the price on the parts that are genuinely known after that: the screens, the standard workflows, the reporting. This is usually most of the build.
• Keep the identified unknowns on time and materials, named explicitly, with a budget ceiling and a decision point when the ceiling is reached.
• Agree what happens at the ceiling before you need it. Stop, descope, or extend, decided in advance rather than during an argument.
• Bill against working software rather than dates, so a milestone cannot be reached by a progress report.
• Write the exit into the contract from the start: your repository, your accounts, your data, no migration project at the end.

That is a more complicated document than either pure model and it is a much shorter argument later. It puts fixed pricing where estimates are reliable and hourly where they are not, which is the only arrangement that matches what the research describes.

The integration clause is the one worth dwelling on, because it is the single most common source of tail risk we see, and the reasons are specific rather than mysterious. We went through them in what an API integration between two systems really costs.

One question that decides it

Ask whether you could write down, today, a test that proves the hardest part works. If you can, the requirements are understood well enough to fix a price, and you should, because the risk premium will be small and you will have bought certainty cheaply.

If you cannot, a fixed price is not protection. It is a bet that your supplier guessed well about something you both admit nobody understands yet, and the bet pays out in change requests. Buy the discovery first, then fix the price on what the discovery established.

Whichever you choose, the negotiation itself usually involves a procurement function with its own constraints that have nothing to do with your project, and knowing which levers are real there saves weeks. The sales side of that conversation is covered well in bdg-labs' piece on negotiating with procurement departments.

The honest limits

Two caveats on the numbers above, because they are easy to over-read. Both studies are of IT projects broadly, skewing large and, in the second case, entirely public sector. A twelve week internal tool is not drawn from the same distribution as a government programme, and the tail for small projects is almost certainly thinner. The shape of the finding transfers; the magnitudes should not be applied to a small build.

We also looked for research isolating failure rates by contract type, fixed price against time and materials, and did not find any we would cite. The vendor comparisons that exist are produced by parties selling one of the models. So the argument here rests on the risk distribution, which is well measured, rather than on a direct comparison of contract outcomes, which as far as we can tell has not been published. If the hardest part of your project is genuinely unknown, that is the finding to act on, and why software projects fail, and why the average is the wrong number is the companion to this one.