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

The engagement was a supply chain transformation at a Fortune 500 retailer, spanning four workstreams, three business units, and eighteen months of prior planning work already completed by an internal team. The sponsor’s brief to the consulting team: “We have the strategy. We need help with execution planning.” The Landscape Brief told a different story. What follows is a section-by-section teardown of what the completed artifact contained, what the synthesis revealed, and where the findings changed the program’s direction before a single roadmap session began.

Goals & Success Criteria: Three Objectives, Three Different Programs

The intake produced nine stated goals across three business units and the corporate supply chain function. The Goals & Success Criteria table revealed the problem immediately: the three business unit leaders each described the primary objective differently. The VP of Retail Operations defined success as reducing distribution center cycle time by 40%. The VP of Merchandising defined success as improving product availability at shelf by 15%. The SVP of Supply Chain defined success as consolidating three regional logistics platforms into one. Each goal was documented in a different source: the operations goal came from a board presentation, the merchandising goal from a quarterly business review, and the consolidation goal from the supply chain strategy deck. All three were legitimate and funded. The problem was that optimizing for cycle time reduction and optimizing for platform consolidation required different sequencing, different resource allocation, and different measures of progress at each milestone. Each objective would have produced a different Workstream Charter with different success criteria and workstream boundaries. The Goals & Success Criteria table didn’t resolve this divergence; it made it visible: three goals, three sources, three owners, alignment status marked as Divergent. The narrative takeaway: “The initiative has nine stated goals. Six are aligned. Three core objectives are divergent across the three business units. Resolution is required before workstream scoping can proceed, because the priority hierarchy determines the sequencing of the first two deployment waves.” That sentence, delivered in the first board readout, shifted the first week of the engagement from execution planning to priority alignment. The sponsor’s assumption that the strategy was settled was correct at the stated level and incorrect at the operational level. Starting with what already existed revealed that what existed was three separate strategies wearing the same label.

Current-State Landscape: Duplication Disguised as Coverage

The Current-State Landscape mapped fourteen functional areas across the three business units and corporate. We expected to find fragmentation (i.e., functions working independently with gaps between them). Instead, the dominant pattern was duplication. Three business units had each built their own demand planning process. Each process used different data sources, different forecasting windows, and different vendor management criteria. At the corporate level, a fourth demand planning process existed that was supposed to consolidate the regional ones but in practice ran in parallel. The result was four versions of the same function, each producing outputs that conflicted with the others. The synthesis identified the consequence: the program architecture would need to address consolidation before integration. The original program plan assumed the three business units operated different functions that needed to be connected. The current-state mapping showed they operated the same function four times and needed to converge on one version before sequencing the deployment. That finding changed the program’s workstream structure. Instead of four parallel workstreams (one per business unit), the architecture session designed convergence workstreams organized by duplicated function, followed by a deployment workstream. The complete deliverable map for the engagement reflected this revised structure.

Artifact Inventory: The Roadmap Nobody Remembered

The intake collected twenty-three artifacts. The Artifact Inventory assessed each one and revealed a finding that would have been invisible in an unassessed collection. Buried in the SharePoint archive was a roadmap from fourteen months earlier, produced by the internal planning team during a previous attempt at the same transformation. That roadmap had been abandoned when the planning team was reassigned. It was never formally retired; it was simply forgotten. But it contained a constraint analysis that remained valid: a code freeze window in Q3 tied to a regulatory compliance deadline that eliminated six weeks from the deployment calendar. This is exactly the kind of hard constraint a Constraints Calendar is designed to identify and make visible to the entire planning team. The current program plan didn’t account for that constraint. Nobody on the current team had seen the old roadmap. The artifact inventory revealed it, rated its relevance as Medium (the roadmap’s sequencing was outdated but the constraint analysis was still operative), and flagged the code freeze as a hard constraint that needed to be incorporated into milestone planning. The narrative takeaway: “Twenty-three artifacts reviewed. Fifteen remain relevant. The critical finding is a code freeze constraint in Q3, documented in a prior roadmap that was abandoned but never superseded. This constraint eliminates the deployment window currently assumed in the program plan and requires re-sequencing of Waves 2 and 3.” Without the artifact inventory’s relevance assessment, the team would have discovered this constraint in month six, during execution, when the deployment window closed and the team had no contingency. The intake step exists to prevent exactly this kind of surprise, but only when it produces an assessed inventory rather than a document folder.

Scope Boundaries: The Gray Area That Changed the Deployment Strategy

The scope table listed forty-two items in scope, twelve out of scope, and seven in the gray area. One gray-area item changed the program’s deployment strategy. The item: “Store-level training for the new inventory management system.” The current assumption was that training was the responsibility of the HR function and was therefore out of the supply chain transformation’s scope. The HR function’s assumption was that training content would be developed by the program team and handed off to HR for delivery. Neither assumption had been documented. Neither had been agreed to by both parties. The gray-area table captured the item, the conflicting assumptions, and assigned the Director of Program Management as the resolution owner with a deadline of Week 3. The resolution conversation revealed that HR had no budget allocated for training delivery and had assumed the program would fund it. The program had no budget for training content development and had assumed HR would handle the entire training function. The narrative takeaway: “Scope is bounded by forty-two in-scope items and twelve explicit exclusions. Seven gray areas require resolution. The highest-risk item is store-level training, where the program team and HR hold conflicting assumptions about ownership and funding. Resolution is required by Week 3 because the training timeline gates the Wave 1 deployment schedule.” The resolution added a training workstream to the program, reallocated budget from the contingency reserve, and pushed the Wave 1 deployment date by two weeks. That two-week adjustment, made during planning, prevented a deployment to 200 stores with no training infrastructure. Programs that failed with good plans frequently trace the failure to exactly this kind of unresolved gray area: an item that both parties assumed the other owned, discovered during execution when the cost of resolution was measured in weeks of delay rather than hours of conversation.

What the Teardown Reveals

Across all four sections, the pattern is consistent: the Landscape Brief changed the program’s direction before planning began. The goals section revealed a priority divergence that would have appeared during execution as conflicting workstream objectives. The current-state section revealed duplication where the team expected fragmentation, reversing the program architecture. The artifact inventory found a constraint hidden in a forgotten document. The scope section identified an ownership gap that would have derailed the first deployment wave. None of these findings were visible from the strategy deck, the charter, or the sponsor’s brief. All of them were visible from the structured intake that the Landscape Brief requires. The practical test is whether your planning process compiles, assesses, and synthesizes the information your organization already has, or whether it starts from scratch and misses the signals that would have changed the program’s direction.


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

Explore the foundations and common gaps: