Most post-mortems produce a document that gets filed away and never looked at again, full of generic lessons like “communicate earlier” and “plan more realistically” that are true of almost every program and useful for none of them. The organization runs the same failure pattern again eighteen months later on a different initiative, and nobody connects it back to the lessons that were supposedly captured the first time. A post-mortem that doesn’t change future behavior isn’t institutional learning—it’s a ritual that makes people feel like something was learned without actually building the muscle to avoid repeating it.
Key Takeaways
- Generic lessons (“communicate better”) aren’t actionable; push every finding to a specific, attributable root cause.
- Separate what went wrong from who’s to blame—psychological safety is what gets you honest input in the room.
- The output should be specific process or structural changes, not a list of good intentions for next time.
- Findings need to be actively fed into how future programs are scoped and governed, not just archived.
- Run post-mortems on partial successes too, not just outright failures—stalled and struggling programs hold just as many lessons.
Push Every Finding to a Specific Root Cause
“We should have communicated better” is the single most common post-mortem finding, and it’s almost always too vague to act on. Nearly every failed program will surface this observation, which means it doesn’t discriminate between what actually went wrong here versus generic truisms about organizational life. The value of a post-mortem comes from pushing past the generic observation to the specific mechanism that failed.
Use a simple “five whys” style approach: why did communication break down? Because the workstream lead didn’t know about the scope change. Why didn’t they know? Because there was no defined process for communicating scope decisions across workstreams. Why was there no process? Because it was never explicitly designed during program setup. Now you have something actionable—a specific structural gap (no cross-workstream decision communication process) rather than a vague behavioral wish (communicate better). The specific finding tells you exactly what to build differently next time; the generic one doesn’t.
Separate the Failure Analysis From Blame
A post-mortem that feels like it’s building a case against specific individuals will produce guarded, defensive input, and guarded input produces shallow findings. People self-censor the moment they sense the exercise is about assigning fault rather than understanding mechanism, and the most useful information—the honest account of what actually happened and why—gets filtered out before it ever reaches the room.
Set explicit ground rules at the start of the session: the goal is understanding what happened in the system and process, not assigning individual blame. Frame questions around decisions and structures rather than people—”what made this decision hard to make correctly” rather than “why did you make the wrong call.” This isn’t about avoiding accountability entirely; it’s about recognizing that most program failures trace back to structural and process gaps rather than individual negligence, and treating it that way gets you honest input that actually reveals those gaps.
Insist on Specific Process Changes, Not Good Intentions
A post-mortem output that reads as a list of things to be more careful about next time relies entirely on individual willpower and memory to prevent recurrence, which is a weak mechanism—the next program team may not even know this post-mortem happened, let alone remember its lessons in the middle of their own delivery pressure. The output needs to be concrete changes to process, templates, governance structure, or checklists that will apply regardless of who’s running the next program.
For each root cause identified, ask explicitly: what specific artifact, process step, or governance checkpoint would have caught this earlier or prevented it entirely? If the finding was a missed dependency, the answer might be “add a mandatory cross-workstream dependency mapping session at kickoff” rather than “be more careful about dependencies.” If the finding was scope creep, it might be “require every scope change request to go through the documented change control process” rather than “hold the line on scope better.” Concrete process changes survive staff turnover in a way that good intentions don’t.
Feed Findings Back Into How New Programs Get Set Up
A post-mortem report that lives in a folder nobody revisits has no mechanism for actually changing future behavior. The findings need an active distribution path into how the next program gets scoped and governed—ideally as a mandatory checklist item during program setup, not an optional reference document that a new program manager has to know to go looking for.
A practical mechanism: maintain a running, organization-level list of post-mortem findings and the process changes that resulted, and require every new program charter to explicitly confirm which relevant past lessons have been incorporated into the new program’s design. This turns institutional learning from a passive archive into an active input that shapes how new work gets structured, rather than trusting that people will remember and apply lessons from a report they may never have read.
Don’t Reserve Post-Mortems for Outright Failures
Organizations tend to only run formal post-mortems after a clear, visible failure—a canceled program, a major missed deadline, a public embarrassment. This misses most of the learning opportunity. Programs that stalled and recovered, that delivered late but eventually succeeded, or that delivered on time but with significant internal friction all hold valuable lessons that a “only review outright disasters” policy never captures.
Build a lighter-weight review into the closeout of every significant program or major phase, regardless of outcome—even successful programs benefit from asking what nearly went wrong and what made the difference. This normalizes the practice as routine reflection rather than a crisis response reserved for failures, which also removes some of the stigma and defensiveness that makes people reluctant to participate honestly when a review only happens after something has visibly gone wrong.
Frequently Asked Questions
Who should facilitate a post-mortem review?
Someone without a personal stake in defending the program’s original decisions—often a PMO representative or a program manager from a different initiative—tends to get more honest participation than the program’s own manager facilitating a review of their own work, even with the best intentions.
How soon after a program ends should the post-mortem happen?
Within a few weeks of closeout, while details are still fresh but with enough distance that people aren’t reacting purely emotionally to a difficult ending. Waiting months usually means key details and context have faded, and people have moved on to other priorities and disengage from the exercise.
Should post-mortem findings be shared broadly across the organization?
Yes, in a form focused on process and structural lessons rather than specifics that could embarrass individuals. Broad visibility is what allows other teams running similar initiatives to benefit from the findings, rather than the same mistake recurring in a different part of the organization that never saw the original review.
What’s a sign that post-mortems have become a genuine part of organizational learning rather than a checkbox exercise?
New program charters and governance plans explicitly reference specific past findings and show concrete design choices made because of them. If new programs keep repeating the same structural mistakes previous post-mortems identified, the review process is producing documents, not institutional learning.