How to Run a Project Pre-Mortem That Changes the Plan

A useful project pre-mortem does more than ask what could go wrong. It changes the plan before the expensive work begins. The team imagines that the project has failed, names the plausible causes, and converts the most important ones into early warning signals, preventive moves, owners, and response rules.

The exercise is not finished when the board is full of risks. It is finished when the plan is smaller, clearer, or better defended.

What a project pre-mortem should produce

A pre-mortem starts with imagined failure, but its real subject is the current plan. You are looking for assumptions that have not been tested, dependencies that have no owner, decisions that will arrive too late, and quality checks that happen after rework becomes expensive.

By the end, keep a short record with five outputs:

• three to five plausible failure paths;
• the earliest visible signal for each one;
• one preventive change that can be made now;
• a named owner for watching or acting;
• a trigger that tells the team when to use the response plan.

If the project does not yet have a clear finish line, establish that first. The definition-of-done framework gives the pre-mortem something specific to test.

When to run the exercise

Run a pre-mortem after there is enough of a plan to challenge, but before the team has committed so much time, money, or reputation that changing course feels impossible. A kickoff, a scope decision, or the week before a launch can all work.

Run it again when a major assumption changes. A new deadline, missing contributor, reduced budget, new approval layer, or altered deliverable can create a different failure path even when the original plan was sound.

Small projects do not need a large meeting. One person can complete the same exercise on paper. The method matters more than the room.

A 35-minute project pre-mortem agenda

This version is short enough to use and structured enough to end with decisions.

Start with silent writing

Do not begin with an open discussion. The first confident voice can narrow the room before quieter concerns appear. Give everyone the same failure statement and several minutes to write alone.

Ask for causes, not dramatic endings. "The launch went badly" is an outcome. "The final approver first saw the work two days before launch" is a cause the team can examine.

Keep each note to one idea. That makes it easier to group repeated concerns and separate a root cause from its downstream effects.

Use questions that expose the plan

Generic worry produces generic risk. Move through the project from inputs to delivery.

Scope and finish

• Which requirement could expand after work begins?
• What would the team keep polishing because no stopping rule exists?
• Which part of the deliverable is necessary, and which part is only preferred?

Inputs and constraints

• What access, information, budget, equipment, or approval must exist before a milestone can begin?
• Which assumption has not been checked by the person closest to it?
• Where does the schedule assume full capacity with no interruption?

Ownership and handoffs

• Which decision belongs to more than one person or to no one?
• Where can work wait without anyone noticing?
• What must the next owner receive to act without reconstructing the project?

If a handoff is a major risk, use a concrete project handoff document rather than a promise to communicate better.

Quality and delivery

• What could be technically complete but unusable for the recipient?
• Which defect becomes expensive if discovered only at the end?
• What evidence will show that the work is ready to deliver?

Turn each concern into a risk card

A useful risk card is brief. It should make the next decision easier without becoming a second project plan.

• Failure: What did not work?
• Cause: What plausible condition created that result?
• Early signal: What would appear before the failure?
• Prevention: What change can reduce the risk now?
• Trigger response: What will happen if the signal appears?
• Owner: Who has the context and authority to act?
• Review point: When will the team check the signal?

For example, "feedback may be late" is too vague. A stronger card says: the approver may not review the first complete draft before production begins; the early signal is a missed outline review; prevention is a reserved review window; the trigger response is to reduce the next production batch; the project lead owns the check on a named date.

The point is not to predict the future perfectly. It is to recognize trouble while the response is still affordable.

Choose risks by action, not anxiety

A vivid risk is not automatically an important one. Select risks using three tests:

1. Consequence: Would this materially damage the finish, deadline, budget, trust, or ability to recover?
2. Plausibility: Is there a credible path from the current plan to this failure?
3. Control: Can the team prevent it, detect it earlier, reduce the damage, or prepare a fallback?

A low-control risk may still belong on the list, but its action will be contingency planning rather than prevention. A low-consequence risk may simply be accepted. Naming that choice is better than pretending every concern deserves equal attention.

Make the plan absorb the lesson

Do not store all the value in meeting notes. Change the working plan while the conversation is fresh. That may mean narrowing scope, moving an approval earlier, reserving capacity, sequencing uncertain work first, adding a quality check, or creating a fallback deliverable.

Record any meaningful tradeoff in a decision log. The pre-mortem explains what could fail; the log preserves what the team changed and why.

Then schedule one review at the first meaningful signal point. A risk reviewed only at the final deadline is not being monitored. It is being remembered too late.

A solo pre-mortem for independent work

If you are working alone, separate the planner from the critic by time. Write the current plan, step away, then return and assume the project failed. Generate causes without editing them. After a short break, rank and convert them into risk cards.

Use an outside reader when the risk depends on an audience, client, or specialist you cannot represent accurately. Self-made never means made alone. A second perspective can reveal an assumption without taking ownership away from you.

Common mistakes to avoid

• Starting before a plan exists. Without scope, finish, or constraints, the exercise becomes free-floating pessimism.
• Debating during the writing phase. Capture the full set before deciding what deserves action.
• Assigning every risk to the coordinator. Ownership should follow context and authority.
• Keeping too many risks. A long register can hide the few signals that matter now.
• Treating prevention as a slogan. "Communicate more" is not a control; an earlier review with an owner and date is.
• Failing to change the plan. Insight without a changed decision is only commentary.

Plan for the work, then do it

A pre-mortem is a moment of disciplined doubt. It gives concerns a useful form, protects dissent from becoming personal, and makes the plan earn confidence through clearer controls.

Once the risks have owners and triggers, return to the work. If a repeatable layer helps mark that shift from planning to execution, the Standard Issue Hoodie is a quiet black fleece option with the ascending mark embroidered at the chest. It is a uniform for the session, not a substitute for it.

For more practical systems for building, finishing, and learning, read The Self Made Journal.