Roadmap: Sequencing Change as a Journey
The roadmap in Agile Change Management is the visible plan that takes people from their current state to a defined future state in small, ordered increments. It is not a project Gantt chart; it is a communication and commitment tool that shows what changes, for whom, and in what order. Candidates must understand the roadmap's components: the vision or end goal, the change increments (often expressed as releases or waves), the dependencies between them, and the milestones at which adoption is checked.
Three concepts carry most exam weight. First, incremental delivery: change is broken into chunks small enough for people to absorb and for the change team to learn from. Second, sequencing by readiness and dependency: increments are ordered so that enabling changes (skills, tools, communications) land before the changes that depend on them. Third, the roadmap as a living artefact: it is reviewed and re-planned as feedback arrives, rather than fixed at the outset.
Common traps:
- Confusing the roadmap with the project schedule. The roadmap describes change and adoption; the schedule describes tasks and resources.
- Assuming a roadmap must be complete before work starts. It should be detailed for the near term and directional beyond that.
- Forgetting stakeholder communication: a roadmap that nobody sees delivers no benefit.
Rule of thumb: if an increment cannot be described in one sentence from the perspective of the people affected ("by this point, managers will be able to..."), it is too big or too vague to schedule.
Worked example: A finance team is moving to a new expenses system. Increment 1 delivers the vision and trains team leads; Increment 2 switches one department over and gathers feedback; Increment 3 rolls out to the rest, informed by Increment 2's lessons. Each increment has a clear adoption milestone, and the later increments are refined only after the earlier feedback arrives.