Fixed-Scope Contracts for Enterprise Work: Where They Work and Where They Don't

Procurement teams at large enterprises tend to have a strong institutional preference for fixed-price contracts, for a reason that makes complete sense from where they sit: fixed price transfers budget risk to the vendor, and budget risk is the thing a procurement function is measured on containing. The problem is that this preference gets applied to a category of work — novel software builds — where fixed price and fixed scope are not the same thing, and treating them as interchangeable is where a large fraction of enterprise engagements start to go wrong before any code gets written.

Fixed scope means the requirements are locked. Fixed price means the number on the invoice is locked. You can have either without the other, and the combination you actually want depends entirely on how well-understood the problem is at the time you're signing.

Fixed price plus fixed scope works when the unknowns are genuinely small. A well-specified integration with a well-documented API, a migration between two systems whose data models you've already fully mapped, a feature build against an existing, stable architecture — these are situations where the risk is low enough that a vendor can reasonably absorb it, and where fixed price gives the client real budget certainty without anyone eating unfair risk. We take engagements like this on fixed-price terms without hesitation, because the estimate underneath it is actually load-bearing.

Fixed price plus fixed scope is where most rebuild disasters start. A greenfield platform rebuild against a fifteen-year-old legacy system almost never has small unknowns — the whole premise of the discovery phase we run beforehand is that the unknowns are large and worth finding before committing to a number. When a vendor agrees to fixed price and fixed scope on a project like this anyway, one of two things is happening: they've padded the estimate heavily enough to self-insure against the unknowns, which means the client is paying for risk that might not materialize, or they haven't padded it, and the risk gets absorbed later as scope cuts, quality shortcuts, or a change-order fight that damages the relationship right when trust matters most.

The structure we actually recommend for platform rebuilds is fixed price per phase, with scope re-confirmed at each phase boundary. Discovery is fixed price and fixed scope — it's short, its deliverables are well-defined, and the risk is genuinely bounded. The build that follows is priced in phases tied to the architecture established during discovery, typically four-to-six-week increments, each with its own fixed price based on what's actually known at that point, not what was guessed nine months earlier. This gives the client the budget predictability they need for each individual commitment, without forcing anyone to pretend they can price nine months of unknown-unknowns in week one.

Change control has to be a fast, cheap conversation, not a negotiation. The reason fixed-scope contracts develop a bad reputation is usually change-order friction — every adjustment becomes a multi-week negotiation that damages trust and slows delivery. We build change control into the contract structure itself: scope adjustments within a phase get resolved through a same-week conversation with pre-agreed pricing logic, not a renegotiation from scratch. The goal is that discovering a requirement was wrong feels like a normal Tuesday, not a crisis.

Time and materials still has a place, and it's not a dirty word. For work where the goal is genuinely exploratory — a proof of concept, a spike into whether an approach is viable at all — time and materials is the honest structure, because pretending to fix scope on genuinely open-ended work just moves the dishonesty into padding. We use it there, transparently, and we say so upfront rather than dressing it up as something else.

The underlying principle is simple even though the industry often obscures it: price certainty and scope certainty both cost something, and that cost has to be paid by someone. The question worth asking any vendor isn't "is this fixed price" — it's "who's absorbing the risk on the parts of this project we don't understand yet, and does the contract structure reflect that honestly."