How to Run a Premortem for a Small Project
- How do you run a premortem?
- What should you bring to the conversation?
- How can you collect concerns without treating them as facts?
- What does a completed worksheet look like?
- Can the proposed checks fit the available time?
- How do you keep the discussion proportionate?
- What happens after the meeting?
- Sources
How do you run a premortem?
A premortem asks a group to imagine that its proposed project has failed, then identify possible explanations before work proceeds. Use it to question the plan and choose checks or changes while there is still room to act. The small-project worksheet below separates imagined problems from established facts. It is for ordinary administrative projects, not a replacement for required safety assessments or specialist advice.
Gary Klein's description starts with a team briefed on a plan and asked to imagine its failure. The crucial distinction is that the outcome is fictional: nobody has discovered what will happen.
Our worksheet applies that idea to a modest shared task. Its example, labels and arithmetic are editorial inventions, not results from a tested intervention.
What should you bring to the conversation?
Start with a plan specific enough to question. Our suggested starting record contains the intended output, its recipient, the agreed deadline and any input another person must supply.
For example, "improve the club's information" gives the discussion very little to examine. "Prepare a directory with six checked entries for the club secretary by Friday afternoon" names a deliverable. It still leaves questions about what an entry needs and who will check it.
If the main question is which project to choose, write a one-page decision memo first. This exercise examines the execution of a proposed choice.
How can you collect concerns without treating them as facts?
Give everyone time to form their own notes before combining them. Atlassian's premortem play uses silent writing, followed by grouping similar ideas. That is a useful starting arrangement; our example does not copy its meeting schedule or voting system.
Ask participants to distinguish an imagined explanation from evidence available now. "The directory arrived late because entries were incomplete" describes the scenario. "We have not agreed which fields each entry needs" is a present question that can be checked.
Record both. Otherwise, a plausible story can quietly become the group's account of something that has already happened.
What does a completed worksheet look like?
Here is our fictional directory example. The team has not yet started production, and none of these problems is a reported event.
| Imagined explanation for failure | Present uncertainty | Check proposed before production |
|---|---|---|
| Entries used different formats | Required fields have not been agreed | Prepare one sample entry for the secretary to accept or revise |
| A contributor stopped midway | Nobody has confirmed backup coverage | Ask each contributor to confirm availability and an agreed handoff route |
| The directory contained old information | The checking source is unspecified | Name the approved source and record when each entry was checked |
The second column is the useful restraint. It tells the team what it does not yet know. The third proposes a way to learn something; it does not certify that the eventual directory will be correct.
For the sample-entry check, an action record might read: "The editor will send one completed sample to the secretary by Tuesday noon; production starts after the required fields are confirmed." Both people must agree to that arrangement. A name in a table does not create availability.
Can the proposed checks fit the available time?
Estimate their cost openly. The following minutes are invented planning allowances, not recommended durations:
| Proposed check | Assumed time |
|---|---|
| Prepare and review a sample entry | 20 minutes |
| Confirm contributor availability | 10 minutes |
| Agree the information-checking source | 15 minutes |
| Total | 45 minutes |
If the team has allocated only 30 minutes, the proposed checks exceed that allowance by 15 minutes: 20 + 10 + 15 = 45, and 45 - 30 = 15.
The next decision is to arrange more time, alter the project or reconsider the checks with the responsible people. Do not relabel 45 minutes as 30 to make the document look finished. Also distinguish effort from elapsed time: a short review can still wait a day for its recipient.
How do you keep the discussion proportionate?
Our suggested sorting question is: would resolving this uncertainty change a real commitment in this plan? A required-field disagreement can change every entry. A preference about the directory's decorative border may wait until the core information is settled.
That is a judgement for this fictional administrative task, not a universal risk-scoring formula. Record a deferred question and the reason for deferring it. Do not claim it has been resolved.
Keep this lightweight format away from decisions involving safety, health, legal duties or substantial financial exposure. Follow the applicable formal process and obtain qualified help. A group discussion cannot authorize skipping a required assessment.
What happens after the meeting?
Atlassian's play calls for action owners and deadlines, accessible records and later revisits. Put the agreed checks where the project is actually managed.
For our directory example, distinguish "sample requested," "sample received" and "format agreed." Those are different states. The editor should not start production on the assumption that silence means approval.
After the project, an after-action review can compare actual events with the earlier record. Keep the premortem's imagined explanations labeled as such: an outcome resembling a prediction does not, by itself, establish its cause.
More tools sit in Clear Decisions. The useful result here is a plan with explicit open questions and agreed responses, not a longer list of worries.