Governing a Multi-Year SAP Program: Operating Model, Quality Gates, and Escalation Paths

How to structure governance for a multi-year SAP program — RACI, steering committee cadence, quality gates and escalation tiers that keep it on track.

A multi-year SAP program needs its governance model before the first phase starts, not after the first major delay exposes gaps in decision-making.

That matters because the people, scope, priorities, and even the definition of "done" can change over the course of a long transformation. Without written decision rights, a program can continue moving while critical questions remain unresolved: Who can approve a scope change? Who decides whether a failed test blocks the next phase? Who accepts residual risk before go-live?

A practical governance model answers those questions through three connected layers. An executive steering committee owns material scope, budget, and go/no-go decisions, with the executive sponsor chairing or representing the committee. A program management office (PMO) coordinates delivery and reporting. Workstreams execute the work and escalate issues they cannot resolve.

To make that structure operational, your program needs four written artifacts:

• A RACI that names roles on both the customer and partner sides.
• A steering committee charter that states what the committee approves, not just what it reviews.
• Quality gates at each phase boundary halt progression until defined criteria are met or a formally approved exception is granted.
• Escalation tiers with a named owner and agreed response time.

Everything else in the operating model builds on those four controls.

Current cross-industry project data shows why this discipline matters. PMI's 2025 Step Up: Redefining the Path to Project Success with M.O.R.E. report, using a combined 2024–2025 sample, rated 53% of IT implementation and upgrade projects as successful, 36% as mixed, and 10% as failures under PMI's value-based measure of project success.

PMI's 2026 Pulse of the Profession found that 31% of complex projects failed to achieve the full scope of their intended benefits, while 81% of project professionals said projects had become more complex in recent years. These are not SAP-specific benchmarks, but they illustrate the governance challenge surrounding large transformation programs.

Why Does Governance Decide Whether a Multi-Year SAP Program Succeeds?

A multi-year program often outlives some of the decisions, assumptions, and people that started it. Governance provides continuity when those elements change.

Implementation partners typically bring a methodology, but methodology and governance solve different problems. A methodology defines what happens during each phase. Governance defines who has the authority to make a decision when cost, scope, schedule, quality, or business priorities conflict.

That distinction becomes increasingly important as the program progresses. Partner directories and buyer guides can help you decide whom to hire. They do not determine how a disputed defect, late dependency, or unexpected scope request will be handled six months after kickoff.

Your governance model, therefore, has to survive at least four common changes:

• A new executive sponsor, without decision rights, is leaving with the previous person.
• Scope growth that accumulates through a series of individually small requests.
• Turnover across both customer and partner delivery teams.
• A change in what the business considers complete or acceptable as the program progresses.

The goal is not to eliminate change. It is to make sure that change follows a known decision path.

What Does the Operating Model Look Like Across Roles and the RACI?

The first step is to translate governance principles into recurring decisions. A RACI matrix assigns who is Responsible for doing the work, Accountable for the outcome, Consulted before a decision, and Informed afterward. In a large SAP program, it is more useful to think of the RACI as an organizational chart for decisions rather than for people.

For example, an SAP S/4HANA migration RACI might assign the following responsibilities:

For material changes that affect the approved budget or schedule, and for go-live decisions, the steering committee is the accountable approval body. The executive sponsor chairs or represents that body rather than holding a separate layer of accountability outside it.

Two principles make a RACI like this useful in practice. First, use exactly one A for each decision path. If accountability is divided between several roles, an issue can circulate between teams without anyone having clear authority to close it. Second, keep accountability for business decisions on the customer side. The partner may perform much of the design, configuration, integration, migration, or testing work, but decisions about business process design, material scope, and go-live ultimately belong to the organization implementing the system. Delivery or service accountability can sit with the partner where the contract explicitly assigns it.

Otherwise, responsibility can cross the contractual boundary without either party formally agreeing to it.

The customer organization also needs enough named people to fill its side of the model. In one SAP ECC-to-SAP S/4HANA migration completed between April and December 2022, 13 LeverX specialists worked alongside 25 customer team members across finance and controlling, procurement, sales and distribution, customer service, Basis, and ABAP development.

In that program, the customer side was larger than the partner team. A RACI that describes only the system integrator's organization would therefore leave much of the actual program governance undefined.

How Should the Steering Committee and Escalation Tiers Work?

Once decision rights are assigned, the next question is where unresolved decisions go. A steering committee should be the program's senior decision-making body, with authority over material changes to scope, budget, and schedule, as well as go/no-go decisions and issues that the delivery organization cannot resolve.

If the committee only receives status reports, it is not functioning as a governance body. The charter should therefore distinguish between decisions and information. The committee might approve phase budget releases, material scope changes, go-live decisions, and the resourcing plan for the next rollout wave. It can be briefed on status reporting, the risk register, and benefit tracking without turning every update into an approval.

Its recurring metrics should also be explicit. These may include:

• Schedule variance against the phase plan.
• Defect backlog against the agreed threshold.
• Data-quality pass rates before the next gate.
• Benefit realization against the business case.

A monthly cadence is often sufficient through normal delivery, with meetings moving to every two weeks around major gates or go-live. Between meetings, the PMO should maintain a decision log.

