A Description and Example
of a
Roadmap Framework
Warren Weinmeyer
TABLE OF CONTENTS
1
INTRODUCTION .............................................................................................................. 4
1.1
Background ----------------------------------------------------------------------------------------------- 4
1.2
Creating a Roadmap Framework --------------------------------------------------------------------- 5
1.3
Implementing a Roadmap Framework ------------------------------------------------------------- 6
2
ROADMAP STAKEHOLDERS AND CONCERNS ................................................................... 6
3
STATES OF APPROVAL FOR AN ACTIVITY ......................................................................... 8
4
THE ROADMAP FRAMEWORK ......................................................................................... 9
4.1
5
6
7
8
Roadmap Overview ------------------------------------------------------------------------------------- 9
TIER 1 – INVESTMENT ROADMAP .................................................................................. 10
5.1
Purpose --------------------------------------------------------------------------------------------------- 11
5.2
Stakeholders --------------------------------------------------------------------------------------------- 11
5.3
Concerns Addressed ----------------------------------------------------------------------------------- 11
5.4
Context and Inputs ------------------------------------------------------------------------------------- 11
5.5
Description ----------------------------------------------------------------------------------------------- 11
TIER 2 – TRANSFORMATION ROADMAP ........................................................................ 12
6.1
Purpose --------------------------------------------------------------------------------------------------- 14
6.2
Stakeholders --------------------------------------------------------------------------------------------- 14
6.3
Concerns Addressed ----------------------------------------------------------------------------------- 14
6.4
Context and Inputs ------------------------------------------------------------------------------------- 14
6.5
Description ----------------------------------------------------------------------------------------------- 14
TIER 3 – STRATEGY REALIZATION ROADMAP (OPTIONAL) .............................................. 16
7.1
Purpose --------------------------------------------------------------------------------------------------- 17
7.2
Stakeholders --------------------------------------------------------------------------------------------- 17
7.3
Concerns Addressed ----------------------------------------------------------------------------------- 17
7.4
Context and Inputs ------------------------------------------------------------------------------------- 17
7.5
Description ----------------------------------------------------------------------------------------------- 17
TIER 4 – PORTFOLIO DELIVERY ROADMAP ..................................................................... 18
8.1
Purpose --------------------------------------------------------------------------------------------------- 19
8.2
Stakeholders --------------------------------------------------------------------------------------------- 19
8.3
Concerns Addressed ----------------------------------------------------------------------------------- 19
8.4
Context and Inputs ------------------------------------------------------------------------------------- 19
Roadmap Framework
8.5
9
Description ----------------------------------------------------------------------------------------------- 19
TIER 5 – SERVICE ENHANCEMENT ROADMAP (OPTIONAL) ............................................. 21
9.1
Purpose --------------------------------------------------------------------------------------------------- 22
9.2
Stakeholders/Concerns-------------------------------------------------------------------------------- 22
9.3
Concerns Addressed ----------------------------------------------------------------------------------- 22
9.4
Context and Inputs ------------------------------------------------------------------------------------- 22
9.5
Description ----------------------------------------------------------------------------------------------- 22
Page 3 of 22
Roadmap Framework
1
1.1
INTRODUCTION
Background
A roadmap framework is a straight-forward concept, based on a couple of fundamental premises.
The first premise is that an idea proceeds from an initial conception through various stages of refinement,
valuation, realization and assessment in order to effect some sort of change in the organization. Various best
practices have been developed for all these stages, which most organizations apply in some form or degree.
Stringing these best practices into a sequence to cover all the stages an idea passes through is sometimes
referred to as the “ideation-to-realization” lifecycle, or some similar nomenclature.
The following diagram provides a representative example of an ideation-to-realization lifecycle, showing the
best practices (the tri-colour ring) along with the types of activities (the inner, pale yellow ring) that typically
occur under the umbrella of these best practices.
Courtesy, Warren Weinmeyer
All rights reserved
The second premise upon which the concept of a roadmap framework is founded is that different
stakeholders are involved at different stages of the ideation-to-realization lifecycle, and that these different
stakeholders are interested in different views of information, in correlation with where they participate in the
lifecycle. For example, the type of roadmap a transformation planner uses looks different and contains
different information than the type of roadmap a project manager uses.
Page 4 of 22
Roadmap Framework
A roadmap framework is a set of roadmaps that cater to the differing information needs of stakeholders,
while maintaining an overall coherence between each other such that one can trace an idea that may be
represented in different forms; for example, as a Capital Investment on an Investment Roadmap, a Capability
Enhancement on a Strategic Roadmap, or a Work Package on a Transformation Roadmap.
1.2
Creating a Roadmap Framework
Creating roadmaps is fundamental to any planning activity. However, different stakeholders look for different
information and at different stages of the Opportunity-to-Value_Realization (also sometimes called the
Ideation-to-Realization) lifecycle. So, any enterprise typically maintains a variety of roadmaps for different
audiences, and at different levels of scope or detail, in order to synchronize and harmonize various initiatives.
Ironically, it is often the case that the roadmaps, as documents in their own right, are not harmonized with
each other in terms of standardizing on look-and-feel, content, and stakeholders; additionally, there typically
are no conceptual linkages between roadmaps to support an ability to navigate seamlessly between higherlevel roadmaps and lower-level roadmaps. The result is often that roadmaps are difficult to bring together in a
consistent and coherent view of the enterprise plans.
A Roadmap Framework attempts to address these issues by creating re-usable templates of roadmaps that are
standardized in content and scope/detail and also conceptually relate to each other in a robust manner so
that, put together, they provide traceability of planning activities from strategy to delivery. So a Roadmap
framework simultaneously improves productivity (via pre-defined templates) and quality (by defining
relationships and linkages between each template). The framework does this by leveraging a few concepts:
 Stakeholder Concerns are the important questions, like cost or interdependency, which the intended
