Sequence the change, not just the software.
Transformation programmes rarely fail on technology. They fail because eleven workstreams were started at once, each with its own steering group, and eighteen months later nothing is finished. This is a sequencing programme: fewer things running, each one finished, each one paying for the next.
One workstream at a time·Benefit measured per stage·Governance that decides
What this programme is for.
Choose this when the problem spans more than a system — where process, structure, data, and tooling all have to move, and the difficulty is deciding in what order.
Too many programmes at once
Eleven initiatives, each three-quarters done, competing for the same four people who understand how the business actually works.
No agreed baseline
Nobody can say what the current process costs, so nobody can say whether any of it has improved.
Decisions take months
The governance structure meets often and decides rarely, and the workstreams wait.
The business has stopped believing
Two previous transformations landed as new software and no change, so the next announcement is met with patience rather than enthusiasm.
How the programme runs.
The discipline is the sequence. One workstream is in flight at a time, it is finished before the next starts, and the benefit is measured against a baseline agreed before it began.
- 01Weeks 1–4
Baseline
Measure what the current processes actually cost — in days, in handoffs, in rework — before anything is changed. Without this, every later claim about improvement is an opinion.
What exists at the end of it
- Cycle time, handoff count, and rework rate for each core process
- Where cost and delay actually sit, measured rather than assumed
- Data quality assessed against what the target processes need
- An agreed baseline everybody has signed up to
- 02Weeks 4–6
Sequence
Order the work by dependency and by payback, and then deliberately cut it down. The output is a plan with fewer things in it than you started with, and a stated reason for each omission.
What exists at the end of it
- Workstreams ordered by dependency, then by payback
- An explicit not-now list, with the reasoning recorded
- A named owner and a decision right per workstream
- Governance that meets to decide, with a standing agenda
- 03Per workstream
Deliver, one at a time
Each workstream runs to completion — process, system, data, and the people change together — and is measured against the baseline before the next one is allowed to start.
What exists at the end of it
- Process redesigned and running, not just documented
- The supporting configuration live in production
- Training and handover to named internal owners
- Measured benefit against the baseline, published
- 04Continuous, from the start
Hand over
Capability transfer is a phase that runs throughout rather than a week at the end. The test is whether your team can deliver the next workstream without us.
What exists at the end of it
- Your own people configuring, not only operating
- Documented decisions, so the next team knows why
- A change process that works without the programme
- The remaining roadmap, owned internally
The usual sequence.
Dependencies decide most of this order. You cannot automate a process you have not measured, and you cannot report across a business whose master data disagrees with itself.
One version of the numbers
The ledger, the master data, and the reporting. Everything downstream depends on the business agreeing what a customer, an item, and a cost centre are.
1 module in this wave
The core operating process
Whichever of order-to-cash, procure-to-pay, or plan-to-produce carries the most cost. Redesigned and rebuilt, not lifted across as it was.
The people and customer surfaces
Once the core runs, the surfaces around it — self-service, portals, mobile, and the employee processes — start paying back quickly.
Intelligence on top
Agents last, deliberately. They are worth most on a process that is already clean, and they hide problems on one that is not.
What the programme leaves behind.
A transformation that ends when the consultants leave was not a transformation. Each of these exists to make the next change something you do rather than something you buy.
- A measured baseline and a measured result
- Cycle times, handoffs, and rework before and after, published per workstream rather than summarised at the end.
- Redesigned processes, running
- Documented as configuration and workflow in the system, not as a process map in a folder.
- Master data that agrees with itself
- One definition of a customer, an item, and a cost centre, with the deduplication work actually done.
- Governance that decides
- A standing agenda, named decision rights, and a record of what was decided and why.
- Internal capability
- Your team configuring and delivering, with the remaining roadmap owned by them rather than by us.
- An honest not-now list
- What was deliberately left out, and the reasoning, so the next team does not rediscover it from scratch.
The terms this programme runs on
- Concurrency
- One workstream in flight, finished before the next starts
- Baseline
- Agreed and measured before any change begins
- Benefit
- Measured per stage against that baseline, and published
- Governance
- Named decision rights, standing agenda, recorded decisions
- Capability
- Transfer runs throughout, not as a week at the end
- Scope
- An explicit not-now list, with the reasoning kept
What this programme is usually pointed at first.
Next step