That log becomes particularly valuable during leadership changes. Without it, decisions made in meetings or email threads can disappear with the people who made them, leaving a new sponsor to reconstruct why the program took a particular direction.

Not every issue should go directly to the steering committee, however. A defined escalation path allows teams to resolve problems at the lowest level with the authority to act.

A gate exception needs the same discipline as any other material decision. Record the unmet criterion, residual risk, responsible owner, remediation date, and approving authority.

Response times matter as well. They should be negotiated rather than copied automatically from the partner's standard template. The RFP stage is often the best time to define them because both parties still have room to establish expectations.

An escalation tier without a response time defines where an issue goes, but not when it needs to come back.

Where do transformations succeed, and where do they stall?

Explore how executive decision authority, business ownership, and implementation-partner input can be structured within SAP transformation governance.

Find more

What Do Quality Gates Look Like Across SAP Activate Phases?

Escalation controls what happens when a problem appears. Quality gates determine whether the program should move forward despite it.

In this governance model, a quality gate is a phase-exit checkpoint that confirms that defined criteria have been met before the program proceeds, unless an authorized exception is documented and approved.

SAP Activate provides the phase structure: Discover, Prepare, Explore, Realize, Deploy, and Run. The governance model should map its decision gates onto the applicable SAP Activate roadmap rather than creating a generic checklist disconnected from the implementation method.

Ask the partner to confirm which quality-gate activities and criteria apply to the roadmap being used, including programs delivered under the RISE with SAP Methodology.

Explore deserves particular attention because fit-to-standard workshops establish how the target solution will support the business processes.

Before leaving the phase, the team should complete the applicable SAP Activate quality-gate activities, confirm the solution design, and document identified gaps, extensions, integrations, conversions, and other required developments. Where the project methodology uses one, a RICEFW register can structure Reports, Interfaces, Conversions, Enhancements, Forms, and Workflows.

The governance layer then turns those delivery outputs into exit criteria. For example:

These are example governance controls, not a replacement for the quality-gate criteria in the SAP Activate roadmap. The exact criteria and signatories should reflect the implementation approach and the organization's governance model.

For a long program, a phased delivery structure can also provide controlled points for assessing readiness before additional scope is introduced. In one SAP implementation for Enable Injections, a medical-device manufacturer serving pharmaceutical companies, the scope was structured across four phases. Financials came first. Materials, production, controlling, and document management followed, with PLM, quality, plant maintenance, and regulatory tooling introduced in later phases.

Each wave can then run through its own gate sequence. If a data-quality problem appears in one wave, this structure can limit its impact to that wave, provided the issue does not affect shared master data, the global template, integrations, or downstream dependencies.

The practical benefit is not simply better reporting. It gives the program a controlled point at which to decide whether the next part of the transformation is ready to absorb additional scope.

How Do You Govern One Partner Across Strategy, Implementation, Integration, and Managed Services?

Governance becomes more important, not less, when one provider covers most of the transformation lifecycle. Putting strategy, SAP implementation, SAP integration, and SAP Managed Services with one partner can reduce disputes between multiple vendors over who owns a cross-system defect.

At the same time, it concentrates delivery responsibility within one commercial relationship. The operating model, therefore, needs controls that a single-project RACI may not address. The first is an explicit accountability boundary at every major handover. Strategy should hand an approved roadmap for delivery. Implementation and integration teams jointly deliver the solution. The delivery organization then transfers an accepted production environment into managed services.

Each handover needs acceptance criteria written with the same discipline as a quality gate. Otherwise, unresolved work can move from one delivery organization to another without a clear owner.

What Transfers at the Handover Into Managed Services?

The transition to managed services is one of the points where accountability can become unclear, as the implementation team leaves and another team assumes responsibility for production.

Define the transfer explicitly. At a minimum, it should cover:

• Open defects, each with a named resolution owner.
• Configuration documentation.
• The support model and its response times.

Change management needs the same treatment. Give it a named lead, define its responsibilities in the RACI, and include relevant deliverables in the phase gates.

For a long transformation, change management can sit within business transformation management, alongside the process redesign on which adoption depends. Multi-country programs add another governance question: when does the delivery organization need to scale?

In one rollout, the program expanded from Lithuania into Poland, Georgia, Spain, the Netherlands, and the Nordics. The LeverX delivery team grew from five people to 20 as additional waves were introduced. Instead of renegotiating capacity after teams become overloaded, put resourcing triggers within the steering committee's remit before the next rollout wave begins.

Accelerate SAP S/4HANA Transformation With SAP Migration Factory

Our guide examines a standardized operating model for managing repeated migration waves under a common governance framework.

Dive in

The same principle applies when evaluating a prospective partner. Ask the bidder to provide governance artifacts from programs it has already delivered: a gate register, a decision log, and an escalation record. These materials provide more evidence about how a team operates than a methodology diagram alone.

LeverX holds SAP Gold Partner status and ISO 9001, ISO 27001, and ISO 22301 certifications. Our teams cover SAP consulting, SAP implementation, SAP S/4HANA migration, SAP Application Management Services, and enterprise software development as part of a broader program. Whichever firms are on your shortlist, the governance questions should remain the same.

If you already have a draft RACI, bring it to the first conversation with our SAP consulting team. The rows nobody can confidently fill are often the areas where escalation paths need the most attention.

FAQ