- Work Bestie
- Posts
- Project ended in disaster? You need a post-mortem.
Project ended in disaster? You need a post-mortem.
The meeting you should really be having.

If you’ve been on enough projects, you’ll have been on one that didn’t go to plan. It’s usually just the standard: we underestimated the timelines a bit, or stakeholders were harder to manage, or we had a new requirement halfway through build. But when you have something more severe, it’s time to do a post-mortem.
🪦 What is a post-mortem?
A post-mortem is a meeting held at the end of a project to uncover what went wrong, why it went wrong, and how we can prevent it in the future. It usually involves everyone involved in the project and relevant managers.
(Some teams host post-mortems after any large project, but I like to reserve them for real disasters: that way everyone knows it’s serious.)
✨ The most important rules
Before you dive into running the meeting, there are a few key points to remember:
✋ There needs to be a designated facilitator.
More than most meetings, the post-mortem needs someone to be in charge of running the meeting. This person will guide the room, prompt people to participate, and manage the mood of the room. Ideally, this person isn’t heavily involved in the project and so doesn’t also need to contribute.
✏️ There needs to be a designated notetaker.
Someone must have the job of recording notes. If you’re doing this virtually, you might use an AI assistant, but I prefer to do this meeting in person as it can be quite intense. The notes don’t need to be detailed minutes, but someone must capture the key actions and be in charge of cataloguing anything on the whiteboard. Ideally, the notetaker is not also the facilitator.
💖 The meeting needs to be as blameless as possible.
Post-mortems can be really serious, especially since you’re all gathering for a bad reason. It’s important that everyone is honest, and the best way to ensure this is to remove blame. If you’re facilitating, try to encourage the focus on systematic failures rather than individual ones where possible.
(eg. if someone was supposed to send an email when something happened, you can still acknowledge that they failed to action it – but the real failure is that the team was relying on a human element when they could have built in an automated reminder.)
📝 The structure of a post-mortem
The structure of a post-mortem can be flexible, but this is the way I like to run them. Typically you’d set aside ~2 hours for this meeting – it’s always better to end it early than have to organise a part 2.
👋 Open the meeting.
Before you dive in, introduce everyone (if they haven’t all met already) and explain who will be taking on the facilitator and note-taker roles. Emphasise that the meeting is not to point fingers and assign blame, but rather to collectively learn and prevent these failures in future projects.
🗓️ Start with the timeline.
For particularly complex projects, this can take a while. I always like to start with a timeline of key events (on the board or Figjam) – things like kick-off date, deployment date, key stakeholder meetings, etc. The idea is to understand all the moving parts of the project and what followed what.
Once you have your timeline, you can start to identify where things went wrong. You might want to go chronologically, or if you know the major mistakes, you can jump around.
😬 Discuss any preventable failures.
When you get to any failures that could have been prevented, discuss as a group what caused them and what can be done. You might not solve them all in the meeting, but you should definitely be agreeing on what can be fixed.
Not everything can be fixed – I’ve been in post-mortems where the conclusion was that sometimes shit happens and we reacted effectively to a bad situation.
✅ Confirm any actions.
Before you wrap up, make sure the notetaker runs through any actions from the meeting – such as problems to be solved by subgroups, or processes/fixes to be implemented immediately. They should also send around this list as soon as possible so that everyone has a record of it.
You often don’t need a follow-up meeting with the whole group, so the post-mortem ends here. However, you might need to report back to any managers who were present what actions have been taken so that they feel confident that it was a good use of time!

Post-mortems can be a really scary meeting – they’re about catastrophes and most times, at least of the attendees has never been to one of these before. That’s why the facilitator of this meeting is so crucial: without careful, empathetic facilitation, a post-mortem can devolve into political blame games. But with the right amount of care, they can be some of the most valuable meetings you have as a project group.
What did you think of this week's post? |