Most project plans explain how the work is supposed to succeed. A pre-mortem examines the less comfortable possibility: the project has failed, the expected results never appeared, and the warning signs now look painfully obvious.
This is not an exercise in pessimism. A project pre-mortem gives people permission to raise concerns while the scope, schedule, staffing, and launch plan can still be changed. It may uncover an unrealistic deadline, an untested assumption, a fragile dependency, or an adoption problem that a conventional kickoff meeting overlooks.
The process is simple. The team imagines that the project has failed and works backward to explain why. The value, however, comes from what happens after those risks are identified.
What Is a Project Pre-Mortem?
A project pre-mortem is a structured risk-identification exercise conducted before work begins or before an important commitment is made. Participants imagine themselves in a future where the project has failed, then describe the events and decisions that caused that outcome.
Cognitive psychologist Gary Klein developed the method using the concept of prospective hindsight. Instead of asking, “What could go wrong?” the facilitator tells the team, “The project has gone wrong. What happened?”
That small shift can change the discussion. When failure is presented as something that might happen, people can dismiss uncomfortable scenarios as unlikely. Treating it as an established outcome encourages them to build a fuller explanation.
The research behind prospective hindsight suggests that this framing can help people generate more detailed reasons for a future outcome. It does not prove that a pre-mortem improves project success by a fixed percentage. The exercise improves risk discovery. Whether it improves the project depends on whether the team acts on what it finds.
Why Normal Risk Discussions Miss Important Problems
Most teams already talk about risk. The difficulty is that those conversations take place within the same hierarchy and expectations that shaped the plan.
A team member may believe the deadline is unrealistic but stay quiet because a senior leader has already announced it. A developer may know an integration is more complicated than the schedule allows but not want to sound uncooperative. An operations employee may see that the new process will create extra work, yet assume nobody wants to hear that during an optimistic kickoff.
A pre-mortem makes criticism part of the assignment. Nobody has to accuse the project owner of making a poor decision. Everyone has been asked to explain an imaginary failure.
The format can expose risks that do not fit neatly into a standard checklist:
- Decisions with no clear owner
- Assumptions supported by little evidence
- Dependencies outside the team’s control
- Skills the work requires but the team lacks
- Approval cycles missing from the schedule
- Products or processes that users may resist
- Support needs that begin after launch
- Small problems that become serious when they occur together
A pre-mortem can make dissent easier, but it cannot repair an unhealthy culture in one meeting. If employees expect to be punished for challenging a plan, the facilitator must actively protect independent thinking and prevent the session from becoming a defence of decisions already made.
Choose the Right Time and Participants
The team needs enough detail to identify specific weaknesses, but the project should not be so advanced that changing it becomes politically or financially difficult.
I would not run a full pre-mortem when the project is still little more than an idea. Before the session, participants should understand:
- The intended outcome
- How success will be measured
- What the project includes and excludes
- The main milestones
- Available staff, skills, and budget
- Important dependencies
- Assumptions behind the plan
- Approval or compliance requirements
- How the result will be launched and supported
The best time is usually after an initial plan has been drafted but before final approval or execution. Larger projects may need another pre-mortem after a major scope change, at an important phase gate, or shortly before an irreversible launch.
The participant list matters just as much. Include people who understand how the work will actually be delivered, used, and maintained, not only those who designed or approved it. Depending on the project, that may include technical specialists, operations employees, customer support, finance, legal, procurement, security, or someone familiar with the intended users.
Keep the group manageable. The goal is to cover different areas of knowledge without creating a meeting where quieter participants disappear.
If a powerful sponsor attends, ask everyone to write independently and have the most senior person share last. Anonymous input or a neutral facilitator may be necessary when power differences are likely to suppress honest concerns.
How to Run a Pre-Mortem
A focused pre-mortem usually takes 45 to 60 minutes. Complicated initiatives may need separate sessions for technical, operational, financial, and adoption risks.
1. Present the Plan Without Selling It
Start with a short, factual review of the project. Cover its objective, scope, timeline, resources, assumptions, dependencies, and success measures.
This is not the moment for a motivational presentation. Participants need a clear plan to examine, including its constraints and uncertainties.
Explain what can still change. If the deadline, budget, or scope is fixed, the team needs to know. Otherwise, participants may spend an hour proposing improvements that nobody has the authority to make.
2. Describe a Specific Future Failure
Move the team to a believable future date and state that the project has failed.
For example:
It is three months after launch. We delivered the project, but users are barely using it, support workload has increased, and the expected business benefit has not appeared. What caused this outcome?
A concrete failure produces better answers than saying only, “The project failed spectacularly.”
Define failure in terms of results, not just delivery. A project can meet its deadline and budget while producing something nobody wants. It can attract users while creating unsustainable support costs. It can achieve a short-term target while leaving the organization with a system it cannot maintain.
The scenario should reflect what the project is actually meant to accomplish.
3. Give Everyone Time to Think Silently
Ask participants to spend five to ten minutes writing down every plausible reason for the failure.
Do not begin with open discussion. The first speaker can shape what everyone else considers important. Silent writing protects independent ideas, gives quieter people time to think, and reduces pressure to agree with the room.
Encourage participants to include concerns they would normally hesitate to mention. The focus should remain on conditions, decisions, assumptions, dependencies, and processes rather than personal attacks.
4. Collect the Reasons Before Debating Them
Ask each person to share one reason at a time. Continue around the group until the meaningful ideas have been recorded.
The facilitator should allow questions for clarification but stop immediate rebuttals. If every concern receives a lengthy explanation of why it probably will not happen, people will quickly stop contributing.
Keep specialist concerns visible even when only one person raises them. A security, legal, or technical risk may receive little support simply because few people in the room understand it.
Once the independent ideas are collected, probe for gaps:
- We delivered the project, but why did users reject it?
- Which requirement remained unclear?
- Which approval arrived too late?
- Where did the plan assume people had more time than they did?
- Which task depended too heavily on one person?
- What happened when a vendor or partner missed a commitment?
- Who was expected to support the result after launch?
- Which warning sign did we notice but explain away?
- Which two manageable problems became dangerous together?
These prompts should expand the discussion, not replace independent thinking.
5. Turn Vague Concerns Into Usable Risks
“Poor communication,” “scope creep,” and “technical problems” are categories, not useful risk statements.
A clear risk connects a cause, a possible event, and its effect:
Because no one owns customer migration, existing clients may remain on the old workflow, leaving support costs unchanged after launch.
This identifies the condition creating the risk, what may happen, and why it matters. It also points toward an appropriate response.
Where possible, separate facts from assumptions. If a concern is based on evidence from previous projects, record that. If it is an untested assumption, label it accordingly and decide how the team can test it.
6. Prioritize With Judgment
The team cannot address every imagined failure equally. Assess the significant risks by asking:
- How damaging would this be?
- How plausible is it?
- How soon could it happen?
- Would we notice it early?
- How much time would we have to respond?
- Could the damage be reversed?
- Is the cause within our control?
- What evidence supports the concern?
Voting can help narrow a long list, but it should not make the final decision. Common risks tend to attract votes. Specialized risks can be overlooked because only one participant understands their severity.
A high-impact risk with little warning time may deserve attention even if it is not the most popular concern. I would rather see a team properly address five significant risks than leave with 40 color-coded possibilities and no commitments.
7. Decide What Will Change
This is where a pre-mortem either improves the project or becomes meeting theatre.
For every priority risk, record:
- A preventive action
- A contingency if prevention fails
- The earliest warning sign
- A risk owner
- The person responsible for the action
- A due date
- Any required budget or decision
- A review date
Prevention and contingency are different. Prevention reduces the likelihood of a problem. A contingency explains what the team will do if it happens anyway.
Ownership also needs to be specific. The risk owner monitors the exposure and escalates it. The action owner completes a particular mitigation task. These roles may belong to different people.
Whenever possible, update the project plan before ending the session. That may mean removing work, adding a pilot, moving a milestone, changing a dependency, assigning specialist support, or clarifying an approval path.
If the proposed response is simply “monitor the risk,” ask what will be monitored, by whom, how often, and what result will trigger action.
What Useful Pre-Mortem Output Looks Like
Imagine a team preparing to launch a customer portal. During the pre-mortem, it assumes the portal is technically live but customers continue contacting support instead of using it.
Possible causes begin to emerge. Customers were not involved in early testing. Account setup is confusing. Support employees still direct people to the old process. Nobody owns migration from the existing workflow.
Recording “low adoption” in a spreadsheet would not solve much. A useful response might include:
- Testing the portal with a representative customer group
- Simplifying account setup before the wider launch
- Assigning one person to own customer migration
- Training support employees before invitations are sent
- Agreeing on early adoption and support-warning indicators
- Preparing assisted onboarding if self-service adoption is weak
- Using a phased rollout instead of forcing every customer to switch at once
The session has now changed how the project will be delivered. That is the result to look for.
Where Pre-Mortems Commonly Go Wrong
The most damaging mistake is identifying that the plan is unrealistic and then refusing to change it. Adding more status meetings will not fix a project that requires more work than the available people can complete.
Other common problems include:
- Senior leaders give the first answers: Their interpretation anchors the discussion and may discourage disagreement.
- Every idea is debated immediately: Participants start filtering themselves instead of sharing what they know.
- Risks become accusations: Blame creates defensiveness and distracts from conditions the team can change.
- Owners receive no authority or capacity: A name in a risk register is not a mitigation plan.
- The output is never reviewed: Risks change as a project moves from planning to delivery and operation.
Teams may identify many convincing failure scenarios and still resist the difficult changes their own analysis recommends. My test is simple: if the scope, schedule, staffing, responsibilities, or launch approach should change, does the team actually change them?
If not, the pre-mortem has documented a warning without responding to it.
Know When a Pre-Mortem Is Not Enough
A pre-mortem is good at surfacing hidden assumptions, overlooked dependencies, and concerns people have not voiced. It is not designed to measure every form of risk.
Safety-critical systems may require formal hazard or failure-mode analysis. Cybersecurity projects need threat modeling and technical testing. Cost and schedule estimates should be compared with outcomes from similar completed projects when reliable historical data is available. High-stakes plans may also need an independent review or red team.
The risks identified during the session should enter a living risk register. Owners need to monitor warning signs, complete preventive actions, reassess exposure, and escalate problems when agreed thresholds are crossed.
A post-mortem still has value after the project ends. Comparing the failures the team imagined with what actually happened can improve future planning.
Make the Pre-Mortem Count
A project pre-mortem gives people a structured way to voice the concern they nearly kept to themselves. It creates time to respond while a difficult problem is still an assumption, dependency, or warning sign rather than an expensive reality.
The meeting itself is not an achievement. If the scope, deadline, staffing, ownership, and launch plan remain untouched afterward, the team has only described how the project may fail.
The real result should be a better plan: fewer unsupported assumptions, clearer responsibilities, earlier warning signs, funded preventive actions, and contingencies the team can actually use. That is how a pre-mortem can help save a project before it starts.
Frequently Asked Questions on Project Pre-Mortem
1. When should you run a project pre-mortem?
Run it after the team has developed a credible draft plan but before final commitments make the project difficult to change. Repeat it after major changes or before a high-risk launch if the original assumptions no longer hold.
2. How long should a pre-mortem take?
A focused session usually takes 45 to 60 minutes. Small projects may need less time, while complex initiatives may benefit from several targeted sessions. Always reserve enough time to assign actions and owners.
3. Who should lead the exercise?
A project manager, team lead, or neutral facilitator can run it. If the project owner is likely to defend the plan or dominate the discussion, use an independent facilitator and ask senior participants to speak last.
4. Can a pre-mortem be conducted remotely or individually?
Yes. Remote teams can use a shared document or digital board for silent input before discussing the risks together. An individual can also run a pre-mortem for a personal decision, although important projects benefit from people with different knowledge and perspectives.
5. How is a pre-mortem different from a post-mortem or risk assessment?
A pre-mortem imagines a future failure so the team can prevent or prepare for it. A post-mortem examines what actually happened after a project or incident. A formal risk assessment evaluates and tracks identified risks throughout delivery. A pre-mortem can help generate those risks, but it does not replace the wider risk-management process.
