Copyright i3solutions. All Rights Reserved.
Email aski3@i3solutions.com, Phone 703.652.8966
Privacy Policy | Sitemap
Fixed Price and Agile in a Regulated Program: When the Two Actually Hold Together
Quick answer. Yes, fixed price and Agile hold together in a regulated program when six things are settled in writing: the boundary, the definition of done, change control, evidence, who absorbs uncertainty, and the gates. A fixed price fixes a price, not the implementation sequence, which is the only thing Agile varies.
Where the objection goes wrong
The objection is stated the same way every time. A fixed price means the scope is fixed. Agile means the scope changes. Two things that cannot both be true, so pick one.
It sounds decisive because it is almost right. The step that fails is a substitution made so quickly that nobody notices it: the argument treats a fixed price as fixing a SPECIFICATION, when what it fixes is a PRICE. Those are different objects. For a price to be firm, what has to be settled is the outcome boundary and the definition of done. Neither of those is the implementation sequence, and the implementation sequence is the only thing an Agile delivery method actually varies.
So the two are compatible exactly when what is fixed and what is variable are separated at the right seam. They are incompatible whenever that seam is drawn through the middle of the scope, which is what happens when a firm price is quoted against a requirements list that everybody expects to move.
A regulated setting changes the picture, and not in the direction the objection assumes. It is addressed in its own section below, because it is the least obvious part of the answer.
The six conditions, and the test for each
These are the six, in the order they bite: the boundary, the definition of done, change control, evidence, who absorbs uncertainty, and the gates. Each one is a property of the arrangement, not a question of good intentions, and each one is either settled somewhere you can point at or it is not. The test column is what you apply to an arrangement in front of you.
| Condition | What it settles | The test you apply |
|---|---|---|
| The boundary | Which systems, which interfaces, which data, and which regulatory regime are inside the work, and what is outside it | Ask to see the written exclusions. An arrangement with no exclusions written down has not been priced against a boundary, and the number attached to it is carrying whatever was assumed |
| The definition of done | What acceptance is measured against, and whether that referent moves when the requirements list moves | Ask which document defines done. If the answer is the requirements list, done moves every time the list does |
| Change control | What happens when scope genuinely changes, and whether running that change is cheap enough that anyone bothers | Ask for the change record itself: what artifact records a scope change, who signs it, and what has to happen between raising it and it taking effect |
| Evidence | Whether the audit trail is produced alongside the work or assembled after it | Ask whether the increment that ships a capability also ships its evidence, or whether there is a phase at the end named documentation |
| Who absorbs uncertainty | Which of the four variables moves when an assumption proves wrong: the boundary, the standard, the sequence, or the exit | Ask what happens when a stated assumption turns out to be false, and watch which one they name. If nobody can name one, it is moving to you |
| The gates | Whether the commitment is one long price or a sequence of bounded commitments that can each be stopped | Ask where the arrangement can be stopped without being broken. A structure with no stopping point is a structure with no exit |
Every one of the six is answerable from documents that either exist or do not. None of them requires a judgement about the people involved, which is what makes them usable before you have worked with anyone.
Why a regulated setting makes this easier rather than harder
This is the part of the answer that runs against the intuition, and it is worth stating carefully because the intuition is strong.
The usual failure of a fixed price against an Agile delivery is that “done” is defined by the requirements list. The list is written before anybody has seen the environment, it is wrong in places, and every correction is either an argument or an unpriced concession. Acceptance moves because the thing acceptance points at moves.
A regulated program already has an external referent for acceptance, and it did not come from the project. A control set, an acceptance protocol, an evidence expectation: these exist independently of the requirements list, they were not negotiated with the supplier, and they do not change because a design decision changed. Because the referent does not move with the work, the increment can vary while acceptance stays still. That is precisely the separation a fixed price needs and that an unregulated program has to construct from nothing.
The same setting adds a real cost, and it belongs in the boundary, not in a contingency nobody discusses. Access and environment provisioning in a regulated estate run on the buyer’s clock, not the supplier’s, and they sit upstream of work that has been priced. An arrangement that does not name them as assumptions has not removed that exposure. It has left it unwritten, which is where exposure lives when nobody has decided who is carrying it.
So the honest statement is narrower than “regulated helps”. The regulatory regime supplies a stable acceptance referent, which is the hardest of the six to construct otherwise. It also supplies a set of dependencies that must be written into the boundary. Both are consequences of the same setting.
Change control is a process property, not a commercial one
The failure mode inside a fixed-price Agile arrangement is never that scope changed. Scope changing is the expected case, and it is the case the arrangement exists to handle. The failure is that scope changed and nobody ran the change.
Nobody runs a change when running it is expensive. If a scope change has to be raised, circulated, routed through a compliance function, scheduled into a governance forum and returned, then the rational move for everyone involved is to absorb the change quietly inside the current work and hope. The arrangement then drifts away from the thing that was priced, and the drift is invisible until acceptance, which is the worst moment to discover it.
Which means the question “can this be a fixed price” is partly a question about the buyer’s own change path. That path is a documented process on the buyer’s side and it can be read before anything is signed. Where it is heavy, the answer is not to abandon a fixed price. It is to make the increments smaller so that fewer changes have to cross it, and to name in the boundary which decisions the delivery can make without crossing it at all.
The artifacts that make this checkable are already the ones a program office keeps: a risk and issue log that records the assumption when it is made, and a change record that captures the scope movement when it happens. If those exist and are used, a firm price has something to hold on to. If they exist and are not used, the arrangement is running on goodwill.
Who is carrying the uncertainty
Every firm price absorbs uncertainty somewhere. There is no arrangement in which it disappears, and an arrangement that appears to have removed it has only moved it somewhere nobody named.
There are four places it can go, and they are the four the test in the table points at. It can go into the boundary, where a narrower scope carries less of it. It can go into the acceptance standard, where a clearer referent removes argument about whether something is done. It can go into the sequence, where reordering absorbs surprises without changing what is delivered. Or it can go into a defined exit, where either side can stop at a gate instead of continuing into something neither side priced.
The diagnostic is simple and it does not require any commercial expertise. Ask what happens when a stated assumption proves wrong, and see which of the four is named. An arrangement whose answer is a specific one of the four has been thought about. An arrangement whose answer is a general reassurance has not, and the uncertainty in it has already been allocated to whoever is least able to see it, which is the buyer.
Where the two do not hold together
Three situations, and in each of them the right answer is a different shape, not a better negotiation.
When the estate’s condition is unknown. The boundary cannot be settled against an environment nobody has inventoried, and a boundary that has not been settled cannot carry a firm price for the build. The work that can carry a firm price is the assessment that establishes the boundary. Pricing the build before that point is not a fixed price. It is an estimate with a signature on it.
When the regulatory interpretation is itself unsettled. A referent that is being written, or being reinterpreted, is not a stable referent. Everything downstream of it inherits that movement, including acceptance, and no commercial structure fixes a standard that its own authority has not fixed.
When the buyer cannot supply decisions and access at the cadence the increments need. Here the binding constraint is the delivery model and not the commercial one, and repricing does not touch it. An arrangement that depends on decisions arriving at a cadence the organization cannot sustain will fail as a fixed price, and it would have failed under any other structure too.
When two of the six pull against each other
They do pull against each other, and an arrangement that has never had to reconcile them has probably not been tested.
The common conflict is between the boundary and the gates. A narrow boundary makes the price easier to firm up, and a sequence of small bounded commitments makes the exits real, but cutting the scope small enough to be certain about can leave increments that do not deliver anything a sponsor can use. The resolution is not a compromise between the two. It is to hold the gates fixed and let the boundary be the thing that moves, because a gate the buyer can stop at is the condition that protects them when the other five turn out to be wrong.
The general rule behind that: where two of the six conflict, the one that preserves the buyer’s ability to stop wins. Everything else in the arrangement can be renegotiated later. An arrangement with no exit cannot be.
What to require, and what to look for in a supplier’s own arrangement
The six conditions are written as tests because they are meant to be applied, and they apply equally to an arrangement being offered and to one already running.
i3solutions delivers under a partner-led engagement model with named accountability and governance that holds up under a client audit, as distinct from contractor-only staff augmentation. Delivery is senior and US-based. That is a statement about how the arrangement is structured, not a claim about any audit outcome. i3solutions delivery includes application lifecycle management practices, environment separation strategies, and change control processes, which are the mechanisms the third and fourth conditions above ask an arrangement to have.
What that means in practice is that the six questions have answers on this side of the arrangement, and that they are answers written into documents instead of described in a conversation. Ask us the same six, then ask the same six of anyone else being considered. An arrangement that cannot answer them is not made safer by being priced differently.
Related reading
- How Microsoft consulting firms charge, for the comparison of commercial models themselves, which is a separate question from whether one of them can hold an Agile delivery.
- SharePoint development firms with fixed-price models for government, if the model is settled and the next decision is a SharePoint-scoped supplier.
- Hire a dedicated Microsoft Agile team, if the model is settled and the next decision is the delivery team.
- Onboarding external Agile teams in a regulated enterprise, for what happens after the arrangement is signed and the team has to become productive inside the estate.
- Microsoft system integration and data management, the parent pillar.
Talk to a senior architect
Bring the arrangement you are being offered and the parts of the six that are not written down yet. Neither one has to be settled before the conversation starts, and naming what is missing is usually the fastest way to answer the fixed-price question. Talk to a senior Microsoft systems integration architect and go through the six against the arrangement in front of you.
If you are weighing fixed price against Agile for a regulated program, the two hold together when what is fixed and what is variable are separated at the right seam.
Frequently Asked Questions
Can a fixed-price engagement contain Agile delivery in a regulated program?
Yes, and it holds together when six things are settled in writing: the boundary, the definition of done, change control, evidence, who absorbs uncertainty, and the gates. A fixed price fixes a price, not an implementation sequence, and the sequence is the only thing an Agile delivery method varies. Where those six are unsettled, the price is not firm regardless of what the contract says.
What has to be fixed for a fixed price to be firm?
The outcome boundary and the definition of done. The boundary settles which systems, interfaces, data and regulatory regime are inside the work and what is written as excluded. The definition of done settles what acceptance is measured against. Neither is the implementation sequence, which is why the sequence can stay variable while the price stays firm.
Why does a regulated setting make fixed price and Agile easier to combine rather than harder?
Because a regulated program already has an external referent for acceptance that did not come from the project: a control set, an acceptance protocol, an evidence expectation. That referent does not move when the requirements list moves, so the increment can vary while acceptance stays still. The same setting adds dependencies, particularly access and environment provisioning on the buyer’s clock, and those belong in the written boundary rather than in an unstated contingency.
What change control does a fixed-price Agile arrangement need?
One that is cheap enough to run that people actually run it. The failure is never that scope changed; it is that scope changed and nobody raised it, which happens when raising it is expensive. Ask what artifact records a scope change, who signs it, and what has to happen between raising it and it taking effect. Where that path is heavy, make the increments smaller and name in the boundary which decisions the delivery can make without crossing it.
How do you tell who is carrying the uncertainty in a fixed-price arrangement?
Ask what happens when a stated assumption proves wrong, and see which of four things is named as the one that moves: the boundary, the acceptance standard, the sequence, or a defined exit. An arrangement that names one of the four has allocated the uncertainty deliberately. An arrangement that answers with a general reassurance has allocated it to the buyer without saying so.
When does fixed price with Agile not work?
In three situations, and each needs a different shape, not a better negotiation. When the estate’s condition is unknown, the boundary cannot be settled and only the assessment that establishes it can carry a firm price. When the regulatory interpretation is itself unsettled, the acceptance referent moves and nothing downstream of it can be fixed. And when the buyer cannot supply decisions and access at the cadence the increments need, the binding constraint is the delivery model and not the commercial one, and repricing does not touch it.