Book Excerpt: The Pre-Mortem Chapter

The following is adapted from the pre-mortem chapter of the book. Step 4 sits at a critical inflection point: after the team has built a shared understanding of the program’s structure and before they begin building the roadmap. The pre-mortem ensures the roadmap gets built on a foundation of honest assessment rather than untested optimism. For the full methodology context, see designing for failure. The pre-mortem begins with a single prompt: “Imagine it is twelve months from now and this program has failed. What went wrong?” The prompt assumes failure has already happened and asks the room to explain it. This flip changes the thinking; instead of evaluating probabilities, which produces cautious, hedged answers, the room narrates a story they already believe is plausible. By this point, the team has completed intake, stakeholder mapping, and program architecture. They know the workstreams and stakeholder landscape well enough to be specific. A brief period of independent writing captures the full room before the most senior person can anchor the conversation. The output reflects twelve or fifteen distinct perspectives rather than three or four that survived the social filter. The facilitator collects and reads failure modes aloud without attribution, separating the idea from the person. The room evaluates each failure mode on its merits rather than on the organizational authority of whoever raised it. For the full facilitation approach to clustering and prioritization, see Designing for Failure Before It Arrives. Some failure modes are low-probability and low-impact; others are high-probability and high-impact and need owners and mitigation strategies before the team moves to roadmapping. The prioritized failure modes become a risk register grounded in what the participants actually know about the program’s constraints and politics: structurally different from the risk logs most organizations maintain. A typical risk log is a compliance artifact with generic entries; “resource constraints” appears on every risk log and tells the team nothing actionable. The pre-mortem risk register contains entries like: “The CRM migration depends on territory alignment data that sales leadership hasn’t finalized. The new comp model can’t be built until territories are set, and the field force is three weeks from open enrollment.” That level of specificity makes the risk actionable: finalize territory alignment before committing to the CRM migration date. Each entry has an owner and a mitigation plan with trigger conditions; the full register template is in Designing for Failure. The step also produces principles and guardrails. Principles are operating commitments (e.g., “Dependencies between workstreams will be surfaced in the biweekly integration review, not in ad hoc escalations”). Guardrails define acceptable variation: scope changes affecting more than one workstream require steering committee approval; budget reallocation within a workstream is at the lead’s discretion. Together, they define the space within which the team can operate independently. The constraints calendar turns operational realities into planning inputs by compiling each function’s blackout windows and peak periods into a cross-functional twelve-month timeline. One constraints calendar saved a Q3 launch by surfacing conflicts weeks before they would have derailed execution. The full pre-mortem chapter, including facilitation scripts and exercise templates, is in the book. For a case study of what happens when this step is skipped, see the pre-mortem nobody ran.