audience wants the roadmap to answer. Every roadmap is created for a specific set of Stakeholders.
 Roadmap Continuum is the concept that roadmaps can be created anywhere along a continuum of
levels of strategic scope, abstraction, or granularity. As a general rule, the “higher” levels of the
altitude continuum (think of a “50,000-foot” view vs a “5,000-foot” view), have a wider scope, are less
concrete (i.e., less prescriptive) and more strategic than the “lower” levels, which get increasingly
focused, detailed and tactical.
 Altitude or Tier is a specific, defined place (i.e., a conceptual “height”) within the roadmap continuum
that indicate the characteristics (i.e. purpose, audience and content) of a roadmap that is created at
that altitude/tier. Roadmaps at the same Tier have a consistent look-and-feel.
The following diagram illustrates the role of these concepts in a simple example roadmap framework:
Higher-level:
 More Strategic
 More Summarized
Roadmap
Continuum
Tier 1: Strategic
Roadmap
Stakeholders:
 Executives
 Planners
Stakeholder Concerns:
 Strategic Goals
 Total Spend
Tier 2: Portfolio Roadmap
Stakeholders:
 Portfolio Mgr
 LoB Mgmt
Stakeholder Concerns:
 Investment Stream
 Business Capability
Page 5 of 22
Lower-level:
 More Tactical
 More Detailed
