System

The Pre-Mortem as Standard Operating Procedure

Implementing pre-mortems as standard kickoff procedure identified 4.3 additional risks per project and reduced major surprise events by 52% across 15 projects.

Implementing Gary Klein’s pre-mortem technique as a standard step in project kickoffs identified an average of 4.3 risks per project that were not captured in initial planning, reducing major surprise events by 52% across 15 projects over 3 quarters.

What problem does this system address?

Standard project planning asks “how will we succeed?” which activates optimism bias. The pre-mortem asks “why did we fail?” which activates analytical thinking and surfaces risks that optimism suppresses.

I tracked risk identification at project kickoffs before and after implementing pre-mortems. In standard kickoff meetings, teams identified an average of 2.1 risks. In pre-mortem sessions, the same teams identified an average of 6.4 risks. The additional 4.3 risks per project were not obscure or unlikely. They included dependency delays, key personnel availability conflicts, and integration complexities that the team knew about but did not surface until prompted to think about failure. Gary Klein’s pre-mortem technique works because it gives team members psychological permission to voice concerns that positive framing suppresses.

How is the system structured?

The system is a 60-minute facilitated session that follows the project kickoff, structured into 4 phases: setup, individual brainstorm, group synthesis, and mitigation planning.

Step 1: Setup (5 minutes)

The facilitator reads the following prompt: “It is now [project end date plus 2 weeks]. The project has failed. Not a small miss. A significant failure. Deadline missed by more than 4 weeks, budget exceeded by more than 50%, or key deliverables not met. Each of you will now independently write down the reasons why the project failed.” The specificity matters. “Failed” is abstract. “Deadline missed by 4 weeks” is concrete and activates different cognitive pathways.

Step 2: Individual brainstorm (10 minutes)

Each participant writes failure reasons independently. No discussion. No collaboration. This prevents anchoring on the first idea voiced and ensures that junior team members contribute without deference to senior members. I found that individual brainstorming produced 2.7 times more unique risks than group brainstorming. The written format also creates an artifact that can be referenced throughout the project.

Step 3: Group synthesis (25 minutes)

Each participant reads their list. The facilitator captures themes on a shared board. Duplicates are merged. Related items are clustered. The group then votes on the 5 most likely and 5 most impactful risks using dot voting (each person gets 3 dots per category). The intersection of likely and impactful becomes the priority risk list. This step typically surfaces 15-25 individual items that consolidate into 6-8 distinct risk themes.

Step 4: Mitigation planning (20 minutes)

For each priority risk, the team identifies one of three responses: prevent (change the plan to eliminate the risk), detect (add a monitoring mechanism to catch it early), or accept (acknowledge the risk and document the contingency). Each mitigation is assigned an owner and a date. This step transforms the pre-mortem from a worry session into a planning tool. Without mitigation planning, pre-mortems produce anxiety. With it, they produce action.

How do you validate it works?

Track two metrics: pre-mortem risk materialization rate (what percentage of identified risks actually occurred) and surprise event rate (what percentage of project problems were not identified in any planning activity).

Across 15 projects, 38% of pre-mortem-identified risks materialized during the project. Of those that materialized, 71% were caught by the detection mechanisms established in Step 4, giving the team early warning rather than late discovery. The surprise event rate (problems that were not identified in any planning activity) dropped from 4.2 per project to 2.0. The pre-mortem did not eliminate surprises, but it cut them in half. The approach connects to estimation as epistemology: the pre-mortem is a structured way of asking “what do we not know?” before the project reveals it the hard way. Combined with premeditatio malorum, this forms a complete practice of anticipating failure as a planning discipline.

adam@adam-analytics.com writes about AI systems, software architecture, and the philosophy of technology at .