Fixed price or time and materials? Who actually carries the risk

Short answer: fixed price is the right model for small, repeatable work whose scope can genuinely be written down, while work that involves discovery, integration or requirements that firm up along the way is safer under time and materials or a capped variant. A fixed-price contract does not remove risk. It either prices the risk in (expensive but honest) or buries it somewhere the supplier ignored in order to win the work, and in that case the bill comes out of quality. The question worth asking is not which model is cheaper. It is where on the uncertainty curve you are making the commitment, and who pays when the estimate turns out to be wrong.

What the two models actually say

The cleanest definition of time and materials sits in US federal procurement rules. FAR 16.601 defines it as acquiring work on the basis of "direct labor hours at specified fixed hourly rates" plus "actual cost for materials", and states the condition for using it plainly: only when it is not possible at the time of placing the contract to estimate accurately the extent or duration of the work. The same section adds two things buyers should read twice. The contract must include a ceiling price, which the contractor exceeds at its own risk. And a candid warning: this model "provides no positive profit incentive to the contractor for cost control or labor efficiency", so buyer-side oversight is required.

Fixed price does the reverse. The deliverable is defined, the amount is locked, and deviation comes out of the supplier's margin. The difference between the two is not a price difference, it is a difference in where the risk sits. Move the risk and behaviour moves with it.

Your estimate is at its widest on the day you sign

The numerical ground for this argument is the cone of uncertainty, which Steve McConnell developed from Barry Boehm's 1981 curve. Estimates made at initial concept can be off by a factor of 4 on the high side and a factor of 4 on the low side (0.25x), a total span of 16x from lowest to highest. McConnell makes two points that get skipped. The cone shows the best case: that is how far skilled estimators miss, doing worse is easy, and doing better is luck rather than skill. And the cone does not narrow by itself. If the project is not making the decisions that remove variability, the shape is not a cone but a cloud that persists to the end; the problem is not that estimates fail to converge, it is that the project fails to converge.

The practical consequence runs against instinct. Committing early does not buy predictability, it destroys it. McConnell puts a 2x to 4x error band on commitments made at initial concept or product definition, and places the first meaningful commitment around 30% into the project. A fixed-price software contract does precisely the opposite: the signature goes on the page at the widest part of the cone.

Fixed price relocates risk rather than removing it

The supplier has two options. Load the uncertainty into the price as a premium, in which case the bid looks expensive next to the competition and usually loses. Or leave the premium out. In the second case, as the project runs on, the supplier starts facing a real loss and behaviour turns defensive: the cheapest reading of a half-specified requirement wins, scope discussions become a revenue line, and time budgeted for testing and design is the first thing cut.

This is a documented mechanism, not a suspicion. The 2017 study by Jørgensen, Mohagheghi and Grimstad in the International Journal of Project Management reaches the same conclusion across two separate datasets: use of fixed-price contracts is associated with a higher risk of project failure than time-and-materials types of contract. The authors explain it as opportunistic behaviour and moral hazard. When the price is fixed for a delivery that is only partly specified, the loosely specified requirements receive low priority on the supplier side, and the effect gets sharper when the supplier has underestimated badly enough to face a substantial financial loss. The cut corners do not disappear either, they are deferred and come back during maintenance as technical debt.

A 35-project dataset from Norway

Mohagheghi and Jørgensen's 2017 paper in the Journal of Software examined 35 software projects across 11 public-sector organisations in Norway, based on 107 interviews conducted between May 2015 and February 2016. Contract types broke down as fixed price (4), time and materials (12), risk sharing or target price (15) and other (2). The researchers treat risk-sharing contracts that carry an upper limit (9 projects) as effectively fixed price, since the financial loss in a large overrun still lands on the supplier. On that classification, 38% of fixed-price projects were rated successful, against 83% of time-and-materials projects.

The sample is small, so those figures are a signal rather than proof. The more useful part is the study's note on why the gap exists: clients choosing fixed price tended to focus more strongly on low price and more weakly on evaluating supplier competence during selection. The model does not act alone, it arrives bundled with a purchasing habit. Jørgensen's 2016 survey in Information and Software Technology points the same way, finding that fixed-price projects, and projects where supplier selection leaned hard on low price, were less successful at delivering client benefits.

The contract model sets the delivery rhythm

In the same 35 projects, success tracked delivery frequency. Projects with a single delivery into production had a 64% success rate (12 projects), those with four or fewer deliveries 77% (13 projects), and those with more than four deliveries 100% (8 projects). All eight agile projects that combined flexible scope with frequent delivery succeeded. Small numbers again, but a consistent direction.

