Lesson 3 of 5
Residual risk and conditions
9 min
No SAP release goes live with zero risk. There are always open defects, untested edge cases and late changes. Good governance does not pretend otherwise. It makes the remaining risk explicit, puts it in front of the person who owns the consequence, and records what they decided.
Writing a risk statement
"Defect 4711 is open" is not a risk statement. A risk statement says what could happen, to which process, how likely it is, what the impact would be, what the workaround is and who owns it. Priya converts every open high-priority defect into one before the board.
- CauseDefect 4711: rebate accrual not posted for one condition type
- EventRebate accruals for Great Lakes Fleet Services understated at month-end
- ImpactAccrual too low by an estimated amount; manual journal entry needed
- LikelihoodCertain for that customer until fixed
- WorkaroundFinance posts a manual accrual from a report; procedure documented
- Owner and dateDan accepts; fix planned for Release 1.1
Conditions versus accepted risks
| Type | Meaning | Example at Contoso | Follow-up |
|---|---|---|---|
| Condition | Must be done by a date for the go decision to hold | Test month-end jobs before the first close | Owner reports completion; if missed, escalation to the board |
| Accepted risk | Known issue the owner accepts with a workaround | Manual rebate accrual until Release 1.1 | Tracked until fixed; workaround monitored |
| Rejected risk | Owner will not accept it; the release must change | Wrong tax determination on intercompany billing to 1810 | Fix before go-live or remove scope |
Three outcomes for each residual item.
Who may accept what
Write down who can accept which risks before go-live week. A process owner can accept risks within their process; a risk that crosses processes or has financial statement impact goes to the sponsor or steering committee. The test lead never accepts business risk, and the release manager never accepts a risk on a process owner's behalf, however late the hour.
- RaisedPriya or Luis writes the risk statement
- Process ownerDan or Maria accepts or rejects risks within their process
- Named deputyTakes the decision if the owner cannot be reached in the agreed time
- Sponsor or steering committeeDecides cross-process risks and anything with financial statement impact
- RecordedDecision, name and time added to the decision record
Risks add up
Each accepted risk may be small on its own, but ten small risks in one process can overwhelm the people running it in week one. Before the go decision, Priya groups accepted risks by process. If order to cash carries six manual workarounds, Maria needs to confirm her team can run all six at once, alongside learning a new system. Sometimes the right decision is to fix two of them first, even though each was acceptable in isolation.
Accepted risks also need an expiry. "Manual rebate accrual until Release 1.1" is acceptable; "manual rebate accrual" with no end date quietly becomes the process. Every accepted risk carries the date or release by which it will be fixed, and Grace reviews overdue ones monthly.
What would you do?
It is 11 p.m. before go-live. A new defect appears in intercompany billing between 1710 and 1810. Dan cannot be reached. The developer suggests Luis accept the risk so the cutover can continue. What should Luis do?
- Write each open issue as a risk statement: cause, event, impact, likelihood, workaround, owner.
- Separate conditions (must be done by a date) from accepted risks (known, with workaround).
- Only owners with authority accept risk; agree the escalation path in advance.
- Likely and severe risks are rejected: fix or remove scope.
Check your understanding · not graded
Lesson check
1. What distinguishes a condition from an accepted risk?
2. Who should never accept business risk at the board?
3. A risk is likely and severe. What is the usual decision?