Tier n
Roadmap Framework
One can quickly see that it is the Stakeholder Concerns that drive what content must be contained in the
roadmap. By understanding stakeholder concerns and identifying clusters of overlapping or related concerns,
the roadmap author can identify candidate information content for the roadmap as well as who the target
audience is. Logically, this means that before a Roadmap framework can be constructed, a standardized and
reusable list of Stakeholders and their Concerns must be assembled. An example of this type of analysis is
presented in Section 2: performing this analysis for each specific company is an important step to ensuring the
resulting Roadmap framework reflects the company’s specific concerns and information needs.
The degree of strategic orientation along with the scope/detail of the content “pins” a roadmap to an
altitude/tier. Roadmaps relate to each other by conceptual linkages (based on data points in common
between the two roadmaps), which provides the structure that defines the framework of roadmaps. Section 4
introduces a realistic example of a 5-tiered framework for roadmaps that addresses a range of stakeholders
from upper/executive management to project planners.
1.3
Implementing a Roadmap Framework
The ideal way to achive a dynamic, living framework of roadmaps is to maintain a central data store from
which the various roadmaps in the framework are generated. Unfortunately, there are few competent
roadmapping tools on the market, though a few of the better EA tools will generate them. These tools
generally offer a few different visualization options and don’t generally allow you to custom-design new ones.
The alternative is to manually draw the roadmaps with a tool such as Visio. While this will provide complete
flexibility regarding how you wish to visualize the roadmap, it will require continuous attention to manually
update the roadmap datapoints to ensure all roadmaps remain in sync.
2
ROADMAP STAKEHOLDERS AND CONCERNS
This section lists the primary audience (stakeholders) for roadmaps created within this example framework,
along with the concerns (i.e. topics of significant interest) that the roadmaps are intended to address. Many
stakeholders share similar concerns, meaning that they can be satisfied by a common set of roadmaps. Most
stakeholders will be primarily interested in only one or two tiers of roadmaps, not all roadmaps at all tiers.
Stakeholders:
 Corporate CIO and Executive Management
 Enterprise Architecture and Corporate Transformation Planners
 Senior IT Management: Directors, Assistant Directors and Managers for BRM, Governance & Strategy,
Information Magement, and Portfolio Delivery
 Enterprise IT: Information Management and Technology Integration Committee
 Business Management
 Portfolio Management: PMO, Product Category Leads, Portfolio Architects, Process Owners
 Project Management: Project Sponsors, project staff, Product Owner, App. Owner, Architecture Owner
Page 6 of 22
Stakeholder Concern Mapping
The following table shows an example mapping the highest priority Stakeholders Concerns that these roadmaps particularly will need to provide
information about. These concerns will be presented in the appropriate context with regard to each stakeholder’s role in the organization.
Concern Name
Stakeholders
Concern Description
Port.
Mgmt
Architectural
(or Maturity)
Plateaus
(Transition States)
Business
Applications
How are transformations/changes
bundled together to make coherent
steps forward toward the Target
State?
What existing Business applications
are involved?
Business Services
What Business Services are involved?
Capabilities
Sr. IT
Mgmt
✔
EA & Xfrm
Planners
✔
✔
✔
What Business Capabilities are
involved?
✔
✔
Cost
What will be the cost of this
investment?
✔
✔
Interdependencies
What are the interdependencies with
other existing, in-flight or planned
initiatives, Capabilities, or Processes
✔
✔
✔
Strategic
Alignment
What goals/objectives/actions does
this support and promote? Does this
support the Mission or Vision?
✔
✔
✔
Tech Elements
What IT applications and
infrastructure or platforms are
involved?
✔
✔
✔
✔
What is the timeline (duration or
interval) for realization of benefits?
Ent IT
Bus.
Mgmt
✔
✔
✔
✔
Prj.
Mgmt
✔
✔
Timeline
Corp. CIO
& Exec
Mgmt
✔
✔
✔
✔
✔
✔
✔
✔
✔
✔
✔
✔
✔
✔
xxx
xxx
xxx
xxx
3
STATES OF APPROVAL FOR AN ACTIVITY
Items on the roadmaps in the framework are colour-coded to indicate whether they are in-flight, planned,
have been proposed but not assessed, and other “Approval Stages”. A universal set of states of Approval for
any roadmapped activity in the framework have been defined as follows:
 Unassigned: the activity has a proposal in some early stage of development and has not yet been
submitted to move it into “Proposed” state. This is also a catch-all stage for any activities which seem
to have fallen through the governance cracks to the extent where it is unknown what stage it is in.
 Proposed: the activity been submitted for assessment to the relevant strategic planning or investment
