Why fixed price is not the win the client thinks it is
I am a consultant who works exclusively on Time&Materials projects. You might say I have a vested interest in arguing against fixed price contracts. You should weigh that accordingly when reading this.
But here is the thing: I am going to make the argument anyway, because I think it holds up regardless of who is making it.
"Fixed price gives us certainty." It is a message I can still sometimes hear from clients at the start of a procurement conversation. To be fair, not as much as I used to, but the sentiment is still out there. And it is completely understandable. You are about to commit significant budget to a complex project. You want to know what you are getting and what it will cost. Fixed price feels like the instrument that delivers that. A number that is agreed upfront and signed in a contract. That’s what certainty looks like.
Except it is not certainty. It is the appearance of certainty. And those two things behave very differently once a project is underway.
You are paying for the risk either way
You might know this already: vendors are not absorbing your project risk under a fixed price contract - they are pricing it. Before the contract is signed, a vendor has to estimate the cost of delivering everything in scope - including all the things that might go wrong, all the requirements that might evolve, and all the complexity that is not yet visible. That uncertainty gets baked into the price as contingency. You pay for it upfront, whether or not it ever materialises.
In a straightforward, well-defined project with stable requirements, that contingency might be modest. In a complex project - one with multiple stakeholders, evolving requirements, a changing system landscape, or anything where the full scope is not knowable at contract signature - that contingency can be substantial. And if the project runs smoothly, the vendor pockets the difference. You have essentially pre-purchased insurance - without knowing it - for a risk that never arrived.
What fixed price does to the relationship
Beyond the financial mechanics, fixed price changes something more fundamental: it changes the incentive structure between client and vendor.
On a fixed price engagement, every change request is a contractual event. The client wants something adjusted. The vendor has to evaluate whether that falls within scope or outside it. If it falls outside, someone has to pay for it - and now you are negotiating, not collaborating. Change becomes adversarial by design.
This has a quieter consequence that might go unnoticed. Teams stop suggesting better approaches. If a developer spots a more suitable solution halfway through the build, they face a dilemma: the better solution is different from what was scoped, and different means a conversation about money. So the suggestion does not get made. The client gets what was specified on paper, not what would have worked best. Innovation basically gets priced out of the room.
The complexity problem
Fixed price can work. If you are commissioning something genuinely well-defined - a specific piece of functionality with stable requirements and a short delivery window - the model has its place. The problem is when clients reach for fixed price terms precisely when projects are complex and uncertain, which is exactly when the model is least suited to the work.
Complex projects have requirements that evolve as understanding deepens. Stakeholders learn things during delivery that change what they need. Systems reveal constraints that were not visible at the start. This is not a failure of planning - it is the nature of complex work. Fixed price does not make that complexity go away. It just creates a contractual structure that is poorly equipped to handle it.
The choices that typically emerge seems almost predictable:
- scope gets squeezed to protect the original number, or
- quality quietly erodes to protect the timeline, or
- the project runs over anyway and everyone argues about who owes what.
None of these are good outcomes - and none of them represent the certainty the client thought they were buying.
What problem(s) are they trying to solve?
Most clients reach for fixed price because they are trying to solve something real. For example, budget predictability. Or protection against a vendor who runs the clock indefinitely. Maybe they've been burned in the past - who knows? Those are legitimate concerns, and they deserve legitimate answers.
But it is worth being precise about which problem you are actually trying to solve, because fixed price addresses some of them less well than it appears, and others not at all.
What are we trying to protect against - runaway cost, or runaway scope? They are related, but they are not the same problem. Fixed price puts a ceiling on cost in theory, but it does so by freezing scope - and frozen scope on a complex project is often a fiction that holds until the first significant discovery.
It is a bit like planning a road trip and insisting you will not deviate from the original route - no matter what. Fine in principle, until there is a collapsed bridge halfway there. At that point, the question is not whether to change or stay the course. It is whether your plan gives you a sensible way to do it, or forces you to argue about who pays for the detour while the project sits at the side of the road.
If the real concern is cost, there are ways to address that without locking scope in a way that creates problems downstream. This might include adopting an “MVP”-mindset where the simplest possible version of the product - the Minimum Viable Product - guides decision making.
Who carries the risk if requirements change - and is that the right answer? Under fixed price, the client carries the risk of getting requirements wrong upfront, and the vendor carries the risk of estimating them poorly. If requirements do change - and on any complex project, they will - the question of who pays becomes a negotiation, not a collaboration. Is that the dynamic you want to be navigating mid-project?
Does fixed price actually give us certainty, or does it give us a number? A signed contract with a fixed figure is not the same thing as a predictable outcome. If scope gets squeezed to protect the budget, or quality degrades to protect the timeline, you have your number - and a system that does not do quite what you needed. That is just a different kind of disappointment masquerading as certainty.
What happens to the relationship when the first change request lands? Because it will land. The question is whether it arrives as a shared problem to solve, or as a contractual dispute to resolve. Fixed price tends to push it toward the latter.
None of this means the concerns that drive clients toward fixed price are wrong. They are not. The instinct to want predictability and accountability is entirely reasonable. The question is whether fixed price is actually the instrument that delivers it - or whether it delivers the appearance of it, which is a different thing entirely.