Recovery
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.
- A single empowered product owner demanded as a condition of continuing
- One voiceA single empowered product owner demanded as a condition of continuing
- Established before any new date was offered
- Scope baselineEstablished before any new date was offered
- The alternative commercial model where scope could not be frozen
- Per-epic re-discoveryThe alternative commercial model where scope could not be frozen
The client
A payments platform handling both conventional and digital currency flows, delivered fixed-price, with several third-party providers embedded in the critical path and a client organisation that had not internally agreed what it wanted.
The engagement
A recovery assessment producing a written justification for the schedule change and a stabilisation plan, with a proposed change to the commercial model.
The problem
The symptoms were everywhere at once: a major feature area with no agreed requirements but effort already in the plan, systemic scope creep, third-party providers changing or disappearing under us, no medium-level design, a project manager handover during the worst phase, and defect volume blocking stabilisation. The tempting response is a recovery plan that promises a new date. That date fails too, because none of those symptoms is the cause.
What I did
I named the cause rather than the symptoms: the client had not internally agreed what they wanted, and calls were being spent watching them discover it. Everything else followed from that. So the first move was formal and uncomfortable — a written statement that no credible schedule exists until scope stabilises, which stops the cycle of dates that exist only to be missed. Then a scope baseline, so that change becomes visible as change rather than as slippage. Then the commercial model: fixed price cannot absorb a scope discovered in flight, so either time and materials, or re-discovery epic by epic with each one priced as it becomes knowable. And the condition that mattered most — the client appoints one empowered decision-maker, because a vendor cannot supply a client's internal alignment no matter how many hours it burns trying.
What was built
A stabilisation plan built on four moves: state formally that dates cannot be committed while scope is unstable, establish a scope baseline, shift the commercial model to time and materials or to re-discovery per epic, and require the client to nominate a single empowered product owner as a condition of continuing.
On the table at the end
- Written justification for the schedule change
- Stabilisation plan with scope baseline
- Dispute log and consolidated change register
- Revised roadmap and successive estimate versions
What it changed
Replaced a rolling series of missed dates with one honest reset: a written statement that no date is possible before scope stabilises, a scope baseline, and a demand on the client to appoint a single decision-maker — the actual root cause.
How it ran
- 01
Separate symptoms from cause
Undefined requirements, unstable providers, missing design and a manager handover are consequences; the cause was a client without a single voice.
- 02
Say the uncomfortable thing in writing
No credible date exists while scope is unstable — stated formally, so the conversation stops being about a schedule nobody believes.
- 03
Baseline the scope
A scope baseline so subsequent change is visible as change, with a dispute log and a consolidated change register behind it.
- 04
Match the model to the reality
Time and materials, or re-discovery per epic priced as each becomes knowable — because fixed price cannot absorb scope discovered mid-flight.
- 05
Make client alignment a condition
A single empowered product owner named as a precondition, because that is the one input the vendor cannot substitute for.
Other work
All case studies →- Enterprise software
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.
- Enterprise software
Data and people existed; the process and the cockpit did not
A delivery assurance function owned everything and controlled nothing. I diagnosed nineteen gaps, designed the target operating model, and put stop conditions in the roadmap so it could not become another initiative nobody uses.
- 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.