We were 8 months into a €10M+ programme, and then the company I worked for changed its strategy.

The executive team decided to shift priorities. They set a new commercial focus, meaning new initiatives that needed resources and attention. Me and my team were a bit shocked, because although the decision was reasonable and made for good reasons, the digital transformation programme felt the consequences immediately. The product owners we relied on started spending time on other initiatives. ‘Our’ developers got pulled toward higher-priority projects. The specialists became harder to involve because they were spending time on other projects. Nobody said the programme was cancelled. It just started moving through mud.

The slowdown wasn't the hardest part. The hardest part was what happened to the work. To keep things moving, we had to constantly reduce what we were delivering. An initiative scoped for full rollout would get trimmed to an MVP. That MVP version would get built but never developed further, because the funding and the people weren't there. Eventually the basic version became the final product, even though it was never meant to be.

That programme delivered results, but it took twice the effort it should have, and several of the initiatives never reached what they were fully capable of.

This is how most digital transformation programmes actually die.

Why digital transformation programmes fail: it's rarely what you think

If you think about why programs fail, you can think about an unclear strategy or a lack of executive alignment. Although these are real problems, I believe they are usually symptoms of something more structural: the programme was designed as if the situation around it would stay the same. As if the company's priorities wouldn't shift, the market wouldn't move, and the resources committed at the start of the year would still be there in month fourteen.

They won't. They never are.

Most transformation programmes are built like large projects. They have a fixed scope, fixed budget, tight delivery timeline and a handover plan. That approach assumes a kind of environmental stability that mid-to-large transformation programmes almost never have.

The programme I ran wasn't undone by bad planning or weak sponsorship. The original plan was solid and the strategy change that hit us 8 months in was a legitimate business decision. The problem was that nothing in the way the programme was organized told us what to do when it happened. We had an agile delivery setup, but which initiatives do you protect? Which do you de-scope? At what point do you go back to the leadership team and say the programme needs to be replanned? We made those decisions, but in hindsight we made them reactively. Initiative by initiative, almost month by month.

Why governance doesn't fix a stalling digital transformation programme

When a programme starts stalling, most organisations reach for the same things. More governance, more check-in meetings. A steering committee that meets more often, with expensive people in the room, which makes it an expensive meeting. An escalation to the executive sponsor.

I understand why, because it feels like control but it isn't.

Adding more meetings to a people problem is like telling an overworked team to work faster. The real issue, that the people you need are being pulled toward other projects, won't get solved in a meeting room. What the steering committee can do ( if it's designed right from the beginning) is give you an agreed framework for making trade-off decisions before the situation becomes critical. 

Formally raising the problem up the chain has a similar issue. By the time something reaches an executive sponsor as a formal issue, it's usually been a problem for weeks. The people closest to the work already knew about it. They just had no path to surface it that didn't feel like failure. A programme that only acts when problems are formally flagged has already waited too long.

The real gap isn't governance or escalation. It's that most programmes don't have an answer in advance to a simple question: what do we do when things change?

Not if. When.

A plan assumes stability. A programme built to run for 18 months inside a real company, navigating real market conditions, needs something more honest than a plan.

It needs a structure that's built to change.

How to structure a digital transformation programme that survives change

The programmes I've seen that deliver share a few elements most don't have. None of them are complicated. Most are just not set up the right way or not set up at all. Here's what I would do:

1. Start with a goal that's big enough to survive a strategy shift

The north star for a transformation programme needs to be ambitious enough that when the business changes direction, the goal itself still stands. "Improve checkout conversion by 4%" doesn't survive a change in business direction. "Own the customer experience from first visit to repeat purchase" does. The goal should sit at a level that commercial decisions fall beneath, not above.

What changes is the roadmap beneath it. And that's fine, because the roadmap is supposed to change. The roadmap is not the commitment. The goal is the commitment. The roadmap is the current best theory about how to get there.

2. Decide upfront which initiatives are protected and which are flexible

