The methodology used to have eight steps. After program architecture, the engagement moved directly into roadmap sessions. The logic: once you have the workstream structure and dependencies defined, you have what you need to build the roadmap. Architecture gives you the “what”; roadmap sessions sequence the “when.”
Known Risks Materialized During Execution
The engagement was a multi-workstream program at a large retailer. The architecture work had gone well: the Workstream Hierarchy was clean and the charters were specific enough to map dependencies. The team moved into roadmap sessions with confidence. During execution, three knowable risks materialized within six weeks:
- The roadmap had sequenced a critical testing milestone during the organization’s annual physical inventory counts, which consumed the operations team for three weeks.
- QA resources needed for integration testing were shared with another program that had already claimed them for the same month.
- The rollout plan required store-level training before the pilot launch, but the training materials depended on configuration decisions that would not be finalized until two weeks before training was supposed to start.
Each of these risks was knowable before the roadmap was built. In two cases, the people who knew about them were in the room during roadmapping. They did not raise them because the session format asked for milestones, not risks.
Architecture and Roadmapping Don’t Surface Risks
The gap was between architecture and roadmapping. Architecture defined what the program would build; the roadmap defined when things would happen. Neither step asked: what do we already know that could blow this up? We had relied on roadmapping sessions to surface risks organically, assuming that when the team sequenced milestones, they would flag conflicts and constraints that threatened the timeline. In practice, the session format worked against that. Roadmapping sessions generate momentum; raising a risk feels like slowing things down, and nobody in a room of senior leaders wants to be the one pumping the brakes.
The Pre-Mortem Inverts the Social Dynamic
After that engagement, we added the pre-mortem as Step 4, designing for failure before the team starts building. The format changes the expectation: the exercise asks for failure modes, so naming them is participation rather than dissent. The operations lead who did not raise the inventory conflict during roadmapping will name it as a failure mode in a pre-mortem because the format asks for it. The pre-mortem also produces a constraints calendar: operational blackouts, peak periods, code freezes, budget cycles, and shared resource commitments compiled into a single cross-functional view. Once those constraints are visible, the roadmap gets built around them instead of into them. Over time, the risk register it generates becomes a decision log that tracks how the team resolved each risk.
Each Step Traces Back to the Problem It Solves
The book includes this origin story because it illustrates how the methodology was built. The pre-mortem solves the problem of known risks that the organization’s existing processes do not surface. A program leader who reads the pre-mortem chapter and recognizes her organization in this story knows where to invest; a program leader whose organization already has a mature risk assessment process can run a lighter version. The methodology is designed so that each step can be traced back to the problem it solves.
