Pre-Mortem vs Post-Mortem: When to Run Which
The short version
A pre-mortem is a forecast. A post-mortem is an autopsy. Both ask the same question, which is why did this program fail, and the only difference is whether you are allowed to do anything about the answer.
Most teams run only the autopsy. They ship the thing, it lands three months late, everyone gathers in a room to agree that the dependency on the platform team was the problem, and the notes go into a folder nobody opens. The next program starts the following Monday with the same dependency and no plan for it.
Run both. The pre-mortem is where you buy the information cheaply. The post-mortem is where you find out what the information cost you.
What a pre-mortem is for
A pre-mortem runs before kickoff, ideally in the same week the charter gets signed. The framing is a time machine. It is twelve months from now, the program has failed, and the room already knows it failed. Nobody is asked to predict a risk. Everybody is asked to explain a fact.
That reframe is the entire mechanic, and it is not a party trick. Ask a team to list risks and you get a list of things nobody minds saying out loud: scope might grow, the timeline is tight, resourcing is a concern. Ask a team to explain a failure that has already happened and you get the real answer. The vendor SOW sat unsigned for six weeks because Finance and Platform disagreed about who owned the budget line, and nobody wanted to be the one to escalate it. Not "a stakeholder alignment issue." Two named directors, one unsigned document, six weeks.
Standard risk tooling never surfaces that second answer. A risk register captures the risks a program manager can name and score. The pre-mortem captures the ones the team can name and will not, which are almost always about people, org boundaries, and politics. Those are the ones that kill programs.
Who is in the room
The people who will do the work, plus the one person most likely to tell you the thing you do not want to hear. Sixty to ninety minutes. Silent written round first, so the senior voice in the room does not set the anchor for everyone else. Then read them out.
Do not invite the sponsor to the first one. The point is to collect the failure modes people will not say in front of the person funding the program. You brief the sponsor on the output, not the raw session.
What a post-mortem is for
A post-mortem runs after delivery, or after the failure, and its only job is to change what happens next time. Not to record what happened. The record is the easy part, and it is the part most teams mistake for the work.
A post-mortem that ends with a timeline of events is a document. A post-mortem that ends with two or three specific process changes, each with an owner and a date, is a control. The test is simple: if the next program runs identically to the last one, the post-mortem did nothing, no matter how good the notes were.
Who is in the room
The team that did the work, plus whoever inherits the process. That second group is the one most teams forget to invite, and it is the reason so many retrospectives evaporate. The lessons live in the heads of the people leaving the program and never reach the people starting the next one.
The honest comparison table
| Pre-mortem | Post-mortem | |
|---|---|---|
| When | Before kickoff, with the charter | After delivery, or after the failure |
| Question | Why did this fail? (hypothetical) | Why did this fail? (actual) |
| Output | Risks with owners, before they cost anything | Process changes with owners and dates |
| Catches | Org, political, and people risks a register misses | The failure modes you did not predict |
| Costs you | Ninety minutes | The program |
| Sponsor in the room? | No, brief them on the output | Yes, they need to own the changes |
| Fails when | It becomes a risk register with worse formatting | It ends in sympathy instead of decisions |
Both templates, both meetings, both built to end in a decision
The Pre-Mortem Tool ($39) runs the ninety-minute session and lands the output in your risk register. The Post-Mortem / Retrospective Tool ($39) forces the "what are we changing?" section most templates leave out. The Pre/Post-Mortem Pair is both for $49.
Get the Pair, $49How they feed each other
These are not two isolated meetings. They are the two ends of one loop, and the loop only closes if you run both on the same program.
The pre-mortem feeds the risk register. Every failure mode the room names becomes a line with an owner and a review date. If the output of your pre-mortem is a list of interesting observations rather than owned rows in a tracker, you ran a workshop, not a control.
The post-mortem feeds the next pre-mortem. This is the step almost nobody does, and it is the one that compounds. The failure modes that actually happened on the last program are the highest-quality input available for the next program's pre-mortem. Open the last post-mortem before you run the next pre-mortem and read the top three findings into the room. You will watch the team recognize two of them immediately.
Run the loop three times and the pre-mortem stops being a guessing game. It becomes institutional memory with a date on it.
When you can get away with just one
Run only the post-mortem when the program is small, short, and reversible. A four-week internal tool with one team and no cross-org dependencies does not need a ninety-minute session about how it might fail. Ship it, and if it goes sideways, learn cheaply.
Run only the pre-mortem when the program is a one-off you will never repeat. A migration you will perform exactly once, a regulatory deadline that will not recur, an office move. There is no next program for the lessons to travel to, so the forecast is worth more than the autopsy.
Everything else, meaning anything long, cross-team, or repeating, needs both. If the program has a dependency on a team that does not report to your sponsor, you need both.
The most common failure mode
For the pre-mortem, it is that the session turns into a risk register with worse formatting. The room lists "timeline may slip" and "resourcing is tight," everyone nods, and the meeting ends having generated nothing a competent PM could not have written alone in ten minutes. The fix is the framing. Insist on past tense. "The timeline slipped" is a risk. "The timeline slipped because we assumed the platform team's Q3 roadmap included our integration and nobody confirmed it" is a finding you can act on this week.
For the post-mortem, it is that the meeting ends in sympathy. The team agrees it was hard, agrees everyone did their best, agrees the dependency was unreasonable, and adjourns. Nothing changes. The fix is structural: the meeting does not end until two or three changes have an owner and a date. Not five, not ten, because a list of ten process changes is a list of zero process changes.
Practical setup for a new program
Week one, with the charter. Run the pre-mortem. Ninety minutes, silent written round, no sponsor. Every finding lands in the risk register with an owner and a review date before the room clears.
Week two. Brief the sponsor on the top three. This is the conversation where you find out which risks they will actually spend political capital on, which is information worth having in week two rather than month six.
Delivery, or failure. Run the post-mortem within two weeks, while people still remember and before the team scatters. End with two or three owned changes.
Next program, week one. Open the last post-mortem. Read the findings into the new pre-mortem. Close the loop.
The bottom line
The pre-mortem costs ninety minutes and buys you the risks your team will not say out loud. The post-mortem costs the program and buys you the risks nobody saw coming. Teams that run only the post-mortem pay full price for information they could have had for ninety minutes.
The pre-mortem is the cheap version. The post-mortem is the expensive version. The loop between them is the only version that compounds.
Run both, and make the second one feed the first.
The findings still have to reach your sponsor
The free status report cheat sheet is the one-page format for putting a risk in front of leadership without burying it on page four. One page, no cost.