The Project Post-Mortem That Generates Learning
As of 2026-08-16
Most SAP analytics post-mortems produce a slide deck nobody reopens, because they are timed weeks late, run by someone with a stake in the outcome, and structured as chronology instead of causation. This module gives consultants the operating pattern for a post-mortem that survives the session: hold it three to four weeks after go-live while the hypercare log is still the evidence base, keep facilitation blameless so junior staff talk, and drive every finding through five-why to a named root cause. The number that matters is the follow-through rate — a corrective action with no named owner and no three-month follow-up review does not happen. Consultants who can show a post-mortem's findings traced into a checklist and template that survived to the next project carry a differentiating credential for delivery-excellence roles, priced at €1,200–1,600 per day for independents in EMEA.
What you will learn
- Time and structure a blameless post-mortem for an SAP analytics project using hypercare data as the empirical baseline, and facilitate the five-why analysis across the canonical failure categories (integration interfaces, authorisations, data quality, requirements)
- Produce the three mandatory post-mortem artefacts—structured report anchored to root causes, specific checklist updates, and a three-month follow-up accountability review—rather than a generic lessons-learned list
- Apply blameless facilitation techniques to maintain psychological safety in mixed-seniority groups, including immediate restatement of blame language and explicit protection of junior participants
- Design a practice-level learning propagation mechanism (quarterly digest, onboarding integration, template updates) that carries post-mortem learning beyond the immediate project team to future engagements
Why Most Post-Mortems Produce Nothing Useful
At the end of an SAP analytics project—a BW/4HANA migration, a Datasphere rollout, an SAC Planning implementation—the team gathers for the retrospective. Someone opens a slide deck titled "Lessons Learned". An hour later, the team has agreed that "communication could have been better", "requirements were not clear enough", and "testing started too late". These observations are technically true of almost every project ever run. They produce no actionable learning. The deck is filed in a SharePoint folder where it is never opened again. The next project makes the same mistakes.
This pattern is not caused by team laziness or bad faith. It is caused by structural failures in how post-mortems are typically run: they are held too late, facilitated by someone with a stake in the outcome, structured around chronology rather than causation, and they do not distinguish between symptoms and root causes. The result is cathartic conversation that feels like learning but produces nothing that changes the next project.
A post-mortem that actually generates reusable learning requires deliberate design—in its timing, its facilitation structure, its analytical framework, and especially in its follow-through mechanism.
Timing: Hold It Before the Team Disperses
Prerequisites
- Intermediate hands-on experience on SAP analytics projects
- Review core concepts first: C058, C055, C047
Outcomes
- Understand the core concepts behind the project post-mortem that generates learning
- Apply Post-Mortem in a typical SAP analytics engagement
- Explain the core architecture and decision points for The Project Post-Mortem That Generates Learning
- Apply a repeatable implementation pattern in a 15-minute lab format
Full module available to members. The full module adds: the decision framework · the end-to-end scenario walkthrough · the KPI scorecard · the anti-patterns · the knowledge check · the diagrams.