01
Decision one: define the phases by outcome
Start by naming each phase for the result it leaves behind, not the activity inside it. Take a regional service firm that wants to modernize its client onboarding. Phase one, Clarify, ends with a single documented onboarding path. Phase two, Simplify, ends with duplicate forms removed. Phase three, Automate, ends with approved steps handled by software. Outcome names let executives judge progress without reading task lists, and they stop phases from blurring together. Limit the roadmap to three or four phases so every stakeholder can recite the sequence from memory after one meeting.
02
Decision two: set an exit test for each phase
Each phase needs a short test that decides whether the next one may begin. In the onboarding example, Clarify might close only when two team leads independently describe the same path and a new hire can follow it unaided. Simplify closes when the team agrees which forms are retired. Write tests as observable statements, assign one owner to confirm them and record the date. This prevents the common drift where phases overlap because nobody can say whether the earlier work is finished, and it gives leadership a natural moment to pause, adjust scope or stop.
03
Decision three: schedule review and adjustment
Finish the roadmap by placing review meetings between phases, with a fixed agenda: what was learned, what changed in the plan and what the next phase needs. In the example, a thirty-minute review after Simplify might reveal that one regional office uses a different intake process, prompting a small added step before automation. Keep a running change log so later readers understand why the plan moved. Treat the roadmap as a living document with version numbers, and share each revision with the same group, so adjustments feel deliberate rather than like failure.