When the Programme Stops Delivering

Mikael Petterson, Partner, DA Network

Published: August 2026

When the Programme Stops Delivering — What Recovery Actually Looks Like

In my 25 years of leading complex programmes, I have been called into several recovery situations. Some were salvageable with the right intervention; some had already passed the point of no return. But almost all of them shared the same root causes — and almost none of them were about technical knowledge of the platform being implemented.

When a programme starts to fail, the instinct is often to look for someone who "knows the system better." A D365 expert. A Salesforce specialist. In my experience, that is the wrong diagnosis. The problem is rarely what is being built. The problem is how it is being led.

Why do programmes fail?

The root causes cluster around four patterns:

1. Unclear expectations. Scope is agreed at a high level, contracts are signed, and then the interpretation gaps surface. What the client thought they were getting and what the supplier thought they were delivering are — sometimes dramatically — different.

2. Timelines that were never realistic. The timeline was built to win the deal, not to deliver the programme. By month three the programme is already behind and nobody wants to say it out loud.

3. Governance and leadership not established. Decision rights are unclear. Steering committees meet but don't decide. Nobody owns the hard calls.

4. Unwillingness to have honest conversations. This is the one that compounds all the others. When difficult conversations are avoided, small problems become large ones — and large ones become unrecoverable.

The first 30 days

When I step into a recovery situation, the first priority is not to fix anything. It is to understand what is actually happening, without preconceptions and without taking sides.

A first 30-day plan typically looks like this: get a clear picture of the current state — review status reports, programme plan, risk log and financials. Have open, unbiased conversations with all parties — client, delivery team, system integrator, platform vendor. Find the gap between expectation and reality and quantify it. And understand the personal stakes and potential conflicts — a recovery lead who ignores organisational dynamics will be managed by them.

Only once that picture is clear does the work of stabilisation actually begin.

Can it be avoided?

Often yes. Unrealistic timelines, scope ambiguity and governance gaps are present from the beginning — if someone is looking for them. The organisations that avoid recovery invest in independent governance oversight early and insist on honest reporting rather than optimistic reporting.

A personal experience

A few years ago I was brought in to stabilise a major ERP implementation running over a year behind. Shutting the programme down was being actively discussed. The first question I was asked was whether I had deep experience of the specific platform.

I didn't. And it didn't matter.

What the programme needed was someone who could sit in a room with a frustrated client and a defensive delivery team, name what was actually happening, and build enough trust on both sides to get things moving again. The platform knowledge was already in the room. What was missing was the leadership to use it.

That is what recovery actually looks like. It is not a technical intervention. It is a human one. The choice of platform is rarely the critical decision — the decision to create an environment where people want to succeed is.