How to Recover a Troubled SAP Project

If your SAP programme is off track, you're not alone and you're not out of options.

Every week, programme sponsors and CIOs find themselves in the same position: the go-live has slipped, the board is asking hard questions you don’t know the answers to, the team is running on fumes, the original business case looks like it was written for a different project, and trust between your internal team and your system integrator is fraying.

This is a recoverable situation, but only if you act quickly, honestly, and with the right support.

Why SAP Programmes Get into Trouble

Before you can fix the problem, you need to understand what it is. In our experience, a troubled SAP programme rarely has just one root cause, it has several, and they compound each other.

The most common failure patterns we see are:

• Scope that was never properly controlled – Requirements grew without formal change management, and the programme absorbed the cost quietly until it couldn't
• A business case built on optimism, not evidence – Original timelines and budgets were set before anyone truly understood the complexity of the landscape
• Misaligned accountability – Your SI is focused on delivering what the contract says; your internal team is trying to keep the relationship intact; meanwhile, the actual business outcomes nobody wants to admit are at risk aren't anybody's clear responsibility
• Under-resourced change management – The technology is being delivered, but the organization isn't ready to use it
• Governance that reports but doesn't decide – Steering committees receive updates, but they don't make the difficult calls that would actually move things forward

If two or more of these sound familiar, your programme isn't just delayed. It's structurally at risk.

The First 30 Days of an SAP Programme Recovery

When an SAP programme is in crisis, the instinct is to push harder, more meetings, more reporting, more pressure on the delivery team. But this instinct is misplaced; your first priority should be clarity, not velocity.

Step 1: Stop and assess

You cannot recover a programme you don't properly understand. The way around this is to commission an independent assessment before you do anything else.

Not an audit by the SI, or an internal review by the team that's been living inside the problem, but an honest, external view.

A good programme assessment will tell you:

• Where the programme actually stands, not where the RAG status says it stands
• What is genuinely deliverable within the current constraints
• Where the critical risks are concentrated
• What decisions need to be made, by whom, and by when

This takes days, not weeks, and it's the only foundation worth building a recovery on.

Step 2: Stabilize before you accelerate

Once you know what you're dealing with, resist the pressure to immediately announce a new go-live date. The board wants certainty, that's understandable, but committing to a date before you've stabilized the programme creates a second crisis on top of the first.

Stabilization means:

• Freezing scope so the team has a fixed target to aim at
• Clarifying roles and decision rights so the right people are accountable for the right things
• Resetting the relationship with your system integrator based on what the contract actually says, not what everyone assumed it meant
• Getting honest about what the organization can absorb, and when

Step 3: Rebuild the plan from the delivery reality

A recovered programme needs a new baseline built from what you know to be true, not a revised version of the original plan.

That means re-sequencing work based on dependencies, not wishful thinking; building in contingency that reflects actual risk, not optimistic assumptions; and it means agreeing a revised business case with the board that is honest about what the programme will deliver, and when.

This may be uncomfortable, but it's also the only route to a programme you can actually deliver.

What Good SAP Programme Recovery Looks Like

Recovery doesn't mean going back to where you were, it means moving forward on a trajectory you can defend.

Programmes we've previously helped to recover share a few common characteristics after the turnaround:

• Simplified scope meaning the must-haves are clearly separated from the nice-to-haves, and the team knows exactly what they're delivering
• Clear accountability where one person owns the outcome, and everyone else supports them
• Honest reporting so that the steering committee gets the real picture every time, with real options for decision rather than a sanitized status update
• A change management plan with teeth meaning the business is actively preparing to land the change, not just waiting for the go-live announcement
• A realistic timeline the board has genuinely signed up to, not one they've been sold

When to Bring in External Support

Some programme recoveries can be led internally, but most can't, for one simple reason: the people inside the problem are too close to it.

You need external support when:

• The programme has already had one or more re-plans that haven't held
• The relationship with the system integrator has broken down
• The board has lost confidence in the programme leadership
• You're facing a go-live delay, but nobody can tell you exactly why
• The delivery team is telling you everything is fine, but your instincts say otherwise

External support at this stage isn't an admission of failure, it's the decision that experienced programme sponsors make when the stakes are high enough to demand an objective view.

Questions Your Board Will Ask and How to Answer Them

If your SAP programme is off track, you'll likely face these questions. Here's how to think about them.

"How did we get here?" Be honest about the compounding factors. Blaming a single cause or a single party rarely survives scrutiny, and it won't help you recover the programme.

"What does it cost to fix this?" Recovery costs money, but so does a failed go-live, or a second implementation attempt. Frame the cost of recovery against the cost of the alternatives.

"Can we trust the new plan?" Only if it's been built independently, tested against delivery reality, and signed off by people who have skin in the game. The board's confidence follows the quality of the assessment, not the optimism of the team.

"What happens if we do nothing?" Nothing gets better on its own; programmes in crisis don't self-correct. The longer you wait to intervene, the fewer options you have.

The Resulting Approach to SAP Programme Recovery

At Resulting, we've worked alongside some of the world's most complex SAP programmes; we know what a programme in trouble looks like, so we know what it takes to turn one around.

Our rapid programme health check gives you an honest, independent view of where your programme stands within days. No jargon, no lengthy discovery process, just a clear picture and a practical path forward.

We work with CIOs, programme sponsors, and incoming leaders who need a straight answer and a credible plan. If that's you, let's talk.

Your programme isn't beyond recovery, but the window to act is narrower than you think.

Book a rapid programme health check now