Creating an effective SAP project steering committee

An SAP project steering committee is the small group of executives who make the calls the project team cannot: budget, scope changes, cross-department conflicts and the final go/no-go. It works when the members have real authority, meet often enough to decide in the meeting, and judge readiness on evidence rather than the calendar. This guide is for sponsors and programme directors setting up a committee or fixing one that has become an audience for status reports. It covers what the committee must decide, membership by project size, how decisions should work, a go/no-go checklist, and what RISE with SAP and AI tools change.

I have never seen an SAP project succeed with a weak steering committee. The committee is where tough decisions happen. Either they happen in real time, or they pile up until they explode at cutover.

On one SAP rollout, the committee met once a month. The project team flagged broken approval workflows, incomplete testing and missing training. Leadership said it would "review it". It never did. The project went live, and finance spent the next six months cleaning up.

At another company, the committee met weekly and made real decisions. When testing revealed gaps, it reassigned resources. When a process was not working, it fixed it. That project went live smoothly.

One committee led. The other sat in meetings.

If the committee is only receiving status reports, it is already failing. The table shows the difference in practice.

Function	What good looks like	What weak looks like
Major decisions	Reviews the case and decides on the spot	"Let's discuss offline"; the issue returns next month
Roadblocks	HR delaying testing? The chair calls the department head directly	Acknowledges the problem and logs it
Scope	Weighs every change request against the plan	Rubber-stamps whatever is escalated loudest
Risk	Sees a vendor struggling and lines up backup before delays hit	Waits to see if it resolves itself
Budget	Approves an extra $2M to extend three months because the disruption would cost more	Pushes it to next month
Go/no-go	Delays go-live six weeks because testing is not complete, and holds the line	Approves go-live because the date is on the calendar

The last row matters most. I have seen committees push back go-lives even when teams wanted to charge ahead. One pharmaceutical client's committee delayed go-live by six weeks because testing was not complete. Tough call, but it saved them from a disaster.

Too many members and the committee cannot decide. Too few and critical voices are missing.

Project size	Budget and scope	Members	Who must be in the room
Small	Under $0.5M, one department, under 6 months	3 to 5	Department head, IT lead, finance representative
Mid-market	$0.5M to $5M, several departments, 6 to 18 months	5 to 8	Business leads from affected departments, IT leadership, finance
Enterprise	Over $5M, enterprise-wide, 18 months or more	8 to 12	C-level from finance, HR, operations and IT; programme manager; change lead

The rule I apply: include people with real decision authority. I have seen committees fail because senior titles could not approve anything without checking with someone else. If the CFO cannot attend, send someone with a genuine mandate to decide, not to report back.

The chair should be the project sponsor, usually a C-level executive who can hold other executives to account. A middle manager chairing the committee cannot overrule a CFO, and that authority matters when scope or budget conflicts surface.

On evidence. I worked with a manufacturing client whose IT team said a process change would add three months. The business insisted it was "simple". The committee refused to decide until it saw effort estimates, dependency analysis and capacity planning. IT was right. The committee got it right because it demanded evidence rather than siding with the loudest voice.

Fast. I have seen a client whose committee met every two weeks but always ended with "we will discuss this offline". Issues piled up until the project was six months behind. Another client's committee made decisions in the room, and its project finished early and under budget. Slow committees produce late projects.

With explicit authority. Effective committees can overrule department heads, approve unplanned budget and reject scope additions mid-flight. If those powers are not written down and understood, the committee becomes advisory, and advisory committees do not deliver SAP projects.

On scope, selectively. At one of my clients, a department suddenly demanded 20 extra reports. The committee asked whether each one was needed now and whether it would break the timeline. It approved five critical reports and moved the rest to after go-live. That decision probably saved the go-live date.

Keep meetings to 60 to 90 minutes. Top risks, the specific decisions needed, and actions with owners and dates. No technical updates that could be read beforehand. If the same issue appears three meetings running without resolution, you have a governance problem, not a complexity problem.

Use data, not decks. I worked with an energy client that built a dashboard of test execution, defect resolution, training completion and budget burn. Meetings stopped being about understanding where things stood and started being about solving problems.

Show the committee the system. One pharmaceutical client's committee walked through a "day in the life" scenario. It realised the approved design would make staff use five different screens for a common process. It ordered a redesign immediately.

Plan for politics. The most common failure is not incompetence. It is departments protecting territory and teams delaying testing because of year-end work. On one project, HR kept delaying payroll testing because it was busy with year-end tasks. The committee reprioritised work and assigned backup testers, and the project stayed on track instead of slipping for months.

