Fixed Price or Time and Materials? You're Choosing Who Owns the Tail Risk

Two numbers, from the same 4,677 software projects.

The median project came in at exactly its budget. Not close to it — on it. The mean project cost 80% more than estimated.

Most people's instinct is that one of those must be wrong. Neither is. The gap between them is the single most useful thing you can know before signing a development contract, and almost nobody who writes about contract models mentions it.

I've scoped and signed a lot of these engagements from both sides of the table. What follows is the version I'd want if I were buying.

The research everyone quotes, and what it actually says

You've seen the statistic that most software projects fail. It gets repeated in every agency pitch deck, usually sourced to something nobody has read.

The most rigorous dataset we have says something more interesting. Flyvbjerg, Budzier, Lee, Keil, Lunn and Bester published an analysis of 5,392 IT projects in the Journal of Management Information Systems — projects completed between 2002 and 2014, across 66 countries, totalling $56.5 billion. For 4,677 of them they had both the estimate and the final cost.

Cost overrun (actual ÷ estimated)	Value	What it means
Median	1.0	The typical project landed on budget
Mean	1.8	The average project cost 80% more
Standard deviation	8.5	Enormous — the spread dwarfs the average
Maximum	280.4	One project cost 280 times its estimate

That maximum is worth sitting with. It was a small workflow customisation, budgeted at $1,500. It finished at $425,000.

Their central finding is that IT cost overruns don't follow a normal distribution. They follow a power law — a large number of projects with small overruns, and a fat tail containing a few catastrophic ones. In the authors' words, managers are "unwittingly exposing their organizations to extreme risk by severely underestimating the probability of large cost overruns."

Two implications land immediately. First, the folklore is wrong in a specific way: most software projects are not disasters. The mode and median sit at roughly zero overrun. Second, and less comfortably, the average is not a planning number. When a distribution has a tail like this, the mean describes almost none of the projects in it. It's dragged upward by a handful of catastrophes.

Two honest caveats, both raised by the authors. Terminated projects are excluded, because organisations stop tracking things they cancel — and projects get cancelled when they're going badly. And firms willing to share performance data are probably the ones managing it well. Both mean the real distribution is likely worse than what was measured, not better.

So what does a contract model actually decide?

Here's the reframe. Every comparison article treats this as a question about price: which model costs less. On the median project, that's nearly the whole story, and T&M usually wins it.

But the median project isn't what a contract is for. Contracts exist for the tail.

A pricing model doesn't change the distribution. It decides who absorbs it. Fixed price moves the tail onto the vendor. Time and materials leaves it with you. That's the entire trade, and everything else — flexibility, transparency, agility — is downstream of it.

This also explains something you may have noticed: nearly every article ranking for this question is published by a development agency, and nearly all of them conclude that time and materials delivers better value. That conclusion isn't dishonest. On median-case reasoning it's correct. It's just that the median case is precisely the case where the client didn't need protection, and the model being recommended is the one where the vendor carries no tail risk at all.

Fixed price

What you're actually buying: insurance. You are paying someone to take the fat tail off your balance sheet.

What it costs: a premium, because that's how insurance works. Agencies commonly price 15–30% of contingency into fixed bids, and more where the scope is vague. On the median project — the one that would have landed on budget anyway — you have simply overpaid. That is not the agency cheating you. That's the product.

How it fails: three predictable ways, and they're worth naming because they're all the same failure.

• The change-order war. Once the price is fixed, every ambiguity becomes adversarial. You believe the login flow obviously included password reset. They believe it obviously didn't. Neither of you is lying; the brief just didn't say. From that point you are managing a contract rather than building a product.
• Silent quality erosion. When a fixed-price job runs long, the vendor's margin is what absorbs it. The pressure lands on whatever the contract doesn't explicitly measure — tests, error handling, documentation, the refactor that got deferred. You get the demo you specified and a codebase that costs more to own in year three.
• Scope calcification. The model punishes learning. Six weeks in you will understand your users better than you did on signing day, and the contract makes acting on that expensive. You end up building the thing you would have designed at your least informed moment.

When it genuinely is the right answer: the scope is properly specified, the work resembles something the vendor has shipped repeatedly, your organisation cannot absorb a budget surprise, or you have no capacity to manage the work week to week. That last one is underrated. Fixed price buys you a defined outcome without a project manager on your side. T&M without one is how budgets drift quietly.

Time and materials

What you're actually buying: the right to change your mind, and the median-case saving from not paying a risk premium.

What it costs: you own the tail. If the project is the one in the fat end of that distribution, it is your budget that discovers this, usually in month four.

How it fails:

• Nobody is incentivised to be efficient. Not through malice — through absence of pressure. In fixed price, every hour saved is the vendor's margin. In T&M, every hour spent is the vendor's revenue. Good agencies manage this with professionalism, which works right up until it's a difficult quarter.
• Drift is invisible until it's large. Nothing ever exceeds a budget on a T&M project, because there isn't one. There's a burn rate, and burn rates don't trigger alarms the way an overrun does. This is the model's real danger and it is the opposite of dramatic.
• It quietly assumes you'll manage it. T&M works beautifully with an engaged product owner making weekly prioritisation calls. Without one, you're funding an open-ended engagement and hoping.

