What is a pre-mortem?
Many projects fail in ways someone on the team could have predicted.
The deadline slips because a dependency was never confirmed.
The launch stalls because nobody owned the review step.
A pre-mortem is a simple meeting designed to surface those predictable problems before they happen, and it takes about an hour to run.
So should you run one before starting a project?
Often yes, especially when the project has a fixed deadline, several people involved, or real consequences if it fails.
This guide explains what a pre-mortem is, when it earns its hour, and how to run one with your team.
A pre-mortem is a project management strategy where the team thinks about what could happen in a project, good or bad, and makes a plan before it starts.
The name flips the idea of a post-mortem, the review teams hold after a project ends.
Instead of asking what went wrong after the fact, you ask it in advance, while you can still do something about it.
Atlassian's Team Playbook describes the exercise as preparing for every twist and turn.
It means imagining what could cause the project to miss its deadline, and also what could keep it on time.
That two-sided framing matters.
A good pre-mortem is not a doom session.
It surfaces risks and strengths together, so you know what to protect as well as what to fix.
The format is deliberately lightweight.
Atlassian's version needs about ten minutes of prep, sixty minutes of meeting time, and between three and eleven people.
You can run it in person with a whiteboard and sticky notes, or remotely with a shared document and video call.
When a pre-mortem is worth the hour
Not every project needs a formal risk session.
Sketching a solo project on a napkin probably does not.
The exercise pays off when uncertainty and coordination costs are high.
Consider running one when:
- The project has a hard deadline tied to something outside your control, like an event, a launch window, or a client commitment.
- Several people or teams need to deliver pieces that depend on each other.
- You have failed at similar projects before and want to avoid repeating the pattern.
- The team is new to working together and you do not yet know each other's blind spots.
- Stakeholders outside the team hold assumptions nobody has said out loud.