Roadmap sessions are where the energy shifts from analysis to construction. The first four steps of a cross-functional planning engagement (gathering information, surfacing perspectives, defining structure, and identifying risks) produce the raw material; step five is where the team builds the plan by working through scope, milestones, dependencies, and sequencing in real time.
We Arrive with Material the Team Has Already Shaped
We arrive at step five with material from the previous four steps: a program architecture, a risk register from the pre-mortem exercise, a constraints calendar that saved the launch by revealing execution windows no single function had identified, and a stakeholder perspective map. Before the first session, we prepare strawman inputs for each workstream: draft scope documents that are intentionally incomplete, roughly 30% of the content structured enough to give the workstream lead a starting point and open enough that the room fills in the remaining 70%.
A Repeatable Sequence Keeps Each Session Focused
Each roadmap session follows a repeatable sequence. We present the strawman scope for one workstream, and the team spends a few minutes in independent writing, capturing what’s missing and what needs to change. The room then works through the markup in round-robin fashion.
After the scope is revised, the team moves to milestone sequencing. We present candidate milestones and the team sequences them based on dependencies, capacity, and constraints. Each milestone gets a rough time window, a set of prerequisites, and a list of dependencies on other workstreams.
Dependency mapping is the hardest part, because it forces the team to name the specific handoffs, shared resources, and integration points that connect one workstream to others. Dependencies are the primary cause of failure in cross-functional programs (a market access workstream waiting on a label that regulatory hasn’t finalized, a patient services hub build that can’t start until IT configures the underlying systems) and this is the session where they become visible and specific rather than abstract and assumed.
The Conflict Log Gives Good Ideas a Home Outside the Roadmap
Every roadmap session generates ideas that don’t belong in the roadmap. A workstream lead proposes an adjacent initiative that would expand the scope; a VP suggests a parallel effort that overlaps with another workstream. The conflict log captures scope additions, contested priorities, and unresolved questions. Every item gets acknowledged and recorded, but none of them enter the roadmap unless the team explicitly decides to include them.
The conflict log prevents scope creep by giving ideas a place to land that’s separate from the roadmap itself. It also creates a record of decisions about what the program chose not to do, which proves valuable in steering committee conversations where sponsors ask why something was excluded.
The Integrated View Reveals What Individual Workstreams Conceal
The most consequential moment in step five is the session where individual workstream roadmaps are combined into an integrated view that puts the whole program on one page. The integrated roadmap shows every workstream’s milestones on a shared timeline, with dependencies mapped as connections between workstreams and constraints overlaid as blocked windows. Several things become immediately obvious:
- Where workstreams run in parallel versus in sequence
- Where dependencies create critical path bottlenecks
- Where constraints compress available execution windows
- Where two workstreams compete for the same shared resource
The program finally makes sense as an integrated whole, but the integrated view also reveals complexity that individual workstream views concealed. Our job is to walk through the view systematically, identify the dependency chains that present the highest risk, and focus the team’s attention on those specific intersections rather than the overwhelming whole.
By the end of step five, the team has revised workstream scopes, a milestone sequence with time windows and dependencies, a dependency map, and an integrated roadmap visual. These artifacts belong to the team because the team built them; a plan that a team constructs together is a plan they’ll actually defend and execute. The next step is designing the lightest-weight governance that works to keep that plan on track.
