Having a Risk Landscape is not the same as having one that is execution-grade. Most programs produce some version of risk documentation during planning. A risk register exists. Someone ran a risk workshop. A few calendar constraints are noted in the project plan. The question is whether what exists meets the quality bar required for the artifact to do its job: giving the planning team a realistic picture of what could go wrong, what timing constraints the roadmap must respect, and what the team will protect when execution pressure mounts. This article defines the quality benchmark across all four components of the Risk Landscape. It is written for leaders whose programs already have risk documentation and who want to evaluate whether that documentation is execution-grade.
Component 1: The Pre-Mortem Output
What execution-grade looks like
The pre-mortem has produced five to ten high-priority failure modes, each stated with enough specificity to design a mitigation. The failure modes include political and organizational risks, not just technical and resource risks. At least one failure mode names an uncomfortable organizational reality that the program needs to design around. The quality bar: the failure modes were generated through an exercise that created genuine psychological safety for candor. The most senior person in the room contributed a real concern, not a softball. Participants wrote individually before sharing. The facilitator enforced specificity.
The test
- Do the failure modes include at least one political or organizational risk that would be uncomfortable to present to the sponsor?
- Is each failure mode specific enough to design a mitigation?
- Were the failure modes generated through individual writing before group discussion?
Why pre-mortems change the conversation describes the facilitation techniques that produce execution-grade pre-mortem output.
Component 2: The Risk Register
What execution-grade looks like
The register captures risks from all sources: the pre-mortem, stakeholder mapping, architecture sessions, and the calendar overlay. Each risk has a specific description, a likelihood and impact assessment, a named owner (a specific individual, not a team), and a disposition (mitigate, monitor, or accept). Mitigated risks have specific mitigation plans with actions and timelines. The quality bar: the register differentiates. Not every risk is high-priority. The vital few risks requiring active mitigation are clearly distinguished from risks being monitored and risks being consciously accepted. The team can identify the top five risks without scanning the entire register.
The test
- Does every risk have a named individual owner?
- Can the team identify the top five risks without ambiguity?
- Do mitigated risks have specific actions with timelines, not just “monitor closely”?
- Are accepted risks documented as conscious decisions, not oversights?
The risk nobody put on the register documents the failure pattern when risks are surfaced but not structured into a register with owners and dispositions.
Component 3: The Calendar Overlay
What execution-grade looks like
The overlay maps every contributing function’s operational calendar against the program timeline. It includes blackout windows, capacity constraints (not just formal freezes), and external dependencies. The program timeline has been adjusted based on what the overlay revealed. The quality bar: the overlay is honest about capacity, not just blackouts. If Q4 is operationally intense for the organization, the overlay reflects reduced team availability even if no formal freeze exists. The overlay has produced specific changes to the program timeline. If it produced no changes, either the timeline was unusually well-aligned or the overlay was not taken seriously.
The test
- Are all contributing functions’ operational calendars represented?
- Does the overlay include capacity constraints, not just blackout windows?
- Has the program timeline been adjusted based on overlay findings?
- Are external dependencies mapped with specific dates and owners?
Component 4: The Principles and Guardrails One-Pager
What execution-grade looks like
The principles are specific enough to guide trade-off decisions during execution. Each principle answers: when the team faces a choice between this and speed (or cost), they choose this. Guardrails have enforcement mechanisms: named authorities who can invoke them and named authorities at a higher level who can override them. Trade-off rules provide starting criteria for common pressure scenarios. The quality bar: a reasonable person facing a specific trade-off decision during execution can read the principles and determine which option the principles support. If the principles are too abstract to guide real decisions, they are not specific enough. If the guardrails have no enforcement mechanism, they are aspirational.
The test
- Can the principles resolve a specific trade-off scenario that the team is likely to face?
- Does every guardrail have a named invoker and a named override authority?
- Have the guardrails been reviewed by the team that will operate under them?
- Are trade-off rules defined for the most common pressure scenarios (timeline vs. quality, scope vs. resources)?
Programs that failed with good plans documents cases where guardrails were absent and execution pressure produced compromises that undermined core objectives.
The Integrated Quality Bar
The Risk Landscape passes the overall quality benchmark when all four components meet their individual tests and the artifact as a whole meets one additional standard: the roadmap team, reading only the Risk Landscape, can identify the constraints the roadmap must accommodate and the commitments the roadmap must protect. Specifically, the roadmap team should be able to determine: which periods of the calendar are constrained (from the overlay), which failure modes the roadmap needs to mitigate through sequencing or buffer (from the pre-mortem and register), and which aspects of the plan cannot be compromised regardless of pressure (from the principles and guardrails). If the roadmap team enters roadmap sessions and discovers constraints or risks that the Risk Landscape should have surfaced, the artifact did not meet the quality bar. The downstream test is definitive. When the Risk Landscape feeds roadmap sessions and the team can build realistic timelines that account for operational constraints, carry appropriate buffers for identified risks, and protect the commitments the guardrails define, the artifact did its job. When the roadmap team is surprised by constraints that were knowable, the Risk Landscape was not execution-grade. The question is whether your Risk Landscape meets the quality bar required to give the roadmap team realistic constraints and protected commitments: or whether risk documentation exists without the rigor to shape what gets built.
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
Explore the foundations and common gaps: