Contract restructuring
Restructuring the contract instead of working harder inside it
A fixed-price build went red when the client hired their own engineers and halved our share of the work. I proposed changing the contract model rather than escalating effort.
- Our share of the work after the client staffed up — with scope unchanged
- Half the capacityOur share of the work after the client staffed up — with scope unchanged
- The proposed fix changes the contract, not the overtime
- Model, not effortThe proposed fix changes the contract, not the overtime
- Two reporting views from one set of facts
- Velocity to the client, cost internallyTwo reporting views from one set of facts
The client
A customer relationship platform build for a mid-market client who, mid-delivery, hired three senior engineers and an engineering manager of their own — halving the capacity we controlled while the fixed-price scope stayed exactly where it was.
The engagement
A contract amendment: fixed-price scope converted to capacity-based time and materials with a dynamically prioritised backlog and cross-team synchronisation with the client's own engineers.
The problem
Fixed price assumes a stable scope and a single delivery team. This engagement had neither: complexity had already exceeded the estimates, and then the client built an internal team that took over part of the work. The instinct in that situation is to escalate effort and protect the commitment, which converts a commercial problem into a burnout problem and still misses the date.
What I did
I treated it as a contract problem rather than a delivery problem, because that is what it was. The proposal was to move to capacity-based time and materials with a dynamically prioritised backlog: the client stops paying for change-control ceremony on a scope that is changing weekly, and we stop absorbing complexity we no longer control. Internally, feature-level cost tracing was kept so that portfolio reporting did not lose its granularity — the client sees velocity and delivered value, management sees where the money goes. And since two engineering groups were now building one product, I proposed an explicit cross-team synchronisation pattern rather than hoping two backlogs would stay coherent by goodwill.
What was built
Capacity-based time and materials with a dynamically prioritised backlog and no change-control bureaucracy for the client, internal feature-level cost tracing preserved for management reporting, and a scaled agile pattern for synchronising two engineering groups that had ended up building the same product from different sides.
On the table at the end
- Written case for the model change with the commercial rationale
- Amendment language distinguishing capacity from fixed scope
- Cross-team working model for the client's engineers and ours
What it changed
Offered a way out of a red fixed-price engagement that did not depend on heroics — moving commercial risk to a model that matches how the work was actually being done, while keeping internal cost traceability for portfolio reporting.
How it ran
- 01
Name the real cause
Not underperformance — a scope model that stopped matching reality the day the client staffed their own team.
- 02
Propose the model, not the overtime
Capacity-based time and materials with dynamic prioritisation, so commercial risk sits with whoever controls the scope.
- 03
Keep both reporting views
Velocity and delivered value for the client, feature-level cost tracing internally — one set of facts, two audiences.
- 04
Design the two-team seam
An explicit cross-team synchronisation pattern, because two backlogs on one product diverge by default.
- 05
Put it in the amendment
Capacity versus fixed scope written into contract language rather than agreed in a call and remembered differently later.
Other work
All case studies →- Payments
A red project where the client had no single voice
A payments build was slipping on every axis at once. The root cause was not the team — it was that meetings with the client were being spent discovering the client's own requirements.
- Software services
What the projects actually earned, once someone put cost next to revenue
Margin was assumed to be about half. Reading revenue, cost and hours together showed a spread from a third to three quarters — and one project that had quietly overrun its ceiling without a change request.
- Health tech
The estimate that covered a third of what the client thought they were buying
Two documents described two different products and both carried our logo. I stopped the contract, wrote the discrepancy register, and split the release into a fundraising build and a regulated one.
Something similar on your plate?
Thirty minutes, no deck. I will tell you whether it is worth doing at all.