Insights

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.

Over the past 10–15 years, many organizations have moved from traditional waterfall delivery to agile ways of working.  We have seen the same across our clients, where agile delivery has become the standard approach. 

And for good reasons. Agile brings clear advantages:  Requirements can evolve,  Learning happens during delivery &  Value is delivered incrementally 

But when working on complex, time-critical transformations with multiple agile teams, our experience is that:  

1.Detailed Requirements Upfront Still Matter 

Even in agile environments, detailed requirements gathering in the beginning of the project plays a critical role when multiple teams are involved. It creates a shared understanding across teams of what needs to be delivered and why. 

Without this clarity Teams interpret scope differently,  Dependencies are missed &  Integration becomes difficult.

In complex transformations, requirements are not about locking scope, they are about creating alignment at scale. 

2. Planning Creates Alignment — Not Rigidity 

Following requirements, structured planning becomes essential. 

This is where Scope is aligned,  Priorities are clarified & Sequencing across teams is defined 

Strong planning helps identify Dependencies,  Integration points  &  Critical paths

At the same time, planning must remain adaptive. 

The most effective programs combine Clear roadmaps,  Rolling wave planning & Flexibility for teams to iterate

This balance between structure and agility is what enables predictable delivery. 

 3. Testing Must Be Prepared Early 

One of the most consistent lessons across complex transformations: 

Integration issues do not appear within teams; they appear between them. 

Early preparation ensures: Test environments are ready,  Data is available, End-to-end scenarios are defined & Roles and responsibilities are clear

Without this, testing becomes Fragmented,  Reactive &  High-risk

Early test readiness is critical to achieving stable and controlled delivery. 

 4. Dependency Management Drives Delivery 

In multi-team environments, dependencies are not a detail they are the backbone of delivery. 

Effective dependency management ensures that: Work is sequenced correctly,  Teams are not blocked & Integration points are aligned 

Without it, delays in one team quickly cascade across the program. 

We consistently see that strong programs Identify dependencies early  &  Actively track them 

This is key to maintaining momentum and avoiding late surprises. 

5. Progress Must Be Visible at System Level 

Tracking progress across multiple agile teams is essential — but it must go beyond individual team status. The real question is not:
“Are teams progressing?” 

It is:
“Are we moving toward a working end-to-end solution?” 

Effective progress tracking Provides a consolidated view across teams,  Highlights risks and misalignment early & Supports better decision-making 

Without it, teams may appear on track, while the overall delivery is drifting. 

The V-model in the agile context 

In our experience a good way to structure complex agile projects is by applying the classic water fall V-model. This is still largely applied in regulated industries, for good reasons.  

Conclusion 

Agile has fundamentally improved how teams deliver, but in complex, multi-team transformations, success is not determined by individual team performance. It is determined by how well the full solution comes together. 

Our experience across industries shows that the difference lies in combining agile execution with structure, transparency, and end-to-end ownership. Detailed requirements, aligned planning, early test preparation, active dependency management, and system-level progress tracking are not in conflict with agile, they are what make agile work at scale. 

The V-model mindset reinforces this by ensuring that what is defined is consistently validated across the full solution, creating traceability and confidence throughout the delivery. 

In complex transformations, agile delivers the parts, structured delivery ensures they work together

M&A IT separation - navigating the Maze: 7 Key Insights for Speed & Value Creation
Carve-outs are inherently complex, blending the challenges of a divestiture with the urgency of a merger. Whether you are driving a carve-out for a corporate portfolio shift or PE-led growth, success requires balancing rapid separation with operational stability.
Drawing from recent experiences, here are seven actionable insights to ensure your next carve-out delivers maximum value:

 1. Timeline defines the Separation Strategy
Timeline and constraints must set the direction for all decisions, not the other way around. Establish what is truly feasible to achieve, focusing on Day 1 readiness and critical milestones.

 2. Radical Simplification
Minimize complexity at all costs. Over-ambitious, highly customized, or deeply complex solutions risk the overall timeline and goal achievement. Unless there is a clear, proven benefit, keep it simple.

 3. Buyer-Type Dependent Strategy
Tailor your strategy to the buyer’s infrastructure. An industrial buyer likely has existing, compatible infrastructure, while a Private Equity buyer may require a full, stand-alone, or “clone-and-carve” solution (unless merging into another portfolio company).

 4. Proactive Data & Risk Management
Define your data exposure strategy early. Decide immediately between: "define and delete" (safer, cleaner) vs. "copy, migrate, and delete later" (faster, higher risk). Mitigate risk by separating critical data sets - including Intellectual Properties - before closing.

 5. Strategic Vendor/License Separation
Refrain from early, blanket outreach to vendors. Instead, follow the natural cadence of contract expirations, starting 2-3 months prior. This avoids triggering premature re-negotiations or penalties, allowing for a structured, cost-effective separation.

 6. People & Culture: Lead with a Vision
For large, distributed teams, establish a clear, simple, and memorable vision. Utilizing a "Sprint vs. Marathon" strategy (similar to the successful FLSmidth approach) helps teams prioritize short-term, versus long-term goals.

 7. Early Incentivization & Rapid Execution
Secure stay-on bonuses and NDAs for key, critical resources early in the process. Ensuring key talent remains is crucial for data accuracy and continuity. Finally, from a people perspective: Get it done FAST.

 Bottom Line: Base your decisions on the synergy case and track progress against that case diligently. A successful carve-out doesn't just separate a business; it sets it up to thrive independently from Day 1.