Most people look at a methodology and see a list, treating it like a checklist: complete each step, move to the next. The steps are valuable because of what each one feeds to the next; the outputs of each step become required inputs for the steps that follow. Understanding those dependencies is the difference between executing a methodology and understanding why it works, as the intake-to-handoff full journey illustrates.
The Baseline Sets the Conversation
Intake and document audit produces a structured baseline of existing charters, roadmaps, and governance documents with gaps identified. That baseline shapes the stakeholder interviews that follow. When the consulting team enters the one-on-ones, they’ve already seen where documents agree and contradict; they can probe specific gaps: “The roadmap front-loads technology work, but the charter describes this as operations-led: how does the team think about that tension?” Without the baseline, interviews become a broader, shallower discovery exercise less likely to surface the tensions that matter.
Stakeholder Constraints Shape Architecture
Stakeholder mapping produces a perspective map: how each stakeholder sees the program and where views conflict. That map is a critical input to architecture. When one-on-ones reveal that two VPs have different assumptions about which function owns the pilot rollout, that conflict becomes a design constraint; the workstream structure needs to resolve it explicitly by assigning ownership or accommodate it with a shared governance mechanism. Programs that skip this step build architectures based on org charts and formal documentation: structures that look logical on paper and fail in practice because they do not account for informal power dynamics and competing assumptions.
Architecture Makes Risks Visible
Architecture produces workstream boundaries and dependency maps. That architecture is the prerequisite for the pre-mortem. Without architecture, failure modes stay abstract: “we might not have enough resources.” With architecture visible, failure modes become structural: “Workstream A and C both depend on the same integration team during the same two-week window” or “the dependency between technology and operations has no owner.” The pre-mortem stress-tests the architecture; without it, the pre-mortem produces risks too general to act on.
Risks Become Sequencing Inputs
The pre-mortem produces a risk register and a constraints calendar mapping blackout windows and seasonal peaks. Both become direct inputs to roadmap sessions. The risk register tells the team which dependencies are fragile: a high-risk dependency gets sequenced with buffer time, and a milestone depending on an unresolved vendor commitment gets a go/no-go gate. The constraints calendar tells the team when the organization cannot execute; if Q4 is closed for a code freeze and holiday peak, the roadmap does not schedule deployments in Q4. Programs that build roadmaps without these inputs produce plans that look clean but collapse when they encounter the constraints earlier steps would have surfaced.
The Roadmap Defines What Governance Supports
Roadmap sessions, with milestones sequenced across workstreams and dependencies mapped, produce the primary input to operating model design. Governance decisions cannot be made in the abstract: a roadmap with four active workstreams and twelve cross-workstream dependencies needs different governance than a roadmap with two independent workstreams. The cadence of syncs and the escalation triggers all derive from the roadmap’s complexity and the risks from the pre-mortem. When the operating model is designed before the roadmap exists, it defaults to generic governance: weekly status meetings and monthly steering committees: defaults that may not match the program’s coordination needs. Designing the operating model after the roadmap means governance is fitted to the work.
Change Management Draws on Multiple Steps
Change management breaks the linear chain; it draws inputs from stakeholder mapping, architecture, and roadmapping at the same time:
- From stakeholder mapping and architecture, it gets the perspective map and the structural view: who is supportive or skeptical and where organizational impact is concentrated.
- From the roadmap, it gets the sequence: when changes land and which groups are affected at each stage.
Change management designed without these inputs defaults to a generic communications plan and training schedule. Designed with them, it’s targeted: it knows which stakeholders need which messages at which points in the rollout.
