Description: A Roadmap shows a path from current state to a desired future state. The roadmap method builds consensus on vision, goals, milestones, and deliverables. The roadmap can be used to rally a community around a plan for action as well as manage expectations for outcomes over time.

A roadmap will typically show:

  • A long-term vision

  • A high-level sequence of milestones (not necessarily with actual dates)

  • High-level goals and deliverables/outcomes for each milestone (or in each phase)

  • A high-level level sense of dependencies (early deliverables are prioritized because they support later deliverables)

A roadmap is typically informed by other things that don’t necessarily appear in the roadmap; see Method section.


  • Build consensus around a problem and path to a solution

  • Getting a list of actions that need to be done to get to the solution

  • Getting many points of view on a problem

  • Be able to guide more specific project planning, work planning, etc.


Typical scenarios include:

  • Strategic planning

    • Audience: Executive sponsors/champions, business stakeholders, IT directors; potentially also affected users

    • Scope: A domain across time, typically spanning multiple years

    • Goals and outcomes: Create shared vision, set long-term goals and expectations, and agree on a sequence of high-level outcomes; provide enough context for more specific project planning or work planning; create transparency

  • Initiative-level planning

    • Audience: Initiative sponsors, business stakeholders; potentially also affected users

    • Scope: Initiative

    • Goals and outcomes: Create shared vision, set long-term goals and expectations, and agree on a sequence of project outcomes; provide enough context for more specific project planning or work planning; create transparency


Roles: Initiation driven by business need, roadmap development process lead by architect with involvement of SME for technology/trend guidance and senior leadership  for vision/strategy guidance.


  1. Identify a problem statement

    1. Gather feedback to identify the problem

  2. Create an early vision/strawman for the roadmap

  3. Identify and engage stakeholders

  4. Refine the roadmap

    1. A roadmap can show dependencies in a sequence, without a strict time dimension (see the UW-Madison “fishbone” example)

    1. Evolve the vision

    2. Identify the big ideas

    3. Identify principles

    4. Identify outcomes, milestones, large chunks of work

    5. Sequence the outcomes

  5. Summarize the roadmap in a communication piece

  6. Publish, promote, communicate the roadmap; rally people around the roadmap

  7. Establish roadmap document update interval and regularly re-visit roadmap to keep current

Artifacts: Development of a roadmap document.


Vision and Roadmapping should be used to support shared understanding of a path from current to future state, typically over an extended period of time.  It’s extremely important to gain buy-in and shared understanding of the future state with all sponsors and stakeholders.  The end result of the roadmap is used as an anchor to support shared understanding and goal setting for all programs, initiatives and projects that are developed to support the roadmap.

Note that communication must be tailored to the audience - senior leadership will be interested in overview-level information with sequence and dependency details that can make use of colors, shapes, and other techniques for emphasis.  Technical audiences may start with the same high level overview but will be well served by having more detailed, likely textual, backing documentation that may not be part of the actual roadmap.


Beware of creating unrealistic expectations by assigning firm dates to far future roadmap events.

Related Methods

This diagram communicates the larger vision. Other diagrams and tools can be used to complement the information in the roadmap and how the decisions were made.

  • Investment Value Matrix - identify areas where the organization budget should be invested

  • TIME Models - evaluate what components in the organization need to be contained vs eliminated vs invested in

  • Capability Maps - focus on what the organization should be doing as far as processes that provide value

  • Dot Diagrams - identify what services / components are high value and their dependencies


Want to help with this page? Please see the Method Contributor Guide.

Stewards for this page:

  • J.J. Du Chateau, University of Wisconsin - Madison

  • Rick Tuthill, University of Massachusetts - Amherst

Other contributors:

  • Robert Guthrie, Washington University - St. Louis

  • Paul Schurr, University of Washington

  • Robert Dein, Miami University of Ohio

  • Piet Niederhausen, University of Washington

  • Chris Eagle, University of Michigan

  • Jason Meyers, University of Washington

  • José Cedeño, Oregon State University