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.
Building a post-mortem worksheet in Excel
Most post-mortem files are one long sheet of prose sitting in cells. It reads like minutes, it gets exported into a deck, and the deck is the last time anyone opens it. The fix is structural, and the structure is three tables in a deliberate order. Here is how the post-mortem template Excel worksheet is built, and why the order is not the obvious one.
The decisions table goes first, on sheet one, above everything else. The obvious order is timeline, then discussion, then actions, because that is the order the meeting runs in. It is the wrong order for the file. Whoever opens this in four months is looking for exactly one thing: what changed. Timeline goes on sheet two. The narrative goes wherever narrative goes. Sheet one, row 4, is the first decision.
The decisions table. Five columns: the finding, the change, the owner, the due date, and a status dropdown (Data › Data Validation › Allow: List, Source: Open,Done,Dropped). Then a sixth column, F, holding the only formula on the sheet that matters:
=IF($B4="","",IF(OR($C4="",$D4=""),"No owner or no date",""))
Read what that is testing. It does not check whether the change is a good one, because a spreadsheet cannot do that. It checks whether the change is a decision at all. "Improve handoffs between QA and release" with no name and no date is a sentence. The same words with a name and a Friday are a commitment. The formula cannot tell a good change from a bad one, but it can tell a change from a wish, and in a retro that is the distinction that goes missing.
Back it with formatting. Select A4:F30, Home › Conditional Formatting › New Rule › Use a formula, amber fill:
=AND($B4<>"",OR($C4="",$D4=""))
Then put the count somewhere the facilitator can see it without scrolling:
=COUNTIF($F$4:$F$30,"No owner or no date")
That cell reads zero before the meeting ends. Cap the table while you are at it. Thirty rows is generous. I have never seen a retro produce more than about seven changes that anyone actually made. A post-mortem that generates nineteen actions has generated zero.
The timeline, on sheet two. Four columns: timestamp, what happened, who observed it, and the source (a ticket number, a chat message, a dashboard panel). The source column is what keeps the timeline factual, because a row with no source is somebody's memory of the incident, and memory is the thing the timeline exists to replace.
Format column A as Date-Time before anyone types into it. A timestamp entered as text sorts alphabetically, which files 10:04 ahead of 9:15 and produces a timeline that is quietly, confidently wrong. Ctrl and semicolon enters a static date, Ctrl and Shift and semicolon enters a static time, and neither one moves afterward.
Sorting is the part people get wrong. Because the range is a Table, use the header dropdown on the timestamp column and sort oldest to newest, which carries whole rows and keeps every event attached to its source. Selecting only column A and hitting sort is how you end up with a timeline where the times are in order and the events are not. Once it is sorted, add an elapsed column so the gaps are visible:
=IF($A5="","",ROUND(($A5-$A$4)*24,1))
Hours since the first event, one decimal. The number that decides most post-mortems is not when something broke. It is how long it sat between the first person noticing and the first person deciding. That gap should be a column, not an opinion.
The what-worked and what-did-not split. One table, not two lists, with a dropdown column holding Worked,Did not work and a count above it:
=COUNTIF($C$4:$C$40,"Did not work")
One table instead of two, for a specific reason. Two side-by-side lists invite the team to fill both to the same length, and the "what worked" list quietly becomes a politeness column. One table with a dropdown lets the split land wherever it honestly lands, including badly. The other half of the discipline is that a Worked row is not free: if something worked and nobody can say what made it repeatable, it was luck, and luck does not carry to the next program. Every Worked row the team wants to keep earns its own change row back on sheet one, naming the thing that made it work.
Excel and Google Sheets. The .xlsx opens in both, and IF, OR, AND, COUNTIF, INDEX, MATCH, IFERROR, and ROUND behave identically. Ctrl and semicolon and Ctrl and Shift and semicolon insert a static date and time in Sheets too, so the habit survives the move. Two differences worth knowing. On import the Excel Table becomes a plain range, so use Data › Sort range › Advanced range options and tick "Data has header row" before sorting the timeline, because the default will happily file your header row somewhere in the middle of the incident. And Sheets has no "Stop If True," so if you layer a second formatting rule onto the decisions table, remember that the higher rule wins on any property both rules set.
Matching the post-mortem back to the pre-mortem
Run a pre-mortem and a post-mortem on the same program and you have held two meetings. Connect them and you have a way to find out whether your team's judgment is any good, which is a different thing and a much more useful one.
The mechanics are small. Paste the pre-mortem rows into a sheet inside the post-mortem file. Name that sheet Premortem, one word, no hyphen, so formulas never need quotes around the sheet name. Keep the original IDs in column A, the imagined failure text in B, and the score in F. Then add one column to the findings table, headed "Predicted," where you type the pre-mortem ID whenever a finding is something you called in advance. The lookup fills in the rest:
=IFERROR(INDEX(Premortem!$B$4:$B$60,MATCH($G4,Premortem!$A$4:$A$60,0)),"Not predicted")
Column G holds the ID you typed. Anything left blank, or any ID that does not match, comes back "Not predicted." That is the answer you want it to give, because the surprises are the interesting half.
Now run it the other direction, on the Premortem sheet, so every predicted failure gets a verdict:
=IF(COUNTIF(Postmortem!$G$4:$G$60,$A4)>0,"Happened","Did not happen")
Put that in column K and the pre-mortem sheet has just become a scorecard for your own foresight. Three counts fall out of it.
- What you predicted and got right. The count of "Happened." Useful, and the number everyone expects to care about.
- What you predicted and prevented. The "Did not happen" rows that had an owner and a mitigation that landed. This is the number that justifies the sixty minutes, and it is the only evidence you will ever have for it, because a prevented failure leaves no trace anywhere else in the program.
- What nobody saw coming.
=COUNTIF($H$4:$H$60,"Not predicted") against the findings table, where H holds the lookup result. If that number is most of your findings, the pre-mortem framing was too polite. It does not mean the team was dim.
The sharpest use is a fourth number, and it takes one more formula. On the Premortem sheet, compare the average score of the failures that happened against the average score of the ones that did not:
=AVERAGEIF($K$4:$K$40,"Happened",$F$4:$F$40)
Copy it into a second cell and swap "Happened" for "Did not happen." If the first number comes out meaningfully higher, your team's likelihood-times-severity scoring has real predictive value, and you should be spending mitigation money strictly by rank. If the two come out close, the scoring is noise wearing the costume of arithmetic, and the honest response is to stop ranking and start asking a different question in the session. I have seen it land both ways. Knowing which one you are looking at is worth more than either answer.
Two meetings and one lookup. That is the whole difference between a program that learns and a program that holds retrospectives.
Questions PMs ask
How long does a post-mortem session take?
90 minutes for a single-program retro. 2-3 hours if you're running it across multiple workstreams or with a large team. The template's facilitation guide covers both formats.
How is this different from an agile retro?
Agile retros are sprint-cycle, team-level, recurring. This template is for program-level post-mortems at major milestones or program closure: bigger scope, executive participation, decisions that change the operating model. The two are complements, not competitors.
Can the team run this without a facilitator?
It works better with a neutral facilitator. The cheat sheet is structured so any senior PM can run the session, but if you're the program lead and your own program is the subject, find someone neutral. Self-facilitated retros tend to over-credit successes and under-examine failures.
