Digital transformation programmes usually stall for organisational reasons, not technical ones: the scope is too broad, nobody senior owns the business outcome, people are not brought along, suppliers end up writing the roadmap and success was never defined in numbers. To restart one, pause new commitments, run a short and honest diagnostic, narrow the scope to a few measurable outcomes, put a single accountable owner in charge and reset the governance with your suppliers.

Key takeaways

  • Stalled programmes share a small set of root causes, and most of them are about ownership and scope.
  • Technology is rarely the main problem, even when it is the most visible one.
  • A restart starts with a pause on new spending and a diagnostic of a few weeks, not with a new tool.
  • Narrow the scope to two or three outcomes that the business can measure.
  • You know you are back on track when decisions get faster and the steering meeting talks about results, not activity.

The five root causes I see most often

In my experience, when a programme loses momentum the symptoms vary (delays, budget overruns, frustrated users), but the causes tend to repeat.

1. Scope that tries to change everything at once

"Digital transformation" often means a new ERP, a new CRM, a data platform, process redesign and now an AI layer, all in the same plan. Each piece depends on the others, so nothing can be finished and nothing can be measured. The programme becomes a permanent state rather than a project.

2. No single business owner

The programme is "owned" by IT, a steering committee or the supplier. All three are problems. IT can deliver systems but cannot change how sales or operations work. Committees spread accountability until it disappears. Suppliers have their own commercial interests. A transformation needs one senior person on the business side who owns the outcome and has the authority to make trade-offs.

3. Change management treated as a communication plan

New systems change how people do their jobs. If the plan for that is a newsletter and a training day before go-live, adoption will be low and workarounds will multiply. Real change management means involving process owners early, redesigning roles and measuring adoption after launch.

4. Vendor-led roadmaps

This is one of the most common patterns. The company lacks senior internal capacity, so the integrator or software vendor shapes the roadmap. Their plan is usually competent, but it is optimised for their product and their delivery model, not necessarily for your priorities. Over time the client stops challenging change requests and the supplier controls both the work and the narrative about the work. I cover how to regain control in holding IT suppliers accountable.

5. No measurable outcomes

If the business case says "improve efficiency" or "become data-driven", nobody can tell whether the programme is working. Steering meetings then track activity (tickets closed, sprints completed, percentage complete) instead of results. Activity can look healthy for a long time while value stays at zero.

How to restart a stalled programme: a step-by-step approach

A restart does not need to be dramatic. It needs to be disciplined. This is the sequence I follow.

Step 1: Pause new commitments

Do not sign new change requests, licences or phases until the diagnostic is done. Keep running what is live and critical. The point is to stop adding weight to a structure you do not yet understand.

Step 2: Run a short, honest diagnostic

A few weeks is usually enough. Interview the sponsor, process owners, key users, IT and the main suppliers separately. Read the contracts, the statements of work, the change log and the budget. Look at what is actually in production and who uses it. This is work where AI agents help a lot: under my direction they analyse contracts, change logs and meeting notes and cross-check them, so the diagnostic moves much faster and is based on the full record, not just on interviews.

The output should answer five questions: what was promised, what has been delivered, what it has cost, what is still useful and what is blocking progress.

Step 3: Decide what to keep, cut or reshape

Not everything is broken. Typically some workstreams are close to delivering value, some should be stopped and some need to be redesigned. Make these decisions explicitly and write them down. Stopping a workstream is not a failure. Continuing one that will never pay back is.

Step 4: Narrow the scope to measurable outcomes

Pick two or three outcomes the business genuinely cares about and can measure, for example order-to-invoice cycle time, the share of customer requests resolved at first contact, or days to close the books. Each outcome gets a baseline, a target and a date. Everything in the plan must connect to one of them.

Step 5: Put one accountable owner in charge

Name a single business-side owner with real decision rights. If that capacity does not exist internally, this is where a fractional executive can step in for a defined period, while building internal ownership to take over.

Step 6: Reset supplier governance

Revisit statements of work against the new scope. Agree outcome-based KPIs, a clear change request process and a steering cadence that you chair, not the supplier. If a supplier cannot adapt, plan an orderly transition rather than living with the misalignment.

Step 7: Rebuild the change plan around people

For each outcome, identify the teams whose daily work will change. Involve their leads in design decisions, plan training close to go-live and measure adoption afterwards. Budget for this explicitly.

Signs the programme is back on track

You do not need to wait a year to know whether a restart is working. Within one or two quarters you should see:

  • Faster decisions. Issues get resolved in days, not months, because ownership is clear.
  • Shorter, sharper steering meetings. The agenda is outcomes, risks and decisions, not status slides.
  • A falling number of change requests, or at least change requests that are clearly tied to the agreed outcomes.
  • Users asking for the next release, rather than building spreadsheets around the last one.
  • Movement on the baseline metrics, even if small.
  • Suppliers proposing improvements instead of waiting for instructions or defending scope.

A diagnostic checklist for owners and CEOs

  • Can someone state the programme's goal in one sentence, with a number in it?
  • Is there one named business owner with authority to make trade-offs?
  • Do we know what has been spent, by supplier, against what was planned?
  • Who wrote the current roadmap, and when did we last challenge it?
  • How many change requests have been approved in the last six months, and why?
  • What share of what has been built is actually used every week?
  • Is there a funded plan for training and adoption?

Closing thoughts

A stalled programme is not a verdict on the people involved or on the idea of transforming the business. It is usually a sign that the structure around the work, ownership, scope and governance, was never set up properly. The good news is that structure can be fixed faster than most people expect. If you want to see how I approach this kind of work, digital transformation describes the scope in more detail.

If your programme has slowed down and you want an independent view on what to keep and what to change, send me a message through the contact form with a short description of where things stand.