The most basic roadmap answers the 4 canonical questions
- Why
- What
- How
- When
I also found another good snippet from the following post
It outlines in a little more detail the key components of a roadmap document especially as it relates to an Information Technology applications roadmap.
- Purpose of this Document - why write the doc
- Stakeholder Chart - whose needs are being met with the solution
- Signoff Chart - timestamp and id of person who signs off.
- High Level Platform Capabilities - the solution capabilities demanded by the business
- Business Drivers for the Capabilities - the list of business programs or business teams that will use the system
- Capability Demand - which business are asking for which capabilities. An interesting grid.
- Technical Interdependencies - what other systems rely on this solution. What other systems does this solution rely on?
- Enterprise Architecture Concerns - what agreements have been made with EA to get alignment of the solution to EA standards.
- Architectural Context - one or more diagrams showing how the solution platform will evolve over time.
- Methodology - how this document and concensus was created. What meetings were held. Who was in the room. (it matters)
- Roadmap schedule - what timelines everything thinks are reasonable for delivering the needs to different business customers
- System Quality Attributes - what quality attributes will be stressed in each of the iterations.
- Alternatives considered - what alternatives to this roadmap were considered and why this one was chosen.
- Roadmap Risks - what could go wrong and who is assigned to watch for it
Platform Historical Narrative - previous decisions and narrative so that we can always answer the question: how did we ever get in a bind like this?