planning governance group. Requisite business case development has been conducted.
 Planned: the activity has been proposed and approved, but is not yet being executed.
 Denied: the activity has been proposed but rejected. However, it was deemed valuable to retain the
activity on the roadmap (perhaps due to implications for other activities or perhaps because it will be
re-proposed later).
 In-Flight: the activity has been proposed and approved, and is currently in execution.
 On-Hold: the activity has been proposed and approved but has been put on hiatus, either before or
after it began executing.
 Cancelled: the activity has been proposed and approved but subsequently has been cancelled, either
before or after it began executing. However, it was deemed valuable to retain the activity on the
roadmap (perhaps due to implications for other activities).
 Completed: the activity was In-Flight and has deemed to be now completed.
The Approval Stage lifecycle is illustrated by the following state machine diagram:
Started
Done
Page 8 of 22
4
THE ROADMAP FRAMEWORK
4.1
Roadmap Overview
The following diagram provides an overview of an example 5-tier roadmap framework:
Roadmap Continuum
Tier 1 – Strategic Investment Roadmap
Purpose: Overview of initiatives from the
strategic plan, showing estimated investment
costs and grouped by affinity (investment
theme, Strategic Priority, Capability, etc.)
Audience: Corp. Executives, Sr. Business Mgmt,
Transformation Planners, Sr. IT Mgmt, EA
Inputs: Strategy (Goals, Objectives, Strategic
Priorities, etc.), Strategic Plan, Assessed
Business
Cases,
Assessed
Opportunity
Statements
Higher Level:
 More Strategic
 More Summarized
Tier 2 – Transformation Roadmap
Purpose: Overview of initiatives from the
strategic plan, mapped to Work Packages in
Transitional States (Maturity increments) and
showing interdependencies, work package
approval status and affected Capabilities.
Audience: CIO, Transformation Planners, EA,
Domain Architects, PMO
Inputs: Strategy (Goals, Objectives, Strategic
Priorities, etc.), Strategic Plan
Transformation Roadmap – <Transformation Name>
Project
Status
Version: 1.0
Lifecycle: Draft Submitted Approved Approved By: <name>
LEGEND
Modified By: <name>
Last Modified:
10/9/2018
Legend
Planned
On Hold
Not Approved
Unknown
Dependency
connector
Dependency
1 label
A
Associated
Work Package
XXX
Transition 2: <Transition Name>
Transition 3: <Transition Name>
<Transition State Description>
<Transition State Description>
<Transition State Description>
A
Action
In progress
Proposed
Transition 1: <Transition Name>
Action
<Strategic Action>
Goal
D
Strategic Plan
Objective
Goal
Objective
E
<Strategic Objective>
<Strategic Action>
G
<Strategic Objective>
Work Package D
Work Package C
Work Package H
Cap1
Work Package E
Transformation Work Packages
Work Package B
<Work Package Name>
<Work Package Name>
Linkage:
 Activities from the
Strategic Plan
Cap3
Work Package H
<Work Package Name>
<Work Package Name>
Work Package J
Work Package J
<Work Package
description – Approval
State: Proposed>
Cap4
<Work Package Name>
<Work Package Name>
I
<Strategic Goal>
<Strategic Objective>
Objective
Work Package A
<Target State Description>
J
<Strategic Goal>
F
Objective
C
<Strategic Objective>
B
<Work Package Name>
Target State: <Transition Name>
Goal
<Strategic Goal>
<Strategic Action>
Action
Capability
H
Work Package J
<Work Package Name>
<Work Package Name>
Cap1
Work Package F
Work Package C
Work Package F
<Work Package Name>
Work Package I
<Work Package Name>
<Work Package Name>
<Work Package Name>
Cap3
Work Package B
Work Package G
Work Package C
<Work Package Name>
Work Package I
<Work Package Name>
<Work Package Name>
<Work Package Name>
Cap2
Linkage:
 Work Packages
