VOL. I
NO. —
DOSSIER REGISTRY
DISP-157FILED: JUL 25

Pre-Mortem at the Planning Counter

Gary Klein's pre-mortem turns project risk into a short exercise in prospective hindsight before the budget, timeline, and reputation are already spent.

Tools Worth Filing4 min read

KEY TAKEAWAYS FOR COGNITIVE LOGGING

  • Assuming failure has already happened makes hidden risks easier and safer to name.
  • The method works because it separates risk discovery from blame.

Today’s workbench tool is small enough to run before lunch and useful enough to save a quarter. Gary Klein’s pre-mortem asks a team to imagine that the project has already failed, then write down why. Instead of asking people to predict possible risks, it asks them to explain a fictional disaster after the fact.

That shift is the machinery. The digest points to Klein’s work on prospective hindsight: imagining an event as already having occurred can improve people’s ability to identify causes. The exact lift will vary by context, but the operational value is obvious. People often know the risks before the plan starts. They just lack a socially safe way to say them.

Normal planning meetings reward confidence. The project sponsor wants momentum. The team wants approval. Junior members may see implementation hazards but stay quiet. Experts may notice a dependency is weak but avoid sounding obstructive. The pre-mortem changes the frame. Nobody is accusing the plan of failure; everyone is contributing to a fictional case file.

The process is simple. Gather the relevant team. State that it is six months from now and the project has failed badly. Give everyone a few quiet minutes to write every cause they can imagine. Then collect one reason at a time until the list is exhausted. Only after the risks are visible should the group cluster, rank, and assign mitigations.

The quiet-writing step matters. If the loudest person starts first, the room converges too early. Independent notes preserve weak signals. Round-robin sharing keeps status from deciding which concern gets oxygen.

For AI projects, the method is especially useful. A failed deployment may trace back to data rights, hallucination tolerance, evaluation gaps, latency, cost, security review, procurement delays, user trust, or a workflow that never needed automation. These risks are often known by different people. The legal issue sits with counsel, the latency issue with engineering, the adoption issue with operations, and the evaluation issue with the product lead.

The pre-mortem does not replace planning, testing, or governance. It gives those disciplines better input. A good session should end with concrete changes: a smaller pilot, a kill criterion, a second vendor, a red-team checkpoint, a budget reserve, a customer interview, or a decision to stop.

The frontier habit is to admire speed. The wiser habit is to spend 30 minutes visiting the wreck before laying the track.

FILED EVIDENCE (VERIFIABLE SOURCES)

FILE CODEDOCUMENT DESCRIPTION
REF-101The Pre-Mortem Method
REF-102The Pre-Mortem Method