Guide · Transformation
How to restart a stalled digital transformation
You restart a stalled digital transformation by finding the one number it was funded to move, tracing that number to the single place it stops, cutting every workstream that does not touch that place, and shipping one move against it inside 30 days. One result restarts it, before any new plan. The board gets the honest reason, the move, the number and the date, and the programme earns the right to the rest.
This guide, in 6 parts
What a stall looks like from the inside
Picture the steering committee in month fourteen. Six workstreams show green, the deck is at version 31 (nobody has read it properly since version 12), the vendor invoices are paid on time, and the one number the programme was funded to move, order-to-delivery time, the cost of a manual price change, the share of orders that ship from the store, sits exactly where it sat in month one. The dashboard is healthy. The business case is not.
We have sat in that room from the inside, on a national kitchen range switch across 29 stores and on a multichannel programme across five functions, and the stall always had the same shape: plenty of activity, no movement on the number, and a status report that measures the first and never the second. A pilot that never leaves the lab has the same shape in miniature.
Why it really stalled
Five failure modes sit behind almost every stall. The status report names none of them.
| Failure mode | What it looks like | The move that clears it |
|---|---|---|
| The report measures activity | Every workstream green, the funded number flat since month one | Replace the dashboard with the one number and the place it stops |
| The last integration mile | The new system works in the demo and dies on contact with the legacy systems, the records that contradict each other, the handoff nobody owns | Put an owner on the handoff and wire the move to the live systems, however ugly they are |
| Nobody owns the running | A sponsor and a vendor own the build; production has no name attached, so the thing is never used and the saving never lands | Name the operational owner before the build team rolls off |
| Scope creep | Each quarter added a workstream, a stakeholder, an edge case, until the first credible result was always one more quarter away | Cut to one shippable move and park the rest, in writing |
| Workflow and data quality never fixed underneath | A broken process automated, a messy dataset scaled: the tool did what it was told, faster, to work that was wrong | Clean the process and the data for the one move only, then build |
The 30-day restart sequence
Four moves, in order. The goal is one credible result back on the board, with the programme's momentum coming from that result and from nothing else.
| Days | Move | What you hold at the end |
|---|---|---|
| 1 to 5 | Find the real constraint. Ignore the status report, follow the funded number back to the single place it stops: a broken handoff, an integration that never landed, a step still done by hand | One named constraint, one number, one owner |
| 6 to 10 | Cut what does not move the number. Stop the workstreams that report progress and do not touch the constraint; a stalled programme usually carries three efforts for every one that matters | Freed capacity and a shorter plan, agreed with the sponsor |
| 11 to 25 | Re-scope to one shippable move, wired to the live systems, owned by a named person, with the metric attached, and ship it | A change in production that the number can register |
| 26 to 30 | Show the board a credible restart: the honest reason it stalled, the move underway, the number it will shift, the date | A board that backs the next move because it can verify the first |
Which move comes first depends on the constraint, and finding it is the work. That is the question our FOCAL Diagnostic answers on a live programme. Sequencing what comes after the first win is its own discipline, and we map that order with the Hub Map so the restart leads somewhere.
The proof we bring
One of us ran the national switch of IKEA France's kitchen range across 29 stores on a single date, with kitchens carrying 25% of the country's turnover, zero revenue lost and a 10-year after-sales commitment, through 8 domain leaders and at least 5 people in every store (2012 to 2014). The same operator then ran a Multichannel Transformation Programme across five functions in India, measured on adoption in daily operations and never on go-live (2018 to 2019). Launch is a date. Adoption is the number.
Another of us led the shift from project delivery to iterative product delivery across IKEA's digital teams from Älmhult (2017 to 2018), then took over a flagship store in a global retail group that was losing sales every week to network outages. Bleeding stopped first: dual physical servers, network downtime down 95%, and foot traffic up 20% once the layout was redesigned on the stable base (internal measurement, 2018 to 2021). The fix moved the group's IT budgets back to physical servers in stores. The full record is in the turnaround case and on the proof page.
A third of us, running a support operation for several markets, took one market's backlog from one month to two hours with no new tool, through ownership and a team that wanted the number to move. Same lesson, smaller room.
The outside evidence points the same way. MIT's study of enterprise AI found that about 5% of AI pilots achieve rapid revenue acceleration, and that the vast majority stall with little or nothing measurable on the P&L (MIT NANDA, The GenAI Divide, 2025). The reasons named are workflow and integration. Model quality is rarely on the list.
The position we hold
A stalled transformation restarts on one shippable move against the number it was funded to move. A restart that answers the stall with a new plan, a new deck and a new budget will stall again within two quarters, because it adds a programme on top of the programme that stopped. McKinsey's survey on restarting stalled digital transformations gets the diagnosis right: more than 60% of respondents put the causes inside the organization's own control, and only 6% blamed market disruption (Blackburn, Bughin and LaBerge, McKinsey, March 2020). That is worth saying out loud to a board that blames the vendor. Where we part ways is the remedy. Their headline fixes are a clear direction, an economic model and more resources, with change management and communications in a supporting role, and each one adds something to the programme. Ours starts by taking work away until one move can ship, and the change management happens on that move, with the people who run it, which is the only place we have seen it stick.
Questions, answered straight
Our status report is green. Why does it feel stalled?
The report measures activity: workstreams shipped, milestones passed, invoices approved. The number the transformation was funded to move sits outside the report, and it is flat. Trace that one metric back to the single place it stops. That place is the constraint, and it is rarely the one being managed.
Do we need to scrap it and start over?
Almost never. A stall is usually a scope and ownership problem sitting on a programme that is mostly sound. Starting over throws away the parts that work and resets a clock the board is already tired of watching. Pick it up where it stopped, find the constraint, cut what is not moving the number, ship one move (the cut is the move that costs the most friends, and it's still the one that frees the calendar).
What can we get done in 30 days?
One honest restart. The real reason it stalled, one workstream cleared of the noise around it, one shippable move in production against the metric, and a board update that carries a result in sight. Thirty days is enough to change the direction and earn the room to finish, which is the thing a stalled programme has lost.
Who should own the restart?
A named operational owner on your side, the person who will run the thing after the build team rolls off, backed by the sponsor who can stop workstreams. A vendor cannot own it and a steering committee will not. Committees approve, they don't run. We work beside that owner for the 30 days and hand over the running with the number attached.
How do you find the real constraint quickly?
From the number, never from the org chart. We take the metric the programme was funded to move and walk it through the operation until it stops: the handoff, the integration, the manual step. On a live programme that takes days, and it is what the FOCAL Diagnostic does, as a paid, scoped engagement with a named move at the end.
What if the vendor says the problem is our data?
The vendor is often right, and it changes nothing about the sequence. Clean the process and the data for the one move only, and let the move prove the platform. The whole estate can wait. A data-quality programme that runs ahead of any shippable result is the fifth failure mode wearing a new badge.
When is a transformation really restarted?
When it ticks six lines: the constraint is named against the funded number, the workstreams that do not touch it are stopped, one move is in production with the metric attached, a named owner runs it, the board has the honest reason and the date, and the process and data under the move are clean enough to build on. Until then it is drifting, whatever the deck says. But the number sat where it sat, and the number is the only reader who cannot be persuaded.
Restart it with operators who have done it
Bring the programme as it is: the status report, the funded number, the org chart of who owns what. Half a day on it tells you where it stops and what the first move is. Start a conversation, or begin with the FOCAL Diagnostic if the board needs the answer in writing first. Everything else we do is on how we work, and The Product Engine is where a restarted programme gets the product operating model that keeps it moving after we leave.