Use independent checks at major gates. A manufacturing client had external reviewers evaluate its readiness before approving go-live. The review found several serious issues the project team had missed or downplayed. My guide to SAP quality gates shows how to structure those checkpoints.

Calendar pressure is the wrong basis for approving go-live. Before the vote, the committee should see evidence on each of these:

1. Integration and user acceptance testing complete, with no open critical defects
2. Final mock data migration reconciled and signed by finance
3. Cutover rehearsal completed inside the planned window
4. Key users trained, with floor support and job aids ready
5. Business readiness confirmed in writing by each process owner
6. Rollback plan tested and agreed
7. Hypercare team, escalation path and first-close support in place

If any item is red, a strong committee says no. A six-week delay is recoverable. A failed go-live that disrupts operations or the financial close can take months to stabilise. I have cleaned up too many go-lives that were approved because the date felt immovable. Feed the committee's agenda from a live risk register so these items surface early.

RISE brings SAP into the governance model. On RISE with SAP, SAP runs the infrastructure and technical operations. SAP's RISE roles and responsibilities document has customers working with an SAP Cloud Architect Advisor, a Client Delivery Manager or SAP's private cloud customer centre. For platform issues such as performance, availability or service levels, the committee needs a route to those contacts that does not run through the implementation partner. Invite them for the relevant agenda items rather than as permanent members.

A clean-core forum belongs below the committee. On RISE programmes, set up a design authority that approves or rejects customisation requests against clean-core principles. It escalates to the committee only when a business-critical request is blocked. Without that layer, every customisation becomes a committee fight. On-premise, the traditional model still applies and SAP is a vendor, not a participant.

1. Steering committeeChaired by the sponsor. Budget, scope, conflicts, go/no-go
   SAP delivery contactsInvited for platform items, not routed through the partner

• Programme management officeDay-to-day execution, risk log, coordination
• Clean-core design authorityRules on customisation, escalates only blocked critical requests

AI saves time on the paperwork. Microsoft 365 Copilot drafts minutes from the recorded meeting. The work becomes reviewing a draft rather than writing from scratch, and the decisions come from the transcript. Atlassian's Rovo can turn meeting notes into structured decision-log entries once the template is built. Joule-based assistants in SAP Cloud ALM can draft a first impact assessment for a scope request, so the committee can decide in the meeting instead of deferring.

Skip sentiment analysis for now. Some vendors pitch sentiment analysis of programme communications as a committee input. On most programmes it is theatre: the signal is weak, false positives are common and being seen to monitor sentiment has a political cost. Only on very large programmes can it flag disengaging groups early. For most committees it is not where to spend the AI budget.

What is the role of a steering committee in an SAP project?

It makes the decisions the project team cannot: budget approvals, scope changes, resource escalation and the final go/no-go. It resolves cross-department conflicts and holds department heads to their testing and training commitments. If it only receives status updates, it is not doing its job. The value is in the decisions made, not the meetings attended.

How many people should be on an SAP steering committee?

Three to five for a small, single-department project; five to eight for mid-market; eight to twelve for an enterprise programme. The usual failure is too many people: a committee of 20 becomes a presentation audience. Every member should have real decision authority over something. On RISE, bring SAP's delivery contacts in for platform items rather than as permanent members.

How does RISE with SAP change the steering committee?

SAP becomes a delivery participant for infrastructure and technical operations, so the committee needs a direct route to SAP's assigned contacts that does not run through the implementation partner. It also needs a clean-core design authority below it to handle customisation requests, with only blocked business-critical requests escalated. On-premise, SAP remains a vendor.

What is the difference between a steering committee and a PMO?

The project management office runs day-to-day execution: tasks, risk logs and coordination across workstreams. The steering committee makes the decisions the PMO cannot: budget shifts, scope changes and go/no-go. In larger organisations a portfolio-level committee sits above several projects and allocates resources between them.

What should be on a steering committee agenda?

Decisions, not updates. Start with the top three to five risks, then the specific decisions needing sign-off, then cross-department issues to resolve, then actions from the last meeting with owners and dates. If an item appears three times without resolution, escalate how it is being handled rather than discussing it again.

When should the steering committee delay go-live?

When testing is not complete, key users are not trained, data migration is not reconciled, a critical integration is unstable, or the rollback plan is untested. A delay is almost always cheaper than post-go-live cleanup. A six-week delay is recoverable; a failed go-live that disrupts the supply chain or the financial close can take months to stabilise.