This article is part of the OpsCorp method library. To see where your program stands across all nine planning dimensions, take the scorecard.

The Landscape Brief answers one board question: “What did we find?” But the answer has structure. It’s organized around four sections, each compiling a different dimension of the program’s inherited context. The sections build on each other: goals define what the program is trying to achieve, the current-state landscape shows where things stand, the artifact inventory assesses what prior work is still valid, and the scope boundaries establish what is in play and what is not. This article walks through each section: what it contains, how we build it, and what separates a useful version from a placeholder.

What Goes into Goals and Success Criteria

The Goals and Success Criteria section compiles every stated goal for the program into a single table. Each row captures five fields: the stated goal, the source document it came from, the stakeholder who owns it, its priority level, and its alignment status across stakeholders. The alignment status is the field that does the most work. When the VP of Technology says the program’s primary objective is platform modernization and the VP of Operations says it’s process standardization, both are documented, both are attributed, and the divergence is visible in one view. The section doesn’t resolve the conflict; it makes the conflict impossible to ignore. The quality bar for this section: goals are specific enough to evaluate, sources are documented, and alignment gaps between stakeholders are explicit. A goal like “improve cross-functional coordination” is too vague to evaluate. A goal like “reduce the time between identifying a cross-functional dependency and resolving it from three weeks to five business days” is specific enough that two people could independently assess whether the program achieved it. These fields map directly to what the Workstream Charter later operationalizes into workstream-level ownership and accountability. The synthesis question we answer: is the dominant pattern fragmentation (pieces exist but aren’t connected), duplication (multiple teams are building the same thing), or misalignment? Fragmentation means the pieces need integration, not invention. Duplication means the program needs consolidation and a single owner. Misalignment means the program needs goal reconciliation before anything else. That diagnosis shapes the entire program architecture. A fragmented landscape calls for coordination mechanisms. A duplicated landscape calls for scope rationalization. A misaligned landscape calls for goal reconciliation before anything else. Our job in this section is to name the dominant pattern so the planning team knows what kind of problem they’re solving. The quality bar: the section covers all relevant functional areas and distinguishes between gaps, overlaps, and conflicts rather than treating all findings as a single undifferentiated list. When the team can see the complete map of what gets built at each step, the current-state landscape is the foundation everything else sits on.

What Makes an Artifact Inventory Different from a Document Folder

Most organizations have a folder somewhere with prior planning documents in it. A SharePoint site, a Google Drive, a Confluence space. The folder contains everything, organized by date or by whoever uploaded it. The artifact inventory is a different thing entirely. The artifact inventory is a scored catalog. Each row captures an artifact name, its type (roadmap, charter, assessment, governance document), its source (which team or person produced it), its date, its relevance rating, and its key takeaway. The relevance rating is the critical field: it forces an assessment of whether each artifact is still current, still operative, and consistent with other artifacts in the inventory. Two traps from the book chapter apply directly here. The archaeology trap is the tendency to collect everything, building a comprehensive archive that satisfies completeness but produces nothing actionable. The intake step is designed to prevent this: we need enough to understand the inherited context, not a museum of prior work. The recency trap is the assumption that the most recent document is the most accurate. Sometimes the most recent deck was a rushed executive update that papered over real constraints. The artifact inventory forces the question: who created this, for what purpose, and is it still the operative version? The synthesis question: what prior work is still valid, and what assumptions from prior work have been overtaken by events? The answer tells the planning team which pieces of the inherited foundation they can build on and which they need to revisit. The quality bar: the inventory is comprehensive enough to cover major prior work, each artifact is assessed for relevance (scored, not filed), and contradictory or duplicative artifacts are flagged. A folder tells the team what was created. An artifact inventory tells the team what is still true.

How Scope Boundaries Prevent the Gray Areas That Derail Programs

Scope boundaries are the section that pays for itself during execution. The section captures two tables: an in-scope/out-of-scope table that draws explicit lines, and a gray areas table that documents items where the boundary isn’t yet decided. The in-scope/out-of-scope table is straightforward. Each row names an item and states whether it’s inside or outside the program’s scope. The value comes from the explicit exclusions. When a VP asks in week eight why the program isn’t addressing a particular capability, the team can point to a documented boundary rather than relitigating scope in real time. The gray areas table is where the section earns its keep. Each row captures the item, the current assumption about whether it’s in or out, the owner responsible for resolving it, and the resolution deadline. Gray areas without owners sit unresolved. Gray areas without deadlines drift until they collide with the roadmap. The quality bar: every gray area has an owner and a deadline, explicit exclusions are documented, and there’s no ambiguity about what the program is and isn’t responsible for. The synthesis question: where is scope likely to creep, and which gray areas need resolution before roadmap sessions? The answer shapes how we sequence the next steps. If gray areas are gating the roadmap, they need resolution before the team can build milestone sequences. If the gray areas are peripheral, they can be resolved in parallel. The Constraints Calendar captures these timing dependencies so the planning team can sequence resolution alongside other planning activities. The practical test is whether your program has documented these four sections thoroughly enough that planning decisions during execution are fast, defensible, and traceable to what the team found at the start.


Go Deeper: The Landscape Brief

This article covers one dimension of the Landscape Brief, the first of nine artifacts in the Planning & Roadmapping method. The Landscape Brief answers the board question: “What did we find?” Explore the full Landscape Brief → Want us to build this with you? Book a consultation →


Keep Reading

Ready to close specific gaps in your Landscape Brief? These articles show you how:

  • You Have a Goals List but Not a Goals & Success Criteria Table
  • Scope Boundaries That Actually Hold
  • From Artifact Dump to Artifact Inventory