The request is always reasonable: the VP calls and says we need a roadmap, the board meeting is in six weeks, the program has been running for three months with no documented plan, and can you help us build one? The request to jump straight to roadmapping (Step 5 in the nine-step methodology) is one of the most common patterns the firm encounters, and it produces a predictable set of failures.
A Roadmap Requires Validated Inputs
A roadmap is a sequencing document: what happens in what order, owned by whom, with what dependencies. To build one well, the consulting team needs four categories of information that Steps 1 through 4 produce:
- Current state (Step 1: Intake). Without the intake baseline, the roadmap is built on assumptions about the current state that nobody has validated. The team assumes prior decisions are still in effect and existing timelines are accurate; some of those assumptions are wrong, and nobody discovers which ones until execution begins. Intake changes everything about the quality of what follows.
- Stakeholder landscape (Step 2: Mapping). Without the perspective map, the roadmap does not account for constraints individual leaders are aware of but have not shared in a group setting. The VP of Medical Affairs knows her team is at capacity through the congress cycle, but that constraint does not surface in a roadmapping workshop because nobody asked about it in a one-on-one. Stakeholder mapping goes beyond the org chart to surface these hidden constraints.
- Program structure (Step 3: Architecture). Without clear ownership boundaries between workstreams, the roadmap sequences activities that overlap. Two workstreams plan work in the same area because nobody defined where one scope ends and the other begins; the overlap becomes a turf conflict during execution.
- Risks and constraints (Step 4: Pre-Mortem). Without a risk register and constraints calendar, the roadmap treats dependencies as stable and timelines as achievable. Designing for failure before the roadmap is built catches the integration vendor that has missed its last three deadlines, the shared testing resource that gets double-booked, and the regulatory submission blackout in Q4 that nobody compiled into a cross-functional view.
The roadmap built without Steps 1 through 4 looks credible in the room where it was built; the milestones are logical and the timeline fits the board meeting deadline. Then execution starts, and the constraints and conflicts that the earlier steps would have surfaced begin appearing as surprises, triggering emergency meetings and scope negotiations. Within sixty days, the team is managing exceptions rather than executing a plan; the roadmap becomes a record of what they thought was true six weeks ago, and the program enters a re-planning cycle that consumes the rest of the quarter. The four steps before roadmapping were added because organizations that jumped straight to roadmapping kept producing plans that collapsed during execution. The reasons were the same: unvalidated current state, unsurfaced stakeholder constraints, undefined program structure, and unidentified risks. Understanding how the steps connect explains why skipping any of them creates downstream failures. Steps 1 through 4 consume roughly five weeks in a standard planning engagement. That feels like a lot when the VP needs a roadmap for a board meeting, but the tradeoff is between a roadmap that survives contact with the organization and one that requires rebuilding within sixty days.
