A risk list is a starting point. It names what could go wrong. A Risk Landscape is a decision-making tool. It names what could go wrong, prioritizes what matters, maps the timing constraints the plan must respect, and defines what the team refuses to sacrifice when execution gets difficult. The Risk Landscape has four components. Each addresses a different dimension of risk that a simple list cannot capture. Programs that build all four components enter execution with a realistic picture of what they face. Programs that stop at the risk list enter execution with optimistic assumptions that will be corrected by reality.
Component 1: The Pre-Mortem Output
The pre-mortem is a structured exercise. The team imagines the program has failed. Not might fail. Has failed. From that vantage point, they work backward: what were the most likely causes? This inversion matters because it changes the psychology of risk identification. In a traditional risk workshop, raising concerns can feel like dissent. In a pre-mortem, it is expected. The team is not predicting failure. They are preventing it by being honest about what could cause it. The pre-mortem output is a prioritized list of failure modes. Each failure mode is stated with enough specificity to be actionable. “Poor communication” is not a failure mode. “The product team and engineering team had different assumptions about the API specification, and no one caught the discrepancy until integration testing” is a failure mode. The quality bar: the failure modes are specific enough that the team can design a mitigation for each one. If a failure mode is too vague to mitigate, it needs to be decomposed into specific scenarios. The pre-mortem should generate five to ten high-priority failure modes. If it generates thirty, the team has not prioritized. If it generates two, the team was not honest enough. Why pre-mortems change the conversation explains the facilitation technique: the most senior person in the room should go first with a genuine concern, signaling that candor is expected.
Component 2: The Risk Register
The risk register takes the failure modes from the pre-mortem plus risks identified during stakeholder mapping, architecture sessions, and the calendar overlay, and structures them into a decision-making format. For each risk, the register captures: a description specific enough to act on; the likelihood (high, medium, or low); the impact if the risk materializes (high, medium, or low); the owner (one person accountable for managing this risk); the disposition (mitigate, monitor, or accept); and for mitigated risks, the mitigation plan with specific actions and timelines. The quality bar: the register forces prioritization. If every risk is rated high-likelihood and high-impact, the register has failed to differentiate. The team should be able to identify the vital few risks that require active mitigation, distinguish them from risks being monitored, and name the risks being consciously accepted. A risk without an owner is a risk that will not be managed. Every line in the register needs a name. “The program team” is not an owner. A specific individual is. The risk nobody put on the register documents cases where risks were identified in pre-mortems but never transferred to the register with owners and mitigation plans. The risks were surfaced. They were not managed.
Component 3: The Calendar Overlay
The calendar overlay maps the program’s timeline against the organization’s operational reality. It answers the question: where does the program’s plan collide with the organization’s existing commitments? The overlay identifies several types of constraints: Blackout windows. Periods when changes cannot occur. Retail organizations have holiday freezes. Financial services companies have regulatory filing periods. Healthcare organizations have accreditation cycles. The program’s timeline must respect these windows. Capacity constraints. Periods when the organization’s bandwidth is reduced even if no formal blackout exists. Budget season pulls finance resources. Annual planning pulls leadership attention. Summer and holiday periods reduce available staffing. The program should not assume uniform capacity across the calendar. External dependencies. Vendor milestones, customer commitments, and regulatory deadlines that intersect with the program timeline. These constraints originate outside the program boundary but affect the program’s ability to execute on schedule. The quality bar: the overlay is honest about capacity, not just blackouts. A timeline that avoids blackout windows but assumes full team capacity during the organization’s busiest operational period is not realistic. The complete deliverable map describes how upstream planning artifacts connect to the calendar overlay by identifying the deliverables that must fit within realistic timing windows.
Component 4: The Principles and Guardrails One-Pager
The principles and guardrails document states what the team will and will not compromise on when execution pressure mounts. Execution always involves trade-offs. The question is whether those trade-offs are made deliberately (guided by pre-defined principles) or reactively (guided by whatever is easiest to cut in the moment). Principles are specific enough to guide decisions. “We value quality” is not a principle. “The team will not skip user acceptance testing regardless of timeline pressure” is a principle. It tells the team what they are protecting and what it costs to protect it. Guardrails are the boundaries that protect the principles. If the principle is that user acceptance testing will not be skipped, the guardrail is: UAT is included in every deployment plan, with a minimum duration of two weeks, and cannot be compressed without program leadership approval. The quality bar: a reasonable person reading the principles document can determine, for a specific trade-off decision during execution, which option the principles support. If the principles are too abstract to guide real decisions, they are not specific enough. Programs that failed with good plans documents programs where guardrails were not defined and execution pressure led to compromises that undermined the initiative’s core objectives. The guardrails would not have prevented the pressure. They would have prevented the capitulation.
How the Four Components Work Together
The four components form a system. The pre-mortem identifies the risks. The risk register structures and prioritizes them. The calendar overlay maps the timing constraints. The principles and guardrails define what the team will protect. Remove any one component and the Risk Landscape has a gap. Without the pre-mortem, the register contains only the risks that someone thought to write down. Without the register, risks are surfaced but not managed. Without the calendar overlay, the timeline collides with operational reality. The question is whether your Risk Landscape will connect all four dimensions before execution begins: or whether your team will encounter unexamined risks, timing collisions, and compromised guardrails as separate surprises during execution.
Go Deeper: The Risk Landscape
This article covers one dimension of the Risk Landscape, the fourth of nine artifacts in the Planning & Roadmapping method. The Risk Landscape answers the board question: “What could break this?” Explore the full Risk Landscape →
Keep Reading
Ready to close specific gaps in your Risk Landscape? These articles show you how: