Lesson 5 of 5
Post-release review
9 min
Every release teaches you something. The post-release review is where you collect the lesson before memories fade and hypercare noise drowns it out. Done well, it makes the next readiness checklist sharper. Done badly, it becomes a blame session that teaches people to hide problems.
Blameless by design
Site reliability engineering practice popularized the blameless postmortem: focus on contributing causes, not individuals, and assume everyone acted in good faith with the information they had. The reason is practical. If the person who imported the wrong transport expects punishment, the next incident will be reported late or not at all. SAP programs benefit from the same discipline.
- Go-live + 1 dayCaptureHypercare lead logs incidents, workarounds and surprises daily
- Go-live + 2 weeksDraft reviewLuis drafts the timeline, impact and contributing factors
- Go-live + 3 weeksReview sessionProcess owners, test, Basis and development review the draft
- Go-live + 4 weeksActions agreedOwners and dates; readiness criteria updated
- Next release boardFollow-upGrace reports action status before the next decision
When to hold one
- After every major release and go-live, regardless of how it went.
- After any release that caused a priority 1 incident or needed an urgent fix within days.
- After any production data correction caused by a release.
- After any fallback or rollback was invoked.
- When a process owner asks for one.
What the review covers
| Section | Questions |
|---|---|
| What happened | Timeline of the release and the incidents that followed; business impact |
| Readiness versus reality | Which criteria were met but did not predict the problem? Which were missing? |
| Contributing factors | Process, tooling, data, communication, timing; never "person X made a mistake" |
| What went well | Practices worth keeping or spreading |
| Actions | Each with owner, date and how we will know it worked |
Structure of a post-release review.
| Finding at Contoso | Contributing factor | Action |
|---|---|---|
| Month-end jobs failed on day 1 of close | Job schedule tested only for daily jobs | Add "month-end and period-end jobs executed in QAS" to operations criteria |
| 18 users could not post goods receipts | Role mapping missed a plant-specific role for 1720 | Security criterion: key user role tests per plant |
| Rebate workaround slower than expected | Workaround documented but never rehearsed | Accepted risks require a rehearsed workaround |
Measuring release quality over time
One review tells a story; a series of reviews shows a trend. Keep a few simple measures per release so you can see whether governance is improving outcomes, not just adding meetings. Use them to ask questions, not to rank teams.
| Measure | How Contoso counts it | What it tells you |
|---|---|---|
| Incidents caused by the release | Priority 1 and 2 incidents traced to release features in the first 14 days | Whether readiness criteria predicted reality |
| Urgent fixes after release | Urgent features created within 14 days that fix release content | Hidden test gaps |
| Conditions met on time | Share of go conditions closed by their date | Whether conditions are realistic and owned |
| Accepted risks overdue | Accepted risks past their fix date | Workarounds turning into permanent processes |
Four measures that show whether release governance is working.
Share the review widely. A short summary to the whole program, with what happened, what was learned and what changes, tells people that raising problems leads to improvements rather than trouble. Archive the full review with the release's decision record, so the next release manager can read both side by side: what the board believed, and what actually happened.
What would you do?
In the Release 1 review, a manager asks which tester missed the goods receipt role problem so it "doesn't happen again". How should Luis respond?
- Hold a review after every major release and after any serious incident, fallback or data correction.
- Keep it blameless: contributing factors, not individuals.
- Compare readiness criteria with what actually happened, and update the criteria.
- Track actions with owners and dates and report them at the next release board.
Check your understanding · not graded
Lesson check
1. Post-release reviews should focus on:
2. Why keep reviews blameless?
3. What is the most valuable output of a review for the next release?
4. Which event should trigger a post-release review?