Project premortem: a meeting agenda and completed example

A premortem is a meeting in which the team imagines a project has already failed and looks for explanations of the outcome. It uses inversion: starting with failure to investigate the conditions that could produce it before executing the plan.

A fictional company is changing its customer support platform. The demonstration worked, training took place and the date was announced. What remains to be checked is whether open requests will retain their histories, owners and next actions after the change.

Choose a failure you can examine

AHRQ describes the premortem as a resource for anticipating implementation barriers. The proposed causes are hypotheses that need checking.

Define the unwanted outcome being examined. For the platform change, it could be losing continuity on open requests. Simply saying that the change was a disaster leaves room for concerns about different problems.

Also agree on the period. A first-day interruption requires different questions from a difficulty that appears after months of use. If both matter, keep separate records to avoid mixing causes and measures.

A suggested agenda for a 45-minute meeting

Invite people who serve customers, configure the system and decide on the transition. Send the plan and failure criterion in advance. The time allocation below is a facilitation proposal for this case, not a duration required by the technique.

If the discussion reveals that nobody can describe a request's path, stop selecting risks and reconstruct that path. Voting on a poorly understood list merely organizes the uncertainty.

Writing individually before the discussion may make room for an observation that would not emerge after hearing the leadership. For this to work, the facilitator needs to receive concerns without requiring the participant to prove the entire hypothesis immediately.

Replace broad concerns with mechanisms

“The team will resist” attributes a general disposition to people. A more useful formulation would be: the person receiving a request will not know which system to update because transition rules have not been defined.

Ask which condition connects the proposed cause to failure. Is there a tool limitation? Is a decision missing? Does the problem depend on an exceptional case, or could it occur in normal use? Look for records, demonstrations and people who can help check the relationship.

A long risk list does not tell you frequency or severity. Distinguish evidence from possibility and note uncertainties. The technique can make a concern more visible without making it more likely.

Choose checks that change the plan

The company could migrate a set of open requests and check their histories, owners and next actions. It could also simulate a message received during the transition and follow its path through support.

Each check needs an owner and a consequence for the plan. If essential history is not preserved, the team might postpone the change or retain secure access to the old system for reference. The outcome depends on what is found.

Compare these measures' costs with the alternatives. Keeping two systems may preserve access and generate conflicting updates. As with choosing tools, follow the whole process and the effort required to leave each option.

A completed worksheet for the platform change

The last risk distinguishes the presence of data from the ability to continue work. An exported file may exist and still require a manual search the operation cannot sustain.

To prioritize, start with failures that prevent handling an essential request and have no demonstrated recovery. Next examine relevant consequences that can be checked before the change with little effort. Reversible inconveniences can remain under monitoring, with a named owner. This order is a working criterion for the example, not a validated probability scale.

When copying the worksheet for your project, keep four fields: observable failure; missing check; owner and deadline; decision if the test fails. The investigation worksheet can hold observations and separate facts from interpretations.

Record what the exercise did not resolve

A premortem depends on participants' knowledge and willingness to contribute. It can miss problems, repeat the group's beliefs or focus attention on a memorable story. Invite someone to look for a different explanation of the same outcome.

After correcting a weakness, examine what the correction added. An extra approval may reduce an error and create a delay. The revised plan also needs owners, limits and monitoring conditions.

By the end of the meeting, every item blocking the transition needs a scheduled check. If the answer will not arrive before the change date, someone must explicitly decide whether to postpone or accept the remaining exposure. A list of concerns without that consequence provides no criterion for authorizing the switch.