Tier 3 – Strategy Realization Roadmap (optional)
Purpose: A break-down of large Work Packages
into milestones (Capability enhancements, project
outcomes, maturity improvements, etc.), showing
approval status.
Audience: EA, Domain Architects, PMO
Inputs: Work Packages, Work Package inter- Linkage:
dependencies
 Work Packages
Tier 4 – Portfolio Delivery Roadmap
Purpose: Central delivery planning and
management roadmap for a Portfolio/Segment,
showing dependencies between Business
Programs/Projects and IT foundational
Programs/Projects.
Audience: CIO, EA, Domain Architect, PMO, IT
and Business Management, Portfolio Manager
Inputs: Work Packages, Work Package interdependencies, (analysis) Work Package
translation to Programs/Projects, affected
Capabilities
Strategy Realization Roadmap – <Sector Name>
Project
Status
Version: 1.0
Lifecycle: Draft Submitted Approved Approved By: <name>
Q2
Q1
 Desc2
In progress
Planned
Proposed
Not Approved
On Hold
Unknown
Dependency between Milestones
Milestones
Modified By: <name>
2019
Q4
Q3
Milestone
Description
Milestone
Description
 Desc3
 Desc3.1
 Desc3.2
 Desc3.3
LEGEND
Last Modified:
10/9/2018
Legend
2018
Current State
 Desc1
2020
Q2
Q1
Q2
Q1
2021
Q3
Q4
2022
H2
H1
H1
2022 Target State
H2
Milestone
Description
 Desc3
Work Package1
Milestone
Description
Milestone
Description
Milestone
Description
 Desc1
 Desc2
Milestone
Description
Milestone
Description
Q4
Q3
 Desc4
 Desc4.1
 Desc4.2
Milestone
Description
 Desc4
 Desc5
Milestone
Description
Milestone
Description
Milestone
Description
Milestone
Description
Work Package 2
Milestone
Description
Milestone
Description
Milestone
Description
Milestone
Description
Milestone
Description
Milestone
Description
Milestone
Description
Milestone
Description
Linkage:
 Work Packages
 Work Package
Milestones
Work Package 3
Milestone
Description
Milestone
Description
Milestone
Description
Milestone
Description
Work Package 4
Milestone
Description
Milestone
Description
Milestone
Description
Work Package 5
Sector Delivery Roadmap – <Sector Name>
Version: 1.0
Project
Status
Lifecycle: Draft Submitted Approved Approved By: <name>
Last Modified:
10/9/2018
Legend
LEGEND
Modified By: <name>
In progress
Planned
On Hold
Proposed
Not Approved
Unknown
Dependency
connector
Q4
Q1
Dependency
1 label
Q3
Capability
1
Capability Legend
General
Note
2020
2019
Q2
XXX
Cap1
2018
Q1
Q4
Q1
Q2
Q3
Q2
Q4
H1
<Capability 1>
2022
2021
Q3
H2
H1
Cap2
<Capability 2>
Cap3
<Capability 3>
Cap4
<Capability 4>
H2
Programs/Projects
<Program Name>
<Project Name>
<Project Name>
2
<Project Name>
Cap4
<Program Name>
1
<Project Name>
<Project Name>
Dependency Connection Notes
1
Service Enhancement Roadmap – <Service Name>
Version: 1.0
Lifecycle: Draft Submitted
Approved
Project
Status
Approved By: <name>
Process, Governance &
Organizational Changes
Q2
LEGEND
Modified By: <name>
Last Modified:
10/9/2018
Legend
2018
Q1
In progress
Planned
On Hold
Proposed
Not Approved
Unknown
2019
Q3
Q4
Q1
Q3
Q4
Q1
<Description
of Change>
<Description
of Change>
Dependency
connector
2020
Q2
Q2
Q4
H1
<Description
of Change>
1
<Project Name>
Interdependencies & Other Notes
1
Business Projects
<Project Name>
1
<Project Name>
<Project Name>
<Project Name>
<Project Name>
<Project Name>
2
<Project Name>
<Project Name>
1
2 <Note 2>
3
3 <Note 3>
Cap3
4 <Note 4>
<Program Name>
<Project Name>
2
<Project Name>
4
<Project Name>
<Project Name>
Cap5
Linkage:
 Programs
 Projects
