Most teams hold a post-mortem when a project goes wrong. Far fewer hold the meeting that might have saved it: a pre-mortem, before any work starts. The two are mirror images. A pre-mortem imagines the project has already failed and asks why. A post-mortem looks at a project that has ended and asks what actually happened.
This guide covers both: what each one is, how to run it, and the twenty questions we use in both. Asking the same questions at the start and at the end is the point. When the project is over, you can see which problems you saw coming, which ones you saw coming and hit anyway, and which ones nobody imagined.
Pre-Mortem vs. Post-Mortem at a Glance
| Pre‑mortem | Post‑mortem | |
|---|---|---|
| When | After the plan is written, before work starts | After delivery, or after a big milestone or incident |
| Starting point | “It’s a month after the deadline, and the project has failed.” | The project as it actually went |
| The question | Why did it fail? | What happened, and why? |
| Who takes part | The people who will do the work, and whoever owns the plan | The team, plus the stakeholders who lived with the result |
| What you get | A ranked list of risks, and changes to the plan | Lessons, and action items for the next project |
| How long | About an hour | One to two hours, plus time to gather the facts |
What Is a Pre-Mortem?
A pre-mortem is a planning meeting in which the team assumes the project has already failed and works out why. The psychologist Gary Klein described it in “Performing a Project Premortem”, in the September 2007 issue of Harvard Business Review.
The trick is in the framing. Asking “what could go wrong?” gets a few polite caveats, because nobody wants to sound negative about a plan the team has just agreed on. Saying “it failed, tell me why” makes finding problems the job, and the people who had doubts finally have a reason to voice them. Klein cites a 1989 study by Deborah Mitchell, Jay Russo and Nancy Pennington, which found that imagining an event has already happened, which they called prospective hindsight, increases the ability to correctly identify reasons for future outcomes by 30%.
How to run a pre-mortem
- Pick the moment. Hold it once the plan is written but before work starts: late enough that there's something concrete to pick apart, early enough to change it.
- Invite the people who will do the work. They know where the plan is thin. If a client or another department could sink the project, bring someone who knows them well.
- Set the scene. Name a date after the deadline and describe the failure plainly: “It's March. The new website launched six weeks late and over budget, and the client is talking to other agencies.”
- Write alone first. Give everyone five minutes to list every reason they can think of, in silence. Writing before talking keeps the first or most senior voice from setting the agenda.
- Go round the room. Each person reads out one reason at a time until every reason is on the shared list. Don't debate them yet; just capture them.
- Rank and choose. As a group, mark the reasons that are both likely and damaging. Most teams end up with three to five worth acting on.
- Change the plan. Each risk you chose becomes a change with an owner and a date: an earlier deadline for copy, a second approver, a check-in with the client. Keep the list where you'll see it again at every milestone.
What Is a Post-Mortem?
A post-mortem is a review held after a project ends, to understand what happened and what to change next time. Depending on the team, it's also called a retrospective, a lessons-learned session or an after-action review. It isn't only for failures: a project that went well has lessons too, and they're easier to talk about.
What makes a post-mortem work is that it's blameless. Google's Site Reliability Engineering book, which treats post-mortems as a core practice, says that to be truly blameless a post-mortem “must focus on identifying the contributing causes of the incident without indicting any individual or team.” It also notes that blameless culture “originated in the healthcare and avionics industries where mistakes can be fatal.” If people expect to be blamed, they defend their decisions instead of explaining them, and the meeting learns nothing.
How to run a post-mortem
- Hold it soon. Within a week or two of delivery, while people still remember why they made the calls they made.
- Gather the facts first. Before the meeting, put the timeline together: planned dates against actual ones, budget against spend, and the decisions that changed course. If the project ran in Redbooth, its task lists, due dates and comment threads already hold most of that record.
- Open with the ground rule. Say out loud that the goal is to fix the process, not to find out who's at fault.
- Start with the pre-mortem list. Go through it first: which risks you avoided, which happened anyway, and what nobody predicted. That comparison is the most honest measure there is of how well the team plans.
- Work through the four categories below, covering what went well as well as what didn't.
- End with action items, not observations. Each one gets an owner and a place where the next project will find it, such as that project's plan or its pre-mortem.
The 20 Questions to Ask in Both Meetings
We group the questions into four categories: planning, execution, results and communication. They're the same questions in both meetings; only the tense changes. In the pre-mortem you ask why you will miss your primary goal, and in the post-mortem, why you did.
Planning
- Project plan: What's missing from the plan? Which parts are vague?
- Resources: Have we measured and allocated people, budget and tools accurately?
- Timing: Are deadlines realistic and tied to specific goals? Is there room for unexpected delays?
- Tasks: Are all the necessary tasks planned, with dependencies and deliverables clearly stated?
- Documentation: Is the way we document decisions and work good enough?
Execution
- Delays: How can we handle unexpected delays better?
- Workflow: Where are the weak points in how work moves from one person to the next?
- People: How can we make roles and responsibilities clear and consistent?
- Tasks: What makes tasks hard to get done day to day?
- Management: Where does management get in the way of the work?
Results
- Primary goal: Why will (did) we miss our main goal?
- Secondary goals: Why will (did) we miss the others?
- Quality: How will (did) our work fall short of the quality we promised?
- External performance: Why is the client or customer unhappy? What's wrong with how we measure success with them?
- Internal performance: What's wrong with the way we measure success internally?
Communication
- Channels: What are the drawbacks of the main ways we communicate?
- Team: How will (did) team members struggle to communicate?
- Managers: How will (did) managers struggle to communicate?
- Meetings: What's wrong with the way we hold meetings?
- Stakeholders: Where will (did) our communication with stakeholders break down?
Answer with facts, not verdicts. “The plan was bad” doesn't help anyone. “The plan left no time for the client's legal review, which took nine days” does.
Example: A Website Relaunch, Before and After
Here's how the two meetings fit together, using a made-up project: a marketing team relaunching its company website, with eight weeks to launch.
The pre-mortem. At kickoff, the team imagines it's launch day and the new site isn't live. Among the reasons they list:
- The product pages were waiting on copy from three departments, and it arrived late.
- Legal reviewed the new privacy page in the last week and asked for changes.
- Nobody owned the redirects from the old URLs, and search traffic dropped after launch.
- The CEO saw the design for the first time in week 7.
Each one goes into the plan as a task with an owner: copy due two weeks before the build freeze, the legal review booked for week 4, a redirect map for the developer, and a fifteen-minute design review with the CEO in week 2.
The post-mortem. The site launches a week late. Going through the pre-mortem list first, the team finds:
- Avoided: the redirects were in place on launch day, the legal review fitted into week 4, and the CEO's feedback came early enough to use.
- Predicted, but it happened anyway: copy still arrived late from one department, because its owner was on leave and nobody else had been named.
- Not predicted: the licences for the new homepage photos weren't approved until launch week.
The action items follow from that: every deliverable gets a backup owner, and “assets and licences” becomes a standing item in the next pre-mortem.
Run Both in Redbooth With the Free Template
Our Project Post-mortem Analysis template puts the twenty questions into a Redbooth workspace: one task list per category, and one task per question.
Here's one way to use it over the life of a project:
- At kickoff, open the template, click Create Workspace and run the pre-mortem in the new workspace. You'll need to be signed in to Redbooth; if you don't have an account yet, create one first. Record each reason as a subtask of the question it answers, and add the risks you decide to act on to the project's own workspace as tasks with an owner and a due date.
- During the project, keep the workspace. A quick look at each milestone shows whether the risks you ranked highest are under control.
- At the end, reopen it for the post-mortem. Next to each pre-mortem answer, add what actually happened, then add the action items for the next project.
Because the workspace stays, the next project's pre-mortem can start from the last one's lessons instead of a blank page.
Mistakes That Make Both Meetings Useless
- Holding the pre-mortem after the plan is locked. If nothing can change, people stop raising problems.
- Letting the most senior person speak first. Everyone else adjusts their list to match. Write alone first.
- Looking for someone to blame. The next post-mortem will be shorter, politer and emptier.
- Action items with no owner. “We should communicate better” is not an action item.
- Never reading the last post-mortem. Lessons nobody reads at the next kickoff aren't lessons. Make the last post-mortem the first item on the next pre-mortem's agenda.
Questions People Ask
Is a pre-mortem the same as a risk assessment?
No, though it feeds one. A risk register lists and tracks known risks over the life of a project. A pre-mortem is a single meeting designed to surface the risks nobody has written down yet, especially the ones people are reluctant to raise. What it finds can then go into the register.
What's the difference between a post-mortem and a retrospective?
Mostly scope. Agile teams hold a retrospective at the end of every sprint, to adjust how they work as they go. A post-mortem looks back over a whole project, or a single incident, once it's over. The questions are similar.
How long should each meeting take?
About an hour is enough for most pre-mortems. A post-mortem usually needs one to two hours, plus the time it takes to put the timeline together beforehand.
Should you hold a post-mortem when a project succeeds?
Yes. A success has causes too, and knowing which ones you can repeat is as useful as knowing what to avoid. It's also the easiest way to make post-mortems a habit rather than a punishment.
Start with the next project on your list: book an hour before kickoff, and copy the template into a workspace to hold the answers.