Digital Transformation
Most programmes stall because the new way of working was designed away from the work it replaced. We start in the operation itself, and change it in an order the business can absorb.
You have probably been here before. A board funded the programme, a target operating model went up on a slide, a platform was selected, and the invoices that were supposed to process themselves still go through the same spreadsheet. Nobody changed the sequence of approvals the spreadsheet exists to work around, and the platform could not change it for them.
The order you change things in matters
Platform first, then rollout
Choose the system, design the target operating model around it, and roll it out department by department. It gives a board one plan, one budget and a date.
- The platform is chosen first; process is designed to fit it
- A multi-year roadmap fixes scope, which makes funding easier to secure
- A steering committee tracks progress through status reports
- Change reaches the floor as a rollout after build completes
Sequenced from the work
Start with how the work runs today, change one part of the operation until it holds, and let what you learn there decide what comes next.
- Technology decisions wait until the process they support is settled
- Scope stays open past the first release, which funders dislike
- The steering group reviews the changed work, not a status colour
- Each slice goes live with its own runbooks and handover
We start in the operation, not the plan
The early work is spent with the people who do the work: the scheduler who keeps a private spreadsheet because the system cannot express a split shift, the finance clerk who re-keys the same order twice, the depot manager who phones rather than raises a ticket. Those workarounds are the real design document. They tell you which rules the organisation runs on, and which ones exist only on paper.
Then the change is sequenced. Part of it is organisational: who decides, who is accountable, which handover between two teams should not exist at all. Process comes next. Software is deliberately last, because a system built to support a process you are about to abandon is the most expensive way to fail. The order gets written down, along with the sequences we considered and rejected.
What a programme covers
Transformation is a word that covers everything and therefore nothing. What sits inside this engagement:
The operation as it runs
Mapping the work that happens, not the work the process document describes. That includes the workarounds, because a workaround is usually the operation telling you where the design was wrong.
Decision rights and structure
Most stalled programmes have a process problem with an org chart underneath it. Who signs off, and which boundary between two teams is creating the queue.
The estate you already have
An honest read on what the current systems can and cannot support. Sometimes the answer is that a licence you already pay for covers the case, and nothing needs building.
Evidence the change held
A measure agreed before anything moves, taken from the operation rather than the programme: how long the queue is, and how many times a case comes back.
Each phase ends with something you can check
No calendar here, because the shape depends on how much of the operation is in scope and how quickly your people can be freed to work on it. The phases run in this order, though, every time.
- 01Phase 1
Read the operation
We sit with the teams whose work is in scope and follow a few real cases from end to end. What comes out is a picture of the operation as it runs, with the workarounds marked and costed in effort.
- 02Phase 2
Decide what changes
Options are written up with what each one would cost the organisation in disruption, not only in build. One of the options on the table is always doing nothing to the software. You pick, in a room, with the trade-offs visible.
- 03Phase 3
Change one part first
A single slice of the operation moves to the new way of working: one depot, or one product line. It runs live, with the old path still available, until the people doing it prefer the new one.
- 04Phase 4
Spread what worked
The rest of the operation follows the slice that held, adjusted where local practice differs rather than where it is habit. Telling those two apart is most of the difficulty, and it is done with the teams themselves.
- 05Phase 5
Hand it over
Runbooks, dashboards and on-call procedures go to the teams who will own the result, along with the decision record. Your people run the new operation; we are there while they do, and then we are not.
Frequently asked questions
Because the sequencing puts software last, and one of the outcomes we write up is that you do not need new software. It happens. A licence you already hold, a few decisions moved to a different desk, and a handover removed can be the whole answer. We would rather tell you that than build something you will resent paying for.
Not sure which one you need?
Describe the problem in a paragraph and we will tell you which service applies.