H2
Lower Level:
 More Tactical
 More Detailed
<Project Name>
<Dependency
description>
2
<Description
of Goal/
Capability
achieved>
<Dependency
description>
<Description
of Goal/
Capability
achieved>
<Description
of Goal/
Capability
achieved>
<Note 1>
Cap2
<Project Name>
Dependency
label
H1
<Dependency Note>
2
<Project Name>
<Description
of Change>
<Project Name>
Dependencies on Platform Maintenance &
otherPrograms
Upgrades
<Project Name>
2021
H2
<Dependency Note>
2
Programs/Projects
<Description
of Change>
<Project Name>
Milestone
Achievement
1
2021
Q3
1
<Program Name>
IT Foundation Projects
Tier 5 – Service Enhancement Roadmap (optional)
Purpose: For specifically-prioritized enterprise-grade
services (eg., Analytics). A description of the planned
changes for an enterprise service, showing servicerelated business and technical (maintenance) projects
and their approval status, required changes to
process, governance or organization, project
interdependencies and capability improvements.
Audience: Domain Architect, PMO, Service Owner,
Program Manager
Inputs: Service Strategy and Strategic Plan Servicerelated
Programs/Projects,
Project
interdependencies, affected Capabilities
Business Projects
Cap1
<Description
of Goal/
Capability
achieved>
Page 9 of 22
5
TIER 1 – INVESTMENT ROADMAP
Page 10 of 22
5.1 Purpose
Provide a 5-year overview of costs, and the distribution of costs, for initiatives from the strategic plan.
5.2 Stakeholders





Corporate Executives
Sr. Business Managment
Transformation Planners
Sr. IT Management
Enterprise Architects
5.3 Concerns Addressed




What are the planned investments and what is our Run/Grow/Transform ratio in a given area?
Which areas are we investing in – what are our investment themes?
What are the estimated costs for each investment?
Do the investments indicate an overall alignment to support the strategy and strategic priorities?
5.4 Context and Inputs




Strategy and strategic priorities
Sector strategic plan and Vision
Assessed business cases and opportunity statements
Enterprise Capability model
5.5 Description
This roadmap may consist of a single artifact or multiple artifacts, depending on the number of strategic plan
initiatives and the number of categories they are grouped into. The main body of the roadmap a spider-web
display that shows how each initiative from the strategic plan drives the strategic plan forward to the end
state Vision, which sits in the center of the web.
Each initiative is represented as a circle that is colour-coded based on the nature of the investment
(Run/Grow/Transform) and sized based on the estimated investment cost (>$1M, $100K-$1M, or <$100K).
The name of the initiative appears adjacent to the circle. Initiatives are grouped by year and by an affinity that
is meaningful to the stakeholder audience (such as investment theme, GoA Strategic Priority, Capability area,
Ministry, etc.). Initiatives that are expected to extend more than a single year may be indicated by a thick line
marking the expected duration.
Transitional steps in the strategic plan may be represented by focus areas listed by year or other period across
the top of the roadmap.
Page 11 of 22
6
TIER 2 – TRANSFORMATION ROADMAP
Page 12 of 22
Here is an alternate format for the Transformation Roadmap:
Page 13 of 22
6.1 Purpose
Describe the strategic plan as a Work Package-based transformation with a series of zero or more transitional
phases (architectural plateaus) to the Target State.
6.2 Stakeholders




CIO
Strategic and Transformation Planning groups
PMO and Demand Management Office
Enterprise/Portfolio/Sector Architects
6.3 Concerns Addressed





