Understanding the RISE with SAP Methodology: Seven Decisions Project Managers Should Not Delay

By Miguel Santos | SAP Advisory & Technical Writing · SAP & Management
A transformation programme can have an approved budget, an implementation partner and a detailed schedule—and still lack clarity about who makes critical decisions.
Who can approve a deviation from standard? Who owns an interface that crosses organisational boundaries? What evidence is required before the programme moves to the next phase? Who will operate the solution after hypercare?
Understanding the RISE with SAP Methodology means understanding how these questions affect delivery.
SAP positions the methodology around a standardised framework, expert guidance and an integrated toolchain. It builds on SAP Activate, incorporating clean core activities, a success plan and quality gates across the transformation journey. SAP methodology overview
For project managers, the immediate challenge is to translate that framework into ownership, evidence and timely decisions.
The following seven priorities are where I would focus management attention.
1. Validate the starting point before committing to the delivery baseline
The implementation team needs a shared understanding of what has been assessed, proposed and agreed.
Review the discovery outputs, architecture assumptions, sizing, scope, dependencies and expected business outcomes. Identify what remains unvalidated and make its impact visible.
SAP’s framework explicitly includes a handover of business value and architecture information from Discover into implementation. That handover deserves management attention. SAP Learning: Standardized Framework
Act now: establish an agreed baseline, with an owner and a resolution date for every material assumption.
A schedule built on unresolved assumptions creates confidence that the programme has not yet earned.
2. Clarify responsibilities across the customer, SAP and implementation partners
A programme may involve several organisations, each with its own contractual scope, delivery processes and escalation routes.
The project manager must connect those responsibilities into one workable delivery model.
Pay particular attention to system provisioning, connectivity, security, integrations, data migration, testing, transports, cutover and incident management. Validate responsibilities against the applicable contracts and service descriptions.
Act now: create a responsibility matrix that covers handovers between teams, including who accepts the output.
“SAP will handle it” and “the partner owns it” are incomplete answers when a dependency sits between them.
3. Give clean core decisions a governance mechanism
Clean core needs to influence design decisions while alternatives are still available.
For each proposed deviation from standard, ask:
- What business requirement justifies it?
- Can standard functionality or process adaptation meet the need?
- What are the implications for integration, security, testing and future upgrades?
- Who will own and maintain the solution?
Act now: introduce a design authority and a documented exception process before significant development commitments are made.
The project manager does not need to make every architecture decision. The project manager must ensure that the right people make those decisions, with the consequences understood.
4. Put quality gates into the integrated plan
A quality gate should have preparation activities, evidence owners, review time and a route for resolving findings.
SAP describes clean core quality gates as checkpoints supporting the success plan and project KPIs, with questionnaires and feedback forming part of the review cycle. SAP Learning: Quality Gates
Act now: work backwards from each gate. Define the required evidence, the accountable reviewers and how unresolved findings will affect progression.
Submitting a questionnaire does not, by itself, demonstrate readiness.
Where internal approval is required, distinguish clearly between SAP’s recommendations and the organisation’s own decision to proceed.
5. Establish traceability in SAP Cloud ALM early
Tools support governance when the programme agrees how to use them.
Define how requirements, tasks, tests, defects and readiness evidence will be maintained and connected. Where other delivery tools remain in use, agree which system holds the authoritative record and how information will be reconciled.
SAP identifies SAP Cloud ALM as a tool for orchestrating transformation using SAP Activate road maps, checkpoints and quality gates. SAP methodology overview
Act now: agree the minimum reporting and traceability model during preparation.
A steering committee should be able to understand what is complete, what evidence supports that status and which decision is needed next.
6. Bring integration, data and cutover risks forward
Interfaces and data can connect workstreams that otherwise appear to be progressing independently.
An interface may be technically available while its business reconciliation remains undefined. A migration load may complete while data ownership and acceptance remain unresolved.
These gaps can emerge late, when the programme has little room to respond.
Act now: build an end-to-end dependency view covering interface ownership, middleware, external parties, data quality, reconciliation, test environments and cutover sequencing.
Include rehearsals and recovery arrangements in the plan. Where rollback is constrained or impractical, define the applicable recovery and business continuity approach explicitly.
Readiness needs to be demonstrated across the business process.
7. Design the Run model before go-live
The methodology extends into Run. Project planning should reflect that continuity.
Operational ownership, monitoring, access management, release governance, support escalation and knowledge transfer need to be developed alongside the solution.
Act now: appoint operational owners early and agree measurable criteria for entering support and exiting hypercare.
Those criteria should address service stability, unresolved defects, monitoring coverage, documentation and the support team’s ability to manage the solution.
A successful handover is an operational capability, supported by evidence.
What should project managers do this week?
Start with a focused readiness review:
- Which assumptions still underpin the approved plan?
- Which responsibilities remain unclear between organisations?
- Which design exceptions lack an accountable decision?
- What evidence is missing for the next quality gate?
- Which integration or data dependency could disrupt testing or cutover?
- Who will own the service after hypercare?
Assign an owner and a decision date to each material gap. Escalate the items that require executive authority.
Urgency should be driven by the cost of delaying a decision and its effect on subsequent work.
The leadership responsibility
The RISE with SAP Methodology provides structure. Its practical value depends on how consistently the programme uses that structure to expose uncertainty, resolve dependencies and demonstrate readiness.
For project managers, this requires technical understanding, commercial awareness and the confidence to challenge unsupported progress.
The most valuable decision is often the one made early enough to preserve better options.
Which of these areas creates the greatest delivery risk in your experience: responsibility boundaries, clean core decisions, integration readiness or the transition to Run?
#RISEwithSAP #SAPActivate #SAPTransformation #ProjectManagement #CleanCore