Projects often look plausible when everyone is focused on the launch date. A premortem temporarily changes the perspective: imagine it is six months later and the initiative has failed. What most likely caused the failure? The exercise makes it easier to articulate risks without directly attacking a colleague’s proposal.
The core idea
A premortem is a structured risk discussion. It can complement a formal risk register, design review or safety assessment, but it does not replace technical verification or regulatory requirements. The value comes from turning concerns into assigned preventive actions.
How to apply it
- Define the project and the imagined failure in one neutral sentence.
- Allow everyone to write plausible causes independently before discussion so senior voices do not dominate.
- Group ideas into themes such as scope, capability, approvals, technology, people and external dependencies.
- Rank concerns by severity and credible likelihood; identify existing evidence and assumptions.
- For the highest risks, assign a specific control, owner, due date and checkpoint. Revisit these through the project.
A workplace example
A website team preparing a major release imagines that launch day went badly. Participants identify broken logins, poor mobile performance, missing privacy disclosures and unverified payment journeys. The team adds device tests, a staged release plan and a clear rollback decision rather than relying on confidence alone.
What to watch out for
Premortems can turn into speculative fear lists unless ideas are assessed. Avoid inventing precise probabilities without evidence. The team should also note strengths and successful controls, and should not use the exercise to punish people who reveal difficult risks.
Practice and reflect
Run a 20-minute premortem for one upcoming decision and assign one action to the highest-priority risk.