What are the activities in the strategic plan?
What work packages are required to realize the strategic plan and what stage of Approval are they in?
How should the transformation be orchestrated as a series of transitional phases?
What are the inter-dependencies between the work packages?
What strategic Capabilities are involved in this transformation?
6.4 Context and Inputs





Sector strategic plan
Enterprise Capability model
Transformation Maturity Model/Architecture Plateaus
Work Package definitions
Work Package dependencies analysis
6.5 Description
This is a single artifact per Transformation. The main body consists of two swimlanes, one depicting
transformation activities from the strategic plan (or ad-hoc introduced opportunities), and the other depicting
the Work Packages required to execute each of the transformation activities. Elements in both swimlanes are
arranged in a series of Transitional States, leading from the Current State to the Target State. Each Transitional
State, upon completion, is designed to leave the organization and info-technical environment in a stable state,
so that if the transformation were to be abandoned upon completing any transitional state, the organization
could continue to operate smoothly: this is a defining characteristic of best-practice Transformation Plans.
These stable states (sometimes referred to as Architecture Plateaus) are indicated on the roadmap as gaps
between the transition phases/stages. How the achievement of a stable state is assured is dependent on the
transformation approach being leveraged: it can be based on reaching a target Maturity level (if the
transformation is Maturity-model-based (eg., CMMI)), on the realization of a new or rationalized Capability (if
Page 14 of 22
Roadmap Framework
a Capability-based planning approach is being used, or simply just based upon a suite of highly-cohesive,
loosely-coupled activities/changes.
Each transformation activity is mapped to one or more work packages that realize (deliver) that activity. These
transformation activities should have a correlation to the “strategic investments” depicted in the Strategic
Investment Roadmap (tier 1). Work packages address the people, process, and technology changes required
to execute the transformation, and are scoped from the size of a Program down to the size of a Capability
increment, depending on the nature and scope of the transformation being planned.
Work packages can have several attached annotations or decorations:
 they are color-coded to Approval stage (Proposed, In-Flight, etc., as described in Section 3 above).
 Inter-depencies between Work Packages are depicted with connectors and labels or, if connector lines
would impact readability, by using the “is dependent on” icon with a label.
 Work packages that introduce or change strategic Capabilities have these impacted Capabilities
indicated with a label.
Page 15 of 22
Roadmap Framework
7
TIER 3 – STRATEGY REALIZATION ROADMAP (OPTIONAL)
Page 16 of 22
Roadmap Framework
7.1 Purpose
Break down the large (Program-scoped) Work Packages associated with a transformation strategic plan into
finer-grained milestones scoped at a project or Capability enhancement level of granularity.
7.2 Stakeholders


Enterprise and Domain Architects
PMO
7.3 Concerns Addressed




What work packages constitute the transformation?
What will the target state look like upon completion of these work packages?
What milestones (projects, project phases, capability enhancements, etc.) are associated with the work
packages?
What is the approval status of these work packages and their associated milestones?
7.4 Context and Inputs




Transformation work packages
Work Package milestone break-down
Work Package/milestone dependency analysis
Assessed business cases, opportunity statements and project charters
7.5 Description
This is an optional roadmap, appropriate for transformations for which large-scoped Work Packages have
been defined that need further refined elaboration.
The main body of the roadmap contains one or more solid bars that indicate a Work Package. Diamonds,
indicating milestones, are spaced along the Work Package, along with short text describing each milestone.
Both the work packages and the milestones are colour-coded to indicate their Approval status (proposed,
planned, on-hold, denied, etc.). Dependencies between milestones are indicated via connector lines.
A timeline is laid out across the top to indicate general sequencing against a 5-year plan, though there is no
intent to indicate exact start/end dates for the initiatives. This timeline is bordered by a Current State
description on the left, and a Target State description on the right.
Page 17 of 22
Roadmap Framework
8
TIER 4 – PORTFOLIO DELIVERY ROADMAP
Page 18 of 22
Roadmap Framework
8.1 Purpose
Provide a delivery roadmap for a Portfolio or Segment of the organization, showing the Business Programs and
Projects, and any dependencies to IT foundational Programs and Projects.
8.2 Stakeholders





CIO
Enterprise and Domain Architect
PMO
Business and IT Management
Portfolio Manager
8.3 Concerns Addressed







What are the Business Programs/Projects?
What are the dependencies between the Business Programs/Projects?
What are the IT Foundations Programs/Projects that support the Sector?
What dependencies exist for Business Programs/Projects on IT Foundations Programs/Projects?
What is the timeline for the programs and projects?
What Business Capabilities are created/enhanced
How will the Target State compare to the Current State after the delivery of these programs/projects?
8.4 Context and Inputs



enterprise Capability Model
transformation work packages
projects architectural dependency assessments
8.5 Description
This roadmap provides a centralized view of all IMB programs and projects within a Sector.
The presentation is divided into two main horizontal swimlanes: the top swimlane contains the Business
Programs and Projects for the sector, while the bottom swimlane contains the IT Programs and Projects that
deliver foundational capabilities required by the business-oriented Programs.
Programs can contain Projects nested inside them to provide greater insight. Programs and Projects are
colour-coded according to whether they are in-flight, planned (approved), proposed, not approved (denied),
on-hold, or of undetermined status (not known, or still preliminary and not yet proposed).
Page 19 of 22
Roadmap Framework
A timeline is laid out across the top to indicate sequencing against a 5-year plan, though there is no intent to
indicate exact start/end dates for the initiatives. This timeline is bordered by a Current State description on
the left, and a Target State description on the right.
Connection lines are drawn from a Program in the Business Services swimlane to a Program in the IT Services
swimlane to illustrate the identified dependencies. To make it easier to track, identifaction labels are attached
to the start and ends of lines.
Red tags appended to the Program indicate which Capability from the Company Capability Model is being built
out.
Yellow tags appended after the red tags map to observational notes that provide context or highlight risks or
dependencies.
Page 20 of 22
Roadmap Framework
9
TIER 5 – SERVICE ENHANCEMENT ROADMAP (OPTIONAL)
Page 21 of 22
Roadmap Framework
9.1 Purpose
Provide a multi-faceted roadmap for more detailed planning and management for enhancing important
enterprise services, such as Analytics, that are more rigorously governed. For example, as part of the Service
Strategy phase of an ITIL service.
9.2 Stakeholders/Concerns



Domain Architect, Service Architect
Service/Product Owner
PMO
9.3 Concerns Addressed







What are the planned Service enhancement projects?
What are the planned platform maintenance and upgrade projects?
What are the dependencies between the planned Service enhancement projects?
What is the timeline?
What are the dependencies between the service projects and other projects/programs?
What Service Capability enhancements will be realized?
What Process, Organizational or Governance changes will be required as a result of these projects?
9.4 Context and Inputs


Company Capability Model
Sector Delivery Roadmap
9.5 Description
This is a series of artifacts; each artifact describes a set of projects required to deliver or enhance an
enterprise Service using a common Gantt-like approach (i.e. timeline and bars). Horizontal swimlanes provide
avenues for describing the Process/Governance/Organizational activities, the required Projects, the platform
maintenance/enhancement activities (which could generate interdependencies with the scheduled projects),
dependencies on other Programs or Projects, and Capabilities (from the the Company Capability Model) or
Goals (from the Stategy Map) that will be achieved.
Projects and Programs are colour-coded according to their Approval status (in-flight, planned, proposed, etc.).
Dependency lines may be drawn between projects within the Program to ensure that sequencing changes of
individual projects take into account these dependencies. Alternatively, dependencies may be indicated simply
by means of the dependency label in conjunction with the “is dependent on” icon (for a dependent project).
Page 22 of 22