After the launch missed its window, everyone knew why: the field team was hired against a PDUFA date that had already shifted twice, and the patient services hub went live without load testing because the vendor integration slipped and nobody adjusted the sequence. Each of these risks was knowable before execution began, and the pre-mortem is the exercise that forces them into the open. Most organizations don’t run one; designing for failure before it arrives is how we approach this step.
How the Pre-Mortem Reframes Risk
Programs are approved on the basis of optimistic plans. The executive sponsor presents a timeline and a budget that justify the investment, the steering committee approves it, and organizational momentum shifts toward execution: the budget is allocated, people are staffed, and the implicit message is clear. In that environment, raising risks feels like dissent. The client who says “I don’t think we can hit the March milestone” is questioning the plan that was just approved. The political cost of raising the concern is tangible; the cost of staying quiet is abstract.
The pre-mortem inverts this dynamic. Instead of asking “does anyone have concerns?” (which tends to produce silence), it asks “assume this program has failed: what are the most likely reasons?” The question gives permission to be pessimistic because identifying failure modes is the exercise, not an act of dissent. The same person who wouldn’t raise a concern unprompted will name three failure modes when the format asks for them.
What a Pre-Mortem Produces
The pre-mortem produces a risk register that is qualitatively different from the risk logs most organizations maintain. A standard risk log is often a compliance artifact: risks are listed, rated on a likelihood/impact matrix, and assigned to owners who may or may not act on them.
A pre-mortem risk register is built from the room’s actual knowledge. The failure modes come from people who understand the program’s constraints, politics, and history. They name risks that would rarely appear on a standard risk log:
- “The field team hiring plan assumes a PDUFA date that has already shifted twice. HR has forty offers out with start dates that don’t work if the date moves again.”
- “The patient services hub vendor is six weeks behind on the integration build. Nobody has adjusted the hub staff training schedule to account for the delay.”
These risks come from people who understand how the organization actually operates, not from a risk brainstorm template. For the full exercise design, see Designing for Failure Before It Arrives. When maintained well, the risk register evolves into a record of how each risk was resolved.
The Constraints Calendar
The pre-mortem also produces a constraints calendar: a cross-functional view of when the organization can’t execute. Every function knows its own blackout windows (PDUFA date uncertainty, payer submission cycles, congress schedules, specialty pharmacy setup windows) but these are rarely compiled together. The program that failed had scheduled field team training during a period when the materials they needed didn’t exist yet, because nobody mapped the dependencies across functions. One team used a constraints calendar to save a launch; the full methodology is part of the pre-mortem exercise design.
Why the Pre-Mortem Matters
Programs that skip the pre-mortem and move directly from architecture to roadmapping build plans on top of unexamined assumptions. The risks don’t disappear because nobody named them. They surface during execution as surprises:
- The PDUFA date shift nobody planned for
- The vendor integration timeline nobody compiled across functions
Each of these surprises triggers a reactive response: emergency meetings, scope changes, and escalations to the executive sponsor. The program enters a cycle of crisis management that consumes leadership bandwidth and erodes confidence.
The pre-mortem takes one session. The failure modes it surfaces would otherwise take months to discover, and by then the cost of correction is far higher. For teams preparing to build a roadmap, the question worth asking is whether the plan has been tested against what the room already knows, or only against what the room was willing to say out loud.
