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.
If none of those apply, a shorter conversation may be enough.
The point is not the ritual.
The point is leaving the meeting with named risks, named strengths, and owned action items.
Pre-mortem vs kickoff meeting
People often ask whether a pre-mortem replaces a kickoff.
It does not.
The two meetings answer different questions.
A kickoff aligns the team on what you are building, who does what, and when.
A pre-mortem stress-tests that plan by asking what could break it and what could carry it.
In practice they work well together.
Run the kickoff first so everyone shares the same picture of the plan.
Then run the pre-mortem against that plan while there is still time to change it.
If you can only pick one for a small, low-risk project, the kickoff usually comes first, because a pre-mortem needs a concrete plan to react to.
If you are weighing whether a kickoff is needed at all, it helps to see the decision laid out separately.
Our guide on whether you need a project kickoff meeting walks through that choice before you start.
How to run a pre-mortem, step by step
Atlassian's published instructions break the hour into short, timed segments.
Here is the flow, with the timing they document.
1. Prep the board (about five minutes)
Set up a shared space before the meeting.
For remote teams, that is a collaboration document such as a Trello board or Confluence page.
For in-person teams, a whiteboard or large sheet of paper with sticky notes and markers works.
Add columns with questions like:
- What could cause us to miss our deadline?
- What will keep our project on time?
- What does this project need that we don't have?
- What do we already have that this project needs?
- What lessons have you learned from past projects?
- What are you worried about? What are you excited about?
You can customize the questions.
Atlassian suggests creative prompts such as asking what keeps a specific role up at night, and adding quantitative data like cost or time estimates to risks where you have it.
2. Set the stage (about five minutes)
Open the meeting by asking the team to consider what could go wrong with this project, and what could go right.
Keep the discussion focused only on this project.
That scope keeps the conversation concrete instead of drifting into general complaints.
3. Brainstorm silently (about ten minutes)
Give everyone ten minutes to write answers on the shared document or on sticky notes under each question.
Silent writing matters.
It stops the loudest voice from setting the agenda and lets quieter team members surface risks others have not thought of.
4. Group similar ideas (about five minutes)
Work together to merge similar ideas into lists.
Ten sticky notes that all describe the same missing dependency are really one risk, and grouping makes that visible.
5. Vote on threats (about five minutes)
Ask attendees to vote on the items that pose the biggest threat to the project.
Atlassian gives each person three votes, which they can spread across cards or stack on one.
In-person teams can use dots on sticky notes.
6. Vote on strengths (about five minutes)
Repeat the vote for the items going well for the project, the keys to success.
This is the half of the exercise teams skip, and it is a mistake to skip.
Knowing what is carrying the project tells you what to protect when tradeoffs appear later.
7. Discuss the top items (about twenty-five minutes)
Move the three topics with the most votes into a discussion column.
Starting at the top, set a ten-minute timer per card and come up with at least one action item to mitigate each risk.
Atlassian suggests asking what the opposite of the risk looks like, imagining success, and planning toward it.
Assign an owner and a due date to every action item, because owned actions are far more likely to get done.
8. Recap and commit (about five minutes)
Close by recapping the action items the team is committing to, each with an owner and a deadline.
Then handle follow-up: save the discussion and actions somewhere the team and stakeholders can find them.
Add the actions to your project board to track progress, and revisit the document periodically so risks stay visible as the project moves.
A worked example of one discussion card
To make the outcome concrete, here is an illustrative scenario of what one discussed risk can produce.
Suppose a small team is planning a website rebuild on a fixed schedule.
During the vote, the card 'the client's content arrives late' wins the most threat votes.
In the ten-minute discussion, the team asks what the opposite looks like: content arriving early enough to design around.
The action item is asking the client for a content draft early in the schedule.
The project lead owns it, with a check-in at the end of that first stretch.
That is a small, cheap change to the plan, made before the schedule was fixed.
It is an illustrative example, not a reported customer result, but it shows the shape of a good outcome: one named risk, one owned action, one date.
Common mistakes to avoid
- Skipping the strengths vote. Risks alone leave you defensive; strengths tell you what to protect.
- Generating risks without action items. A list of worries changes nothing. Every discussed card needs at least one owned action.
- Letting one person dominate. Silent brainstorming and voting exist precisely to prevent this.
- Running it too late. A pre-mortem works while the plan can still change. After commitments are locked, it tends to become a complaint session rather than a planning tool.
- Never revisiting the document. Risks evolve. Atlassian recommends periodic revisits so the team stays aware of them.
Variations for small and distributed teams
You do not need a big team or a synchronous hour.
Atlassian documents two variations worth knowing.
For teams spread across time zones, send the collaboration document with a deadline and let people answer asynchronously, tag topics for discussion, and sign up for tasks.
For Scrum teams, a condensed version can run during sprint planning, so anything that might impede the sprint is discussed before commitments are made.
Solo founders and freelancers can adapt the same logic.
Answer the board questions yourself, then ask one outside person, a peer or mentor, to add their answers before you decide what to act on.
The value comes from the outside view, not the headcount.
Where pre-mortems fit with other early planning
A pre-mortem is one of several cheap checks worth doing before work begins.
It pairs naturally with mapping the dependencies your project relies on, since hidden dependencies are among the most common risks a pre-mortem surfaces.
Our guide on mapping dependencies before starting a project covers that in detail.
It also pairs with clarifying who owns what.
Many voted risks turn out to be ownership gaps in disguise, where everyone assumed someone else was handling a task.
The guide on mapping roles and responsibilities before a project helps close that gap.
And because one of the board's standard questions asks what lessons you have learned from past projects, it is worth reviewing those lessons before the meeting.
Our article on analyzing past projects before starting a new one shows how to mine them.
The decision, in short
Run a pre-mortem when the project has real stakes, shared dependencies, or a history of similar failures, and when the plan can still change.
Skip it, or shrink it to a short conversation, when the work is small, solo, and easily undone.
If you do run one, follow the documented flow: prep the question board, brainstorm silently, and vote on threats and strengths.
Discuss the top three with timers, and leave with owned, dated action items.
In our view, an hour of honest imagination before the work starts is a low-cost way to catch problems while they are still cheap to fix.
In our view, a pre-mortem does not prevent every failure. It prevents the failures someone already saw coming and nobody said out loud.
Source references: www.atlassian.com.
Take the next step with Ideoreto. Use the ideas in this guide as a starting point for your next project.
Register for Ideoreto to get started.