Why another SAP project failed, and what it teaches us about Project Governance

The Zimmer Biomet SAP S/4HANA failed project shows how even experienced organizations can face serious trouble with ERP transformations. Despite the involvement of a global consulting partner like Deloitte, the program ended in operational disruption and financial loss, resulting in a $172 million lawsuit against Deloitte.

This is not a story of failed technology, but of weak governance, overreliance on a single partner, leadership changes, and a rushed go-live under pressure. Let’s examine what failed — and more importantly, what every organization should do to avoid repeating this in their next SAP (or ERP) transformation.

What happened?

There are a few critical mistakes that were made in the area of project governance and
project execution

1. Ignored business readiness under aggressive timeline - the project schedule prioritized meeting a cutover date over ensuring business readiness. This has led to rushing, system instability, and major defects in core processes.
2. Scope creep with change requests - rather than locking in scope early, the project tolerated numerous changes to its scope. Many change orders were the results of the initial weak scope planning and shifting priorities during the delivery
3. Leadership and structural instability - the SAP Cutover phase coincided with layoffs (3 % of workforce) and a CEO transition on top of it. This created the pressure to “just go live” as soon as possible.
4. Resource turnover & offshore team over reliance - high turnover in contributing teams and over reliance on the off shore teams in India disrupted continuity, local know-how, and consistent project execution.
5. Weak contractual client protections - the contract lacked solid acceptance criteria, holdbacks, and quality enforcement triggers. All this could be then a part of their project governance plan.

Each of these issues or their impacts could have been prevented by structured governance with clear accountability, validation gates, and stable leadership.

Why Project Governance matters?

SAP Project Governance is the system of internal discipline: checkpoints, decision Q-Gates, project roles, escalation paths, and independent auditing oversight. That keeps a complex transformation from falling off the delivery rails and loosing the focus on currently most important projects aspects.

• With governance, there is no place for rushing to the next stage when the objective data about outcomes show that the project is not yet ready.
• Without governance, even the best technical teams and the most sophisticated project management tools will not rescue a project from scope drift, political pressures, or misaligned events in business reality.

What could have been done differently

In Zimmer's case, governance should have acted as a counterweight to vendor over-assurances, internal optimism, and executive distraction.

Your Project Governance focus checklist

Here is a list of Governance Focus points and Key Controls / Actions you can take to protect your SAP project from failure resulting from weak project governance.

1. Independent project approach and schedule validation - set realistic expectations for delivery timelines and project complexity. A third party or internal oversight should review estimates, scope, risks and assumptions. Don’t accept vendor’s promises just because your companies have worked a long time together.
2. Contract structure - define milestones, acceptance criteria, payment holdbacks, and specific quality metrics. Embed exit or remediation clauses.
3. Change control - all change requests must pass through a Change Board. It has to be clear who approves what and when. No additional job gets done without a formal work order resulting from an approved change request.
4. Tool-based workflows - use a tool (e.g. Jira + approvals) to route any requirement, scope item changes, or defects through an agreed governance workflow. This will not slow you down - this will secure your outcomes quality.
5. Go/No-Go gates - in each project phase, require a formal Q-Gate criteria sign-off by a cross-functional internal team. This will ensure their involvement and personal engagement.
6. Business Readiness checks - validate process simulations, data integrity, user training, cutover dress rehearsals. Have measurable exit criteria. Also, involve internal decision makers and key users. Let them taste the technology, before it arrives at their desks.
7. Hypercare escalation path - ensure immediate visibility of PGLS (Post Go-Live Support) critical issues using a tracking tool like Jira. Introduce a governance path to mobilize resources by type of issue with internal SLA in place (Service Level Agreement)
8. Holdbacks & payments - tie final payments to delivering agreed outcomes, not just configuration. Involve key users to check-points and UAT to confirm that the system works as expected before releasing the next payment.
9. Independent review & audit - conduct a formal review, compare promised vs actual metrics, ensure know-how hand over to solution support

Governance is not bureaucracy. When done right, it is your risk receptor: the structure that prevents or catches problems early, so they do not negatively impact your project.

Final 3 questions to you

Zimmer Biomet’s lawsuit is a striking reminder that even large organizations with experienced System Integrators like Deloitte consulting can fail spectacularly when governance is understated or ignored, especially on the client's side.

If you’re sponsoring, governing, or delivering an SAP transformation today, ask yourself:

• Do you have project governance in place before the first euro from project budget is spent? If not, what gives you confidence in the project’s progress? Is it your genuine oversight based on independent project delivery status data or just "always green" PowerPoint updates from your System Integrator?
• Do you follow a proven SAP Activate methodology integrated with governance, which you follow phase by phase? If not, how will you protect your project from team's improvisation disguised as technical experience? Have you already heard the fairy tale "it is too complex to explain what has been completed so far"
• Do you have defined quality gates and checkpoints that verify delivered and validated outcomes? If not, how will you protect yourself from wishful thinking and late-stage surprises about data management, business readiness and testing results?

If your answer to these questions is "no", you’re not just at risk of project delays. You may be preparing your company to be next in the headlines about yet another failed SAP project (or you might soon need that badge #opentowork on LinkedIn)

Want to know more about SAP Project Management?

Download my White Paper “Why SAP Projects Fail”. It gathers real project cases and lessons learned from SAP programs and explains how structured governance can prevent them. It is free to download directly and your e-mail is not needed.