The link to the contract is direct. Under a fixed price, acceptance and payment usually hang on one large delivery, because accepting intermediate deliveries reopens the scope conversation. The same study observes that fixed-price projects were less likely to deliver frequently or to run benefit management during execution. Whatever model you sign, tying the payment schedule to deliveries rather than calendar months is the strongest lever you hold.

The models in between: caps, target prices, phases

The debate is usually framed as two extremes, while the things actually used in practice sit in the middle.

• Capped time and materials. Work is billed by the hour against a not-to-exceed ceiling, with a written rule for what happens as the ceiling approaches. Budget discipline stays intact, scope flexibility survives. Corporate approval processes generally wave it through as readily as a fixed sum.
• Target price with pain and gain sharing. A target amount is agreed, and coming in under or over it is shared between the parties at a set ratio. The detail that matters is whether the sharing has an upper limit: if it does, the contract behaves like fixed price regardless of what it is called. Jørgensen's paper at the CHASE workshop at ICSE 2017 isolates exactly this variable, which is to say the deciding factor is not the contract's label but the supplier's exposure to financial loss.
• Phased contracting. A small, fixed-price discovery phase (one to three weeks, producing a written scope, architecture decisions, interface sketches and an estimate range), followed by capped time and materials for the build. This is what narrowing the cone costs, and it can be bought as a separate line item. A supplier reluctant to sell that phase is telling you something.
• Fixed price per increment. A separate price for each package, with scope frozen only inside that package. You give up some long-range predictability and get a real delivery every couple of weeks in exchange.

Taking scope changes out of the negotiation

PMI's 2018 Pulse of the Profession reported that 52% of projects completed in the previous twelve months experienced scope creep, up from 43% five years earlier. Change is the normal condition, not the exception. That is the exhausting part of fixed price: every change opens a fresh negotiation round, and both sides start defending position instead of discussing the product.

Two clauses Jeff Sutherland proposed for agile contracts break the loop. "Change for Free": as long as the total amount of work does not change, the client can make any change at no extra charge, with a lower-priority item dropping off the list when a new one comes on. "Money for Nothing": if the client decides the remaining backlog is no longer worth building, they can close the contract early by paying 20% of the remaining value. Together they hold budget and date fixed while leaving scope variable. Budget and date are what management wants pinned down; the order of scope should have been the client's call all along.

What makes time and materials defensible

The FAR warning is fair: the model gives the supplier no built-in incentive to work efficiently. The contract and the working rhythm have to supply that incentive instead. The minimum set that works:

• A weekly report of hours spent and a refreshed estimate for the work remaining, with hourly rates itemised by role.
• A written estimate range and acceptance criteria before each increment. With no acceptance criteria, the invoice argument starts after the work is finished.
• Backlog priority contractually on the client side. The one real guarantee time and materials gives you is the right to stop whenever you choose.
• Named people in the team, with an obligation to notify you when they change.
• Automated evidence: deliveries passing through a deployment pipeline, and production behaviour reported through observability and SLOs. That is what closes the gap between a claim that something is done and proof of it.

Clauses to include whichever model you sign

Acceptance criteria and a definition of done. A delivery rhythm, with the payment schedule attached to it. A warranty period, and a written line between fixing a defect and building a new request. Assignment of economic rights, delivery of the source code and where a buildable copy is kept, which we covered in detail in our post on source code ownership and escrow. Whose name the cloud accounts, domain and payment provider are registered under. A change control procedure and who approves changes. An exit clause: when the relationship ends, what gets handed over, in what format, within how many days.

Where fixed price genuinely is the right answer

Work whose scope fits on a page in one sitting, with a small integration surface and a precedent behind it: a defined design package, a scoped data migration, a penetration test with written scope, a reporting module of known size. Fixed price makes both sides comfortable there. On the other hand, jobs like modernising a legacy system or connecting several systems carry uncertainty in a place neither you nor the supplier can see yet, because the real surprises live in the data on the other side of the interface.

A first step that fits in this week

Three things. One: open the proposal on your desk and mark how many scope items are described by a single-sentence heading. Under a fixed price, those lines are the negotiation list for the next six months. Two: before asking for a price on the main build, buy a small fixed-price discovery phase whose output is a written scope, architecture decisions and an estimate range. Three: attach the payment schedule to deliveries rather than to calendar months.

Wedevit sits on the buyer's side of this table because we sell neither a product nor day rates: we normalise incoming bids onto the same scope definition and compare them, review the technical annexes of the contract (acceptance criteria, rights assignment, exit clause), and verify deliveries against criteria written before the work started. The real job before evaluating a proposal is getting the scope into a state where a price can be asked for at all.