Team Operations
Project Premortems: Find Risks Before Work Begins
Imagine a project has failed, then turn plausible reasons into observable warning signs, responsible owners and proportionate mitigations.
What you will learn
- Explain a premortem and distinguish it from a retrospective
- Turn an imagined failure into specific risks rather than predictions
- Choose warning signs and proportionate actions with accountable owners
A project premortem asks a team to imagine that a proposed plan has failed, then explore plausible reasons why. The purpose is to uncover risks while the plan can still change. An imagined failure is a prompt for investigation, not a prediction that the project will fail.
Use the exercise when the team has a plan specific enough to examine. Without a defined outcome, scope and dependencies, people tend to produce generic worries rather than actionable risks.
What is the meaning of premortem?
Gary Klein describes the premortem method as imagining failure after a team has been briefed on a plan and generating potential threats. Credit that origin while keeping the discussion grounded in your own project's facts.
A premortem happens before the outcome is known. A retrospective examines work that has already happened. Both can support learning, but they use different evidence: one explores possibilities; the other reviews observations.
Start with a concrete fictional plan
Imagine a small software company plans to release a customer knowledge resource. The proposed launch includes reviewed articles, a working search path, clear ownership and a customer announcement. The team will not change product permissions or billing as part of the release.
Now imagine the launch has not met its purpose. Customers cannot find answers, support receives repeated questions and the team is unsure which content is current. Ask people to identify plausible ways the plan could have produced that outcome.
Give participants room to write independently before discussion. The goal is to hear concerns that might otherwise stay unspoken, not to reward whoever tells the most dramatic story.
How to perform a premortem?
Use the failure story to produce specific risks, then test what is known about them. The original worksheet below uses the fictional resource launch; it is not an incident report.
| Imagined failure | Risk to investigate | Indicator and proportionate response |
|---|---|---|
| Customers cannot find the answer | Search and navigation may not match customer language | Test a small set of real questions before release; content owner reviews failed routes |
| Articles become contradictory | Updates may lack a shared source and owner | Check for conflicting instructions; assign the source owner and review trigger |
| Announcement points to an unavailable page | Publication and messaging may be sequenced incorrectly | Verify live destinations before sending; release owner can hold the announcement |
| A useful answer exposes restricted information | Public and private material may be confused | Review source permissions; authorized reviewer resolves uncertain content |
Add evidence, uncertainty and a review date. Do not invent a probability because a risk register has a probability column. Qualitative judgments can be useful when their basis and limits are clear.
Separate a concern from a reason to stop
Some risks can be reduced through a small check. Others require changing scope, adding capability or not proceeding. Discuss the cost of the mitigation as well as the concern. A review process that takes more work than the project may not be proportionate.
For the fictional search risk, a focused test can reveal whether the main questions lead to useful answers. It does not prove that every future question will work. Decide what evidence is sufficient for the release and what should remain monitored afterward.
Security, privacy and consequential access questions should go to the responsible owner. A brainstorming exercise cannot authorize bypassing a safeguard or publishing uncertain material.
Make ownership and triggers visible
Every selected action needs a person who accepts responsibility, a checkable output and a point at which the team revisits it. “Be careful with links” is not a mitigation. “The release owner verifies all announcement destinations are live before sending” is observable.
Keep unselected risks and the reason for accepting them. Otherwise, the team may repeat the same debate or later assume a concern was never considered. Revisit the exercise when the plan changes materially rather than treating it as a one-time ritual.
The 90-day operating plan lesson shows how goals become coordinated actions. The project management guide supports the broader work around scope and dependencies. A premortem is one focused review within that planning process.
Copyable AI prompt
Try this with Aurora AI in Finta, Codex, or Claude, using authorized project information.
Read [proposed plan], [known dependencies] and [constraints]. Imagine the intended outcome was not achieved. Generate plausible failure mechanisms, clearly labeled hypotheses rather than facts. For each, identify existing evidence, uncertainty, a warning sign, a proportionate mitigation, responsible human owner and review trigger. Include privacy and access questions without making legal or security attestations. Do not invent probabilities, approve risk acceptance or change the project. Prepare a workshop draft for human review.Leave with a better plan
Explore Finta's Decision Red Team for preparing the questions. Judge the exercise by the useful changes it prompts, not by the length of the risk list.