Not every part of the project matters equally. Some pieces are essential. If they fall behind, everything that depends on them falls behind too. Others are valuable, but the project won't collapse without them. This distinction matters enormously when resources come under pressure, but most programmes don't make it explicit until they're already in trouble.

Before the programme starts, the steering committee should agree on a priority system. Priority one: initiatives that are protected regardless of what happens to the surrounding context. Priority two: initiatives that are important but can be descoped or delayed if needed, with defined minimum viable versions. Priority three: initiatives that depend on spare capacity and will be deprioritised first.

This sounds obvious. I've almost never seen it done. When the strategy shifts and the hard conversations start, having this framework agreed in advance means decisions get made against a clear set of criteria, not by whoever is most available or most vocal.

3. Build warning signals into the governance from day one

The question isn't whether your programme will need to be replanned. It's whether you'll recognise it early enough to replan intentionally rather than reactively.

Before the programme starts, agree on a few clear warning signs. These are specific conditions that tell you it's time to stop and rethink. Not an alarm, but a decision point. When one of these conditions is met, the conversation moves to the leadership team automatically, without anyone having to decide first whether it's serious enough.

Examples: if more than 30% of the planned required people is unavailable for two consecutive sprints, we replan. If two or more priority-one initiatives are delayed by more than six weeks, we replan. If a new company initiative is announced that requires resource from the programme team, we replan.

The specific triggers matter less than the fact that they exist before the pressure starts. When they're defined in advance, the conversation shifts from "is this serious enough to escalate?" to "the trigger was hit, what do we do?".

4. Get the business involved before the build starts

This is the one I see consistently underestimated. The teams who will eventually run what gets built (business operations, customer service, marketing) are often consulted late, or not at all. By the time they're in the room, the fundamental decisions have already been made.

When the product arrives, it doesn't quite fit how they actually work. Their needs weren't built in, because nobody asked them early enough. They're open to change, they just don't feel connected to something they had no hand in shaping. And when people don't feel that connection, they use the new system without really committing to it.

The fix is straightforward: involve the relevant business stakeholders in product requirements and solution design from the beginning. Not as approvers but as real contributors. Their input changes what gets built. And when they've shaped what gets built, they defend it.

What changes when you design for this

In one of the initiatives I led, I involved a customer intelligence specialist from the very start. Not as a stakeholder to consult somewhere along the way, but as a core member of the project team. Because of that, we were able to design the product in a way that also served the goal of direct customer marketing from day one. If we hadn't included that person early, we'd have been building without that data foundation and would have had to fix it  later — or leave that business goal unserved entirely.

What I can say about the programme I described at the start: the things that went wrong were all predictable in hindsight. Not because we were naive. Because we hadn't designed for the possibility that the context would change. The response when it did was improvised, and improvised responses to programme pressure are almost always slower and more expensive than designed ones.

When I now come into a programme in its early stages, the first questions I ask aren't about technology or delivery methodology. They're about what happens when the plan meets reality. Is there a priority model? Do the replanning triggers exist? Are the business teams who will run this involved in designing it?

If the answer to those questions is no, the project is built on shaky ground and no amount of meetings or senior backing will fix that. The risk isn't the technology. It's the assumption that everything around the project will stay stable long enough for the plan to work.

It won't. And the only honest response to that is to design for it.

The question before you begin

Most transformation programmes are not set up to fail. They're set up for a world that doesn't exist. A world with stable priorities, fully available specialists, and a context that holds still long enough for the plan to work.

The ones that deliver are designed for the world that does exist. One where strategy shifts mid-programme, where specialists get pulled for legitimate reasons, where the business teams who need to adopt the outcome weren't involved early enough.

None of this requires more budget, more governance, or a larger programme management office. It requires different decisions, made earlier, about how the programme is structured.

If your programme is stalling, or you're about to start one and want to avoid the patterns I've described, I'm happy to talk through what that looks like in practice. Check my services.

nick@vzconsulting.nl / www.vzconsulting.org