Now accepting guest editorial from SAP, Oracle, Workday and ServiceNow practitioners.Pitch a guide
The Sign-Off Table

Lesson 4 of 5

Delivery implications: timeline and governance

7 min

RISE and GROW change how a program is planned and governed. Some work disappears, such as buying hardware. Some new work appears, such as managing service requests, coordinating SAP maintenance windows and tracking a cloud release calendar. This lesson turns the responsibility split into planning rules for the PMO.

New items in the plan

  • Provisioning lead time. Private cloud systems are built by SAP after the contract; the first sandbox or development system is a dependency for Prepare activities.
  • Service requests. System copies, updates, additional systems and some technical changes are requested through SAP's service channels, with lead times and approvals.
  • Maintenance windows. SAP schedules technical maintenance; mock cutovers and test cycles must avoid them or be planned around them.
  • Release calendar. Private edition customers plan Feature Package Stacks and upgrades; public edition customers inherit SAP's upgrade dates.
  • Tool onboarding. SAP Cloud ALM, SAP Signavio and other bundle tools need tenants, users and owners before Explore.
  1. PrepareContract to first systemsOrder form confirmed, Cloud ALM provisioned, private cloud sandbox and development requested from SAP
  2. ExploreDesign within the bundleFit-to-Standard; extension and integration choices checked against BTP entitlement
  3. RealizeBuild and testService requests for QAS refreshes planned; test cycles placed around SAP maintenance windows
  4. DeployRehearse and go liveProduction cutover coordinated with SAP ECS; rehearsal system copies requested well in advance
  5. RunOperate under the contractFeature Package Stacks and upgrades requested, tested and approved by Contoso
Where RISE adds work to each phase of Contoso's plan.
The Sign-Off Table · thesignofftable.com/academy/sap-pmo-102

A GROW project plans differently again. Because SAP upgrades public edition tenants on its own calendar, the PMO places the go-live and every major test cycle against that calendar first, then fits the rest of the plan around it. A UAT cycle that straddles an upgrade of the test system has to be re-scoped or repeated, so experienced public edition teams treat the upgrade dates as fixed milestones from the first week of Prepare.

Three-party governance

Governance under RISE needs SAP in the room, but not everywhere. Contoso's steering committee stays a Contoso forum with the partner present. SAP joins a separate service governance meeting, usually with an SAP delivery or customer success contact, to review service requests, incidents, maintenance plans and upcoming updates. Grace links the two: items from the service meeting that affect scope, dates or risk go to the steering committee through the RAID log.

Steering committee (monthly)Contoso executives, Grace, partner leadership: scope, budget, gates and go-live
Program management (weekly)Grace with workstream leads: plan, RAID, dependencies
Service governance (bi-weekly)Contoso Basis lead, Grace, SAP service contacts: requests, maintenance, updates
Workstream stand-ups (daily)Build, data, integration and test teams
Contoso's governance layers under RISE. SAP joins at the service layer; decisions stay with Contoso.
The Sign-Off Table · thesignofftable.com/academy/sap-pmo-102

Planning for clean core

RISE and GROW both push customers toward a clean core: staying close to standard, extending through released interfaces, and keeping custom code out of the core where possible. For a PMO this is not only an architecture principle. Each deviation from standard adds build effort, test effort for every future update, and risk at each upgrade. Many programs set up a standardization board or design authority that reviews every proposed deviation with its business reason and long-term cost; the next courses in this track cover that in detail.

  1. Deviation proposedA workshop finds a gap the standard does not cover
  2. Business caseValue, alternatives in standard, cost to build and to retest at every update
  3. Design authority reviewApprove, reject, or redirect to a standard or side-by-side option
  4. RecordedDecision and rationale linked to the requirement in Cloud ALM
A clean-core deviation flow. Under RISE and GROW, every approved deviation also adds to the regression suite.
The Sign-Off Table · thesignofftable.com/academy/sap-pmo-102

What would you do?

Contoso's partner wants to schedule SIT cycle 2 across a weekend that SAP has announced for technical maintenance of the QAS system. The partner says "it is only a few hours." What should Grace decide?

Key points
  • RISE adds provisioning, service requests, maintenance windows and release planning to the program plan.
  • Keep decisions in Contoso's steering committee; meet SAP in a separate service governance forum and route impacts through RAID.
  • Clean core is a delivery principle: each deviation adds build, test and upgrade cost.
  • Confirm the bundle's tool and platform entitlements before designing integrations and extensions.

Check your understanding · not graded

Lesson check

  1. 1. Which item is new in a RISE plan compared with a self-managed ECC program?

  2. 2. Where should SAP service topics be reviewed at Contoso?

  3. 3. Why does clean core matter to a PMO?

  4. 4. What should happen to an SAP maintenance window that overlaps a planned test cycle?