When it genuinely is the right answer: the scope will legitimately change as you learn, you have someone competent steering it weekly, and a 50% overrun would be annoying rather than existential.

Retainer

Included because it's usually compared alongside the other two, which is a category error worth correcting.

A retainer doesn't price a project. It prices capacity — a standing claim on a certain amount of a team's time. That makes it excellent for continuous improvement, ongoing product work, and support, and a poor fit for a defined build with an end date.

How it fails: you pay for availability you don't consume, or you consume more than you pay for and the relationship sours. Both are symptoms of the same thing — a retainer with no definition of what "used" means. If yours doesn't specify hours, response times, or a rollover rule, it isn't an agreement, it's a subscription with vibes.

The mechanism behind the tail, and how to attack it

The Flyvbjerg paper doesn't stop at describing the distribution. It proposes a cause, and demonstrates it in simulation: interdependence between technological components. A problem in one component cascades into the components coupled to it, which cascade into theirs. Small local trouble becomes a systemic overrun. Their recommendation to managers is to identify the components with high interdependency and resource them deliberately.

Translate that out of the academic register and it is unusually actionable, because it tells you the tail is not evenly distributed across your project. It concentrates in a small number of places, and you can usually name them before you start:

• Anything that has to talk to a system you don't control — a legacy ERP, a bank's API, a government portal, a partner's data feed.
• Anything requiring data migration out of a system nobody fully understands any more.
• Anything where a regulator, an auditor, or a third party gets to say no late in the process.
• Anything depending on a vendor's documentation being accurate. It frequently isn't, and you find out by building against it.

If your project contains none of these, your tail risk is genuinely modest and paying a large fixed-price premium is poor value. If it contains three, no contract model will save you — you need to go and find out how bad the worst one is before anyone quotes the whole build.

What we actually recommend, and why it isn't a fudge

Split the engagement at the point where the uncertainty lives.

Phase one: a fixed-price discovery. Small, capped, days rather than months. Its job is not to produce documents. It is to reach into the specific components you just listed and establish what's actually there — call the API, inspect the legacy schema, confirm the integration behaves the way the documentation claims. The deliverable is a technical plan, a de-risked scope, and a defensible estimate for phase two.

Phase two: priced with what you now know. If discovery shrank the uncertainty, fixed price becomes reasonable, because the vendor's premium falls when their risk does. If discovery revealed the tail is real and unavoidable, T&M with a not-to-exceed ceiling and a monthly review is the honest structure — you keep the flexibility, and the ceiling puts a bound on the tail instead of pretending it isn't there.

This isn't splitting the difference. It's the structure the research points at: the paper says overruns are generated by interdependent components, so you spend a small, bounded amount of money attacking exactly those components before committing to the large number. You are not choosing a contract model. You are buying information that makes the choice cheap.

It also functions as a low-cost audition. You find out how a vendor works, how they communicate bad news, and whether their estimates survive contact with your systems — for a fraction of the cost of finding out during the build. We've had discovery phases end with us telling a client the project shouldn't proceed. That's a good outcome for both sides, and it's only available if the first cheque is small.

Choosing, in one table

If this is true	Model	Because
Scope genuinely fixed, vendor has built it before	Fixed price	Their risk is low, so the premium should be too
A budget surprise would be existential	Fixed price	You're buying insurance; pay for it deliberately
Nobody on your side can steer it weekly	Fixed price	T&M without an owner is unbounded
Scope will change as you learn, and you have an owner	T&M, with a ceiling	You keep optionality and skip the premium
Ongoing product work with no end date	Retainer	You're buying capacity, not an outcome
Two or more high-interdependency unknowns	Fixed-price discovery first	Price the tail down before pricing the build
Vendor quotes a fixed price without asking about your integrations	None of them	They haven't priced the risk, so they'll manage it out of your quality

Four questions that tell you what you're dealing with

1. "What's in your contingency, and what happens to it if we don't need it?" A fixed-price bid contains a risk premium. A vendor who can discuss it openly has priced your project. One who denies there is one has either not thought about it or is hoping you won't.
2. "Which part of this are you least certain about?" The answer names your tail. Anyone who says "none of it" has not read your integration requirements.
3. "What specifically counts as a change request?" Ask before signing, not during. If the boundary can't be described in a couple of sentences, it will be litigated later, while your project waits.
4. "On T&M, what stops this running over?" Acceptable answers involve a ceiling, a cadence, and a named person. "We'll keep you updated" is not a control.

The short version

• The median software project lands on budget. The mean overruns by 80%. Same dataset. The difference is a fat tail of catastrophes, not a general tendency to slip.
• Your contract doesn't shrink that tail. It assigns it. Fixed price gives it to the vendor and charges you a premium. T&M leaves it with you and doesn't.
• Judge the premium against your own tail risk — which lives in integrations, migrations, third parties, and anything you don't control.
• When the tail is real, buy information first. A small fixed-price discovery aimed at the risky components makes the second contract cheaper under either model.

Working out how to structure an engagement? Tell us what you're building and which systems it has to touch, and we'll tell you where your tail risk actually sits and which model we'd sign if we were you — including when that's a fixed price from someone else. You may also want the honest breakdown of what custom builds cost, or what to check before hiring an agency. When you're ready, put the question to us directly.