The first two articles in this series covered what a Landscape Brief is and what its four sections contain. This article covers what happens when programs skip it. The patterns are consistent enough to categorize: inherited decisions that nobody examined, constraints that surface during execution instead of planning, and scope that expands without a documented baseline to push back against. Each pattern traces back to one of the open questions the Landscape Brief is designed to answer. When those questions go unanswered, the consequences show up later, in more expensive settings, under more pressure.
The Program That Inherited Decisions Nobody Examined
A retail organization launched a store systems modernization program spanning five functions. The program team started planning in week one: workstream definitions, milestone sequences, dependency mapping. The planning moved fast because a prior team had already done foundational work six months earlier, including a charter, a preliminary roadmap, and a set of scope agreements between functions. The program team treated those documents as settled. They built their milestones on top of the prior roadmap’s sequencing (the kind of inherited sequencing a Workstream Roadmap would have pressure-tested). They used the prior charter’s scope boundaries as their own and inherited the prior team’s assumption that the supply chain function was out of scope. By week ten, the supply chain assumption collapsed. The deployment sequence required inventory system changes that touched supply chain directly. The prior team had excluded supply chain because, at the time, the program was framed as a store operations initiative. Six months later, the program’s scope had expanded, but nobody had revisited the prior team’s boundary decision. The exclusion was embedded in the inherited documents, and nobody had asked whether it was still valid. The replanning cost three weeks of collaborative time and required re-sequencing two workstreams. The constraint was visible in the prior artifacts. An artifact inventory with relevance assessments would have flagged it: the prior charter’s scope boundaries were based on a narrower program definition that no longer applied. The intake step exists to identify exactly this kind of inherited assumption before the team builds on top of it. The open question that went unanswered: What artifacts already exist, and are they still valid?
The Program That Hit a Constraint Nobody Compiled
A life sciences company ran a post-merger integration program across four business units. The program had executive sponsorship, a dedicated PMO, and a twelve-month timeline. The planning team built a roadmap with quarterly milestones and cross-functional dependencies mapped between all four units. The roadmap placed a critical systems integration milestone in November. What the planning team didn’t compile was the constraint inventory from each business unit. One unit had a regulatory submission window in October that consumed its entire IT capacity for six weeks. Another unit had a manufacturing validation cycle that blocked any system changes from mid-October through December. Both constraints were documented in functional calendars and operational memos. Neither was compiled into a single view the planning team could reference. The November milestone was impossible before anyone identified it as such. The planning team discovered the conflicts in September, two months before the milestone, when the workstream leads began flagging resource shortfalls. The team had to push the milestone to February, which cascaded into downstream dependencies and extended the overall program timeline by ten weeks. A Constraints Calendar that distinguished between hard stops and negotiable preferences would have caught this during planning. The November milestone would never have been set because the constraints were visible in the functional documents; nobody compiled them. Programs that failed with good plans frequently share this characteristic: the information existed, but it lived in functional silos rather than in a single assessed inventory. The open question that went unanswered: What constraints are already known, and which are hard stops versus assumptions?
The Program Where Scope Expanded Without a Baseline
A financial services organization launched a cross-functional process standardization program covering operations, compliance, and technology. The program began with a clear mandate: standardize five core processes across three regional operating units. By month four, the program was working on eight processes across four operating units. The expansion happened incrementally. A regional leader asked the program team to include a sixth process because it was adjacent. The compliance function requested that a fourth region be added because it had similar issues. Each addition was reasonable in isolation. None was evaluated against a documented scope baseline because no baseline existed. The program had a charter, but the charter stated the scope in broad terms: “standardize core operational processes across the organization.” That language was elastic enough to absorb every request. Without an explicit in-scope/out-of-scope table and a gray areas register with owners and deadlines, the program had no documented boundary to reference when new requests arrived. The consequences compounded. The team that was resourced for five processes across three regions was now responsible for eight processes across four regions, with the same timeline and the same budget. The team absorbed the additional scope by working longer hours and compressing testing cycles, which produced quality issues that emerged during the first regional rollout. A scope boundaries section with explicit exclusions and a gray areas table would have given the program lead a documented reference point. Each new request could have been evaluated against the baseline: is this in scope, out of scope, or in the gray area? If it’s a gray area item, who owns the decision and by when? Without that structure, scope decisions were made informally, and the cumulative effect was a program that was materially larger than what the team was resourced to deliver. Starting with what already exists includes defining what the program is responsible for, not what it inherited. The open question that went unanswered: What coordination infrastructure exists to sustain alignment? In this case, the missing infrastructure was the scope governance mechanism itself.
The Pattern Across All Three
Each program had planning, leadership support, and competent teams. What each lacked was the foundational inventory that the Landscape Brief produces: a compiled, assessed, explicit record of goals, current state, prior work, and boundaries. The Landscape Brief does not prevent all program failures. It prevents the category of failure that comes from building on a foundation the team has not examined. The four sections (i.e., Goals and Success Criteria, Current-State Landscape, Artifact Inventory, and Scope Boundaries) exist because each one answers a question that, left unanswered, produces a predictable failure pattern. The practical test is whether your program has examined its inherited foundation, or whether you’re building downstream on assumptions that nobody has verified.
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