Describe the friction first
Begin with the places where work slows down: repeated approvals, spreadsheets that disagree, information trapped in inboxes, or reports that take days to prepare. Speak to the people carrying out these tasks. Capture the problem, its frequency, and its effect before describing a software solution.
Choose a small set of priorities
Compare improvements using business value, effort, dependencies, and the ability of the organisation to adopt the change. A high-profile project is not automatically the best first project. An improvement to a shared data source may make several later changes easier to deliver.
Make each phase useful on its own
Give every phase a clear outcome, owner, and acceptance criteria. For example, replacing an email approval chain should result in a process people can complete and managers can track. Avoid phases that deliver only infrastructure without explaining which operational result that infrastructure enables.
Plan for people and existing work
Include training, data preparation, support, and the time needed to run old and new processes during transition. Ask who will maintain the system after launch. A technically complete system may still fail to gain adoption if responsibilities are unclear or the new process makes everyday tasks harder.
Review and adjust
At the end of each phase, review the intended outcome and the actual result. Keep a short record of what changed, what remains difficult, and what should be done next. The roadmap is a decision tool, not a promise to implement every initial idea. Revise it when priorities or evidence change.