Why most post-mortems produce nothing
Most retros run hot for an hour, generate a long list of "learnings", get summarized into a deck nobody reopens, and the next program repeats the same mistakes. The pattern isn't because PMs are lazy. It's because the format invites narrative instead of decision.
A post-mortem is only useful if it changes the next program. That means the output isn't "what we learned", it's "what we'll do differently, who owns it, when it lands." Anything less is a writing exercise.
"A retro that doesn't change the operating model is theater. The artifact is the change, not the document."
This template structures the retro to produce ownership and changes, not narrative. The facilitation guide covers how to run the session so the team is honest without descending into blame.
Blameless ≠ consequence-free
The phrase "blameless post-mortem" gets misused. People hear it as "we don't talk about who did what." That's not the discipline. The discipline is:
- Focus on the system, not the person. When a person made a mistake, the question is what about the process, tooling, or context made that mistake easy to make.
- Decisions get owners. "We should improve handoffs" is not a decision. "The release manager owns rewriting the handoff template by Friday, with sign-off from the engineering lead" is a decision.
- Repeated patterns get escalated. If the same kind of failure shows up across three programs, that's a leadership-level issue, not a per-program one.
Pair the post-mortem with the pre-mortem template on your next program, comparing what you predicted vs. what actually happened is one of the highest-leverage learning loops in program management.
A worked example: findings that became changes
The difference between a retro that produces "learnings" and one that changes the next program is visible in the output format. Three rows from a real closeout:
| Finding |
Root cause |
The change |
Owner |
Due |
| UAT found 40% of all defects in the final two weeks | Test environment wasn't production-like until week 10 | Environment parity becomes a phase-gate criterion before UAT entry | R. Vance, QA lead | Next kickoff |
| Two workstreams built the same reconciliation logic | No cross-workstream design review existed | Design review added at the 30% build mark, both leads required | D. Silva, Eng lead | Oct 1 |
| The vendor escalation took nine days to reach a decision | No escalation path was named in the SOW | Escalation path, with names and response times, required in every SOW | M. Grant, PMO | Immediate |
Notice what's absent: no "improve communication," no "align earlier." Every row converts a finding into a specific change with a named owner and a date. That conversion is what the worksheet's action template forces.
