- Imagine the planned project has already failed.
- Collect reasons alone before the group compares them.
- Turn the strongest risks into owned actions and warning signs.
The launch plan looks neat. The deadline is approved, the supplier sounds ready and nobody wants to slow the meeting with doubts. Two weeks later, a missing approval stops the work.
A pre-mortem gives those doubts a place. Before work begins, the team imagines that the project failed and writes down what caused it. The group then chooses actions that make the most likely failures less likely or less harmful.
Use it after the first plan, before commitment
Run it after the first plan. Do it before money is locked, customers are promised a date or staff are fully booked. Too early, the team has little to test; too late, useful changes cost more.
Johns Hopkins' premortem tool uses the same core move: imagine a project has failed, list the reasons and develop ways to reduce them. Its example serves a health project, but the exercise can be adapted to a small-business launch, move, event or system change.
Keep the method in scale. A high-cost or safety-critical plan needs qualified risk, legal or technical review. A short workshop is not a substitute.
Write a clear failure scene
Start with one sentence in the past tense. For example: “It is three months after launch, and the booking system failed to deliver the expected result.” State the agreed goal and the date.
Do not blame a person in the prompt. Focus on the outcome. The goal is to test the plan, not to decide who would deserve fault.
Share the first plan before the meeting. Link the steps to a one-page SOP when the work will repeat. People need enough detail to see real handoffs and assumptions.
Collect risks alone first
Give each person five to ten quiet minutes. Ask them to list reasons the failure happened. Private writing helps a junior teammate record a concern before the loudest voice sets the direction.
Prompt several angles: customer demand, scope, cash, people, data, supplier timing, approvals and support after launch. Include outside events, but spend most of the time on risks the business can influence.
Ask for causes, events and effects. The Association for Project Management says clear risk descriptions separate what is true now, what might occur and what effect would follow. “Supplier has one driver; delivery may slip; opening day could move” is more useful than “supplier risk.”
Group and rank what the team found
Put similar notes together without deleting the original concern. Invite each person to explain one item. Questions are useful; instant defence is not.
Now score each group with two plain tests:
- Likelihood: How plausible is this path with the facts we have?
- Impact: What happens to the goal, customer, cost or date if it occurs?
Use low, medium and high if numbers would add false detail. Mark what evidence supports the rating. A guess can stay on the page, but label it as an assumption.
The UK government's Orange Book says risk work should use scenario analysis, question optimistic assumptions and consider links between risks. Small firms can apply that principle without copying a government framework.
Choose responses, owners and warning signs
Start with the top risks. Decide whether to reduce, avoid, transfer or accept each one. Write what the team will do, not only what it hopes will happen.
Labelled example: An invented shop plans an online booking launch, but only one person knows how to export the old bookings. It assigns a second trained person, schedules a test export by Friday and watches for any record that fails to match.
APM says a risk register should record risks, responses and clear action ownership. Put the chosen items into a short register with the risk, owner, action, due date and early warning sign.
If the action needs a decision owner, check the small-team responsibility chart. If it needs spare hours, test the change in the weekly capacity plan before promising the date.
Change the plan while change is cheap
A list is not enough. Update the project scope, steps, budget, supplier plan or launch date where the evidence justifies it. Record accepted risks too, including who accepted them.
Do not treat every imagined failure as equal. Some controls cost more than the harm they prevent. The Orange Book stresses a proportionate approach that fits an organisation's context and complexity.
Plan major shocks elsewhere. The one-page business continuity plan guides the first response if vital work stops, while the pre-mortem improves this project plan.
Review at the first useful signal
Book a short risk check at the first milestone. Do not wait for the project to end. Compare the early warning signs with what is now happening.
Add new risks, close dead ones and adjust the action owner when work moves. The Orange Book treats monitoring as work that happens before, during and after a response. A small register should also stay alive.
Copy this 45-minute pre-mortem
- 5 minutes: restate the goal, plan and imagined failure.
- 10 minutes: write the possible causes alone before sharing, with nobody speaking.
- 10 minutes: group similar causes and clarify them.
- 8 minutes: rank each cause for likelihood and impact using the agreed labels.
- 8 minutes: choose actions, owners and warning signs.
- 4 minutes: name plan changes and the next review date.
The aim is not to prove the project will work. It is to reveal a weak path early enough to change it, then keep watching as new facts arrive.
Sources and scope
Johns Hopkins: premortem tool and guide · APM: risk management and registers · HM Treasury: Orange Book risk principles. This is general project-planning guidance, not a risk assessment for regulated, legal, financial, safety or medical work.