A CIO receives two bids for the same platform. The first: £1.9 million, fixed price, nine months, scope per the attached specification. The second: time and materials, estimated at £1.4 million, explicitly flagged as the midpoint of a £1.2m–£1.7m range. The investment committee picks the first, and the minutes record why: it “transfers risk to the supplier and gives budget certainty”. Twenty months later the programme closes at £2.5 million — base price plus eleven change requests, none of which was negotiated under competitive pressure, because halfway through a build there is no alternative vendor.
This pattern recurs across UK and US enterprise IT often enough that it has stopped being an anecdote and become a template. Its cause is neither vendor dishonesty nor client incompetence. Its cause is a price for risk that nobody decomposed before signing. This article argues something many buyers of software services will dispute: for the same delivery, fixed-price costs more than time and materials, because the vendor prices risk with a buffer and the client pays that buffer in one hundred per cent of cases while the risk materialises in a minority of them. Fixed-price is not a transfer of risk. It is the purchase of an insurance policy — and like every policy, it costs more than the expected value of the loss, because otherwise nobody would sell it.
What is the client actually buying with a fixed price?
It is worth naming precisely what crosses the table when a fixed-price contract is signed. The risk that the system will not work does not cross. The risk that the solution will not answer the business need does not cross. The risk of delay does not cross in any commercially meaningful sense — liquidated damages recover a fraction of what it costs when a campaign fails to launch on schedule. Exactly one thing crosses: the risk of variance in the cost of construction.
That is a real good and there is no point deprecating it. A finance director who has to close the year without a variance against capital budget is buying predictability, and predictability is worth money. The problem starts where that value is never set against its price. Nobody buys insurance without asking about the premium. In IT contracts the premium is folded into a single number on the front page of a proposal and is essentially never shown separately.
The second thing a client buys unintentionally is a change in the relationship, from partner to counterparty in a scope dispute. Under time and materials, the question “is this inside the contract?” carries no economic weight — the work is billed either way. Under a fixed price it is the only question that matters, because the answer determines whose margin takes the hit. The entire apparatus that grows around that answer — acceptance protocols, review boards, expert opinions, escalations — is a cost that simply does not exist under time and materials.
How does a vendor actually price a fixed-price engagement?
A fixed-price quote has two layers, and the client sees only their sum. The first is expected cost — the best estimate of effort multiplied by the cost of an hour. The second is the risk premium — a buffer covering scenarios worse than expected.
The size of that premium is not a question of greed but of probability distribution. A vendor pricing at expected cost breaks even on half the projects and loses on the other half under a symmetric error distribution — and the distribution in software construction is not symmetric. It is right-skewed, because a project can take twice as long as estimated but cannot take half as long. To make money at all, a vendor has to price meaningfully above the expected value.
Orders of magnitude worth using as a starting point for the conversation, with the caveat that every vendor computes them differently and rarely discloses them:
- well-specified scope, familiar technology, a team experienced in the domain: a buffer of 15–25% over expected cost;
- scope described at the level of functional requirements, with no technical design: 30–50%;
- scope described as business outcomes, with integrations into client systems of unknown condition: 60–100% and beyond — above a certain point a serious vendor declines to quote a fixed price rather than issue a number it cannot defend.
On top of the risk premium sits a cost-of-capital and cash-flow premium: with milestone-based billing the vendor funds the work from its own balance sheet for months. In a positive interest rate environment that is several more percentage points that somebody has to pay.
The sum of those components is the price of the policy. The client pays it every time. The risk it protects against materialises — depending on the class of project — in perhaps thirty or forty per cent of cases. That asymmetry is the core of this article’s thesis, and simultaneously the reason a market for fixed-price services exists at all: selling insurance is profitable.
Why does the worst-priced bid win a fixed-price tender?
The phenomenon has a name and a literature: the winner’s curse, first formalised by Capen, Clapp and Campbell in 1971 while studying competitive bidding for offshore oil leases. When several bidders price the same good of uncertain value and the lowest price wins, the winner is systematically the one whose estimate erred furthest downward. Not the bidder who best understands the problem — the one who most underestimated its difficulty, or most needed the work.
In software tenders the mechanism bites especially hard, because the spread of estimates between competent vendors quoting the same scope routinely reaches a factor of two. At that spread, selecting the lowest bid is close to equivalent to selecting the largest estimation error in the room.
The consequence is not a cheaper project. The consequence is a vendor under margin pressure from month three, whose available levers are: staffing the work with cheaper, less experienced people; compressing everything invisible at acceptance, which means testing, documentation and code quality; and interpreting scope boundaries aggressively so as much as possible falls into change requests. All three are rational from the vendor’s position, and the client pays for all three — just later, and in a different currency. The third route is the most expensive of them, and its economics deserve their own treatment.
What do change requests actually cost?
A change request on a fixed-price engagement is a transaction concluded in conditions where one party has no alternative. At signature the client had three bidders and full negotiating power. In month six it has one vendor that knows the codebase, holds a team with context, and whose replacement would mean several months of delay plus the cost of knowledge transfer. Negotiating power has moved entirely to the other side of the table.
The effect shows up in the rates. Work priced inside a change request is routinely billed tens of per cent above the base day rate from the original bid — not because it costs more to build, but because there is nothing to benchmark it against. Add the cost of the process itself: drafting, pricing, negotiating, approving and executing a contract variation typically consumes several calendar weeks, during which scope is frozen and the team runs at half throughput or works on something else.
The third cost is the most insidious: pressure not to raise changes at all. If every change is expensive, slow and adversarial, the organisation learns to avoid them. The result is a system delivered exactly as specified twenty months earlier — that is, against the weakest understanding of the need in the entire project lifecycle, because it was formed before any contact with working software. Conformance to specification and business usefulness are two different things, and fixed-price optimises the first.
What does a specification precise enough to price actually cost?
A fixed price requires scope described precisely enough to quote and precisely enough to settle an acceptance dispute. That is not free, and the cost almost never makes it into the comparison between models.
Producing a specification at the level that supports a credible fixed quote — process analysis, functional and non-functional requirements, integration design, acceptance criteria — typically runs to 8–15% of project value, spent before delivery starts. On a £2 million programme that is £160,000–£300,000 and two to four calendar months.
Worse than the amount is when the work happens. The specification is produced at the point of maximum ignorance in the whole lifecycle: before the first working screen, before the first confrontation with the real state of the systems it must connect to, before the first user reaction. You are buying precision of description exactly where you do not yet have knowledge — and you pay for that precision twice: once to produce it, and again in every change request that exists because the description was written too early.
The same mechanism, one level down at individual task granularity, is what we describe in story point estimation is decision theater: precision in an estimate made before the knowledge exists does not convert into precision in the outcome, however much effort goes into it.
Does time and materials solve the problem, or just move it to the client?
Honesty requires stating plainly that time and materials is neither free nor free of pathologies. It moves cost-variance risk onto the client and demands a capability not every organisation has.
Its own failure modes are real. The vendor has no economic incentive to finish sooner — the longer it runs, the more it bills. Without discipline on the client side scope inflates, because any idea can be added to the backlog without a negotiation. Without visibility into actual progress the client pays for time rather than outcome and learns about trouble late.
The decisive difference lies in the cost of controlling those pathologies. Under time and materials the control mechanisms are cheap and non-adversarial: a fortnightly demonstration of working software, an open backlog with client-owned priorities, a short notice period, a hard monthly spend cap. None of them requires arbitration or an expert opinion. Under a fixed price the control mechanism is the acceptance protocol and the argument over scope interpretation — an expensive, slow, relationship-damaging instrument that by construction assumes one party must lose.
So the conclusion is not “time and materials is better”. It is that both models have misaligned incentives and differ in how expensive those misalignments are to control. A client that can steer delivery — has a product owner with a real mandate, can prioritise, and looks at working software every two weeks — controls time and materials cheaply. A client without that capability will not control any model, and for them the fixed-price premium can be a fair price for outsourcing management itself.
When is a fixed price genuinely the right choice?
This article’s thesis is not “never sign fixed-price”. It is “price the premium before you sign”. There are configurations where a fixed price is the correct decision, and not merely for lack of an alternative.
Closed, short, repeatable scope. A data migration with a known schema, deployment of a standard module, an integration against a documented third-party API. Variance is low, so the premium is low, and the client’s governance cost disappears. On engagements of a few weeks, the premium is frequently smaller than the cost of monthly oversight.
An organisation with no delivery-steering capability. If nobody on the client side can make weekly priority calls, time and materials will produce a worse outcome regardless of price. The fixed-price premium is then a purchase of management, not merely of predictability.
Public procurement and internal procedures that mandate a price. There the decision sits outside this analysis. The sensible move is not to fight the model but to narrow the scope of any single procurement to the genuinely predictable part and carve the rest into a separate route — which is precisely how the better-run framework call-offs under UK public procurement are structured.
A hard budget constraint. If overrunning by 15% means not “a difficult conversation” but loss of funding and closure of the initiative, predictability carries option value beyond expected-value arithmetic. That is worth naming explicitly and paying for deliberately.
Which hybrid models outperform both extremes?
In practice the best results come from structures that split risk rather than transferring it wholesale. Four of them work reliably enough to be worth knowing by name.
Fixed price per increment, not per programme. Scope divided into two- to three-month stages, each priced as a fixed sum once the previous one closes. Estimate variance over a short horizon is several times smaller, so the premium falls; the client keeps predictability inside the budget period plus an exit point after every stage.
Time and materials with a hard cap and shared savings. Billing against actual work, with a ceiling above which the vendor absorbs the overrun, and a split of the difference when it comes in under. That second half matters — without it, a cap behaves like a fixed price and attracts the same premium.
Target cost with pain/gain share. The parties agree a target cost and a percentage split of the deviation in both directions, commonly 50/50. This moves part of the risk to the vendor without forcing it to price the worst case, and it is the only structure in which both sides profit from the same event.
Fixed price for an outcome, not a scope. Payment tied to a measurable business result rather than delivery of a feature list. Hard to construct and dependent on trust, but it eliminates the scope dispute at source, because scope stops being the subject of the contract.
What all four share: they shorten the horizon over which anyone has to forecast. The risk premium grows with the length and uncertainty of that horizon, so shortening it is the cheapest lever available to the buyer.
How do you compare two bids in different models so the comparison means something?
Setting a fixed price against a time-and-materials estimate compares a certain number with an uncertain one, and the certain one always wins — regardless of which is actually cheaper. For the comparison to carry information, both sides have to be brought to total cost of ownership.
To the fixed-price bid, add: the cost of producing a specification good enough to price and accept against; the expected value of change requests (a starting point: 15–30% of base value on engagements longer than six months, more where scope is immature); the cost of the acceptance process and any disputes; and the cost of delays caused by scope freezing while variations are negotiated.
To the time and materials bid, add: your own delivery governance cost (product owner, reviews, prioritisation — realistically 5–12% of project value); the risk of overrunning the estimate, expressed as a range rather than a point; and the cost of building control mechanisms if they do not yet exist.
Only those two totals are comparable. In practice, once the comparison is done honestly, fixed-price comes out more expensive on most engagements longer than six months whose scope anyone at the table would call “reasonably clear” — and rarely comes out more expensive on short, genuinely closed pieces of work. It is the same shape of calculation we apply to when body leasing stops paying off: a cost model has to be evaluated across the full horizon, not against the first quarter’s invoice.
What does the contract model decision map look like?
| Project characteristics | Estimate variance | Client’s delivery-steering capability | Recommended model | Main risk of getting it wrong |
|---|---|---|---|---|
| Closed scope, under 3 months, familiar technology | low | any | Fixed price for the whole | Overpayment is small here; the risk is decision latency rather than the model |
| Product development, horizon beyond 12 months, evolving scope | high | high | Time and materials with a monthly cap | Fixed price: a 30–50% premium plus change requests priced without competition |
| System implementation, 6–12 months, requirements known, integrations uncertain | medium | medium | Fixed price per increment, 2–3 month stages | One price for the whole: premium calculated against the worst integration scenario |
| Budget-critical initiative, overrun means loss of funding | any | any | Fixed price, or T&M with a hard cap | Uncapped T&M: losing the funding costs more than the premium |
| Client with no product owner holding a real mandate | any | low | Fixed price, or build the capability first | T&M: scope inflates, nobody prioritises, cost grows uncontrolled |
| Public procurement with a mandated price | any | any | Fixed price on a narrowed, predictable scope | Wrapping the unpredictable part into the same procurement — premium and disputes guaranteed |
How do you run this analysis before your next decision?
The calculation fits inside a week and needs nothing beyond access to your own project history.
Step 1 — measure your own variance. Take the last five closed projects and compare original cost against final cost, counting variations and change requests. The median of that deviation is your real variance, and simultaneously what the vendor is pricing into the premium. If it comes out at 40%, a fixed-price bid carrying a 30% buffer is cheap from where you sit.
Step 2 — compute your historical change-request share. Across fixed-price engagements from the last three years: what percentage of final value was contract variations? That number, added to the base price, is your real price for the model — and it is what should be compared against a time-and-materials estimate.
Step 3 — assess your delivery capability honestly. Is there a person with a mandate to prioritise? Do you look at working software more often than once a quarter? Can you say “we are not doing that”? Three noes mean the fixed-price premium is a fair price for you, not a loss.
Step 4 — ask the vendor to decompose the quote. A serious vendor can show expected cost and risk buffer separately, together with the assumptions the buffer rests on. A refusal to decompose is itself information. Working through specific assumptions tends to reduce the premium more than any amount of haggling over the headline number, because some risks the client can absorb more cheaply than the vendor — guaranteeing test environment availability, or a 48-hour decision turnaround, for example.
Step 5 — consider shortening the horizon instead of changing the model. Before choosing between the two extremes, check whether the scope can be split into separately priced stages. That usually saves more than winning a few per cent off the total.
Key takeaways
A fixed price does not transfer risk — it sells a policy against the budgetary consequences of risk, and like every policy it costs more than the expected value of the loss. The client pays the premium in one hundred per cent of cases and draws on the cover in a minority of them. That does not make the model bad; it makes it a financial product to be priced before purchase, rather than a default contracting posture chosen because it “gives certainty”.
Three mechanisms make the arithmetic worse than the cover page suggests: a risk premium that scales with scope uncertainty, a winner’s curse that rewards the worst estimate in a tender, and change-request economics negotiated in conditions where the client has no alternative. On top sits the cost of a specification produced at the point of maximum ignorance.
The practical conclusion is not “switch to time and materials”. It is: shorten the horizon over which anyone has to forecast. A fixed price for a two-month increment carries a premium several times lower than a fixed price for a nine-month programme, while preserving predictability inside the budget period. If you want to run this calculation against your own data before signing the next contract, get in touch — our Software Development team delivers under all three models and can show where the risk premium sits in your specific case.