Roadmapping in Program Management

DISCLAIMER:

• The section "Example" is not finished yet, there will be figures according to each stage of the process. Nevertheless, feedback is very welcome
• Literature is not added yet and will follow in the next days.
• Figures are not final yet, they will be arranged nicely to flow with the text (I still have to figure that out)
• Generally, my main concern is "sense-making" so if you do not understand something, please point it out to me :)

Thanks in advance :)

Overview

A roadmap is a time-based chart that aligns multiple planning layers (such as marketing-, product-, development-plan) with strategic business objectives. Its main idea is to create one integrated planning approach. This way, strategic pathways towards specific trajectories can be found, compared and decided while taking into account the planning elements’ interdependencies, mutual requirements and synergies. Due to this holistic approach, technology roadmaps are a valuable tool for program management in organisations in two ways:

• To analyse and define the need for initiatives and/or programs as well as their design;
• To administer programs and their underlying activities.

In this article, the main focus will be on how to use technology roadmaps for the definition of (organizational) programs. For that, the key aspects of roadmaps and their purposes are described. Afterwards, the utilisation and the benefits of roadmapping for program management are discussed. As a third step, a roadmapping toolbox as well as an example for practical use are presented. Finally, the limitations of roadmapping processes are discussed emphasizing the necessity of continuous roadmap processes.

Understanding Technology Roadmaps

Technology Roadmaps were first broadly introduced in the 1970s when pioneers like Motorola used them to integrate their technology and product development/planning. Since then, several types of roadmaps have been developed for different purposes (e.g. Service/Capability Roadmap for service-driven companies; or knowledge asset roadmap for knowledge-driven companies). What they have in common is the approach of extrapolating or ‘’forecasting’’ effects of certain elements into the future and/or backcasting future goals/expected trends into current activities. In order to visualise these aspects, most roadmaps share certain commonalities described below.

Key Aspects - What they look like

figure 01

Roadmaps are time-based charts that depict projects, initiatives, technologies and other planning objects on several layers. The timeframe (x-axis) typically spans several years and may include the past as well for reference. Even though specific dates will increase the roadmap's explanatory power, relatively vague estimates (such as "now", "plans", "strategy") may be useful in some cases.

The y-axis depicts the different planning layers, that can mostly be joined into three main perspectives (blocks):

• Resource perspective (bottom-layers): e.g. technologies, resources
• Delivery perspective (middle-layers): e.g. products, services, systems
• Purpose perspective (top-layers): strategic objectives, markets, business

A more detailed overview including possible layer-categories can be found in figure 01.

Within this framework, bars, and milestones are arranged to represent the activities/initiatives. The interrelations are represented by arrows that connect the different elements often times spanning several layers.

However, timeframe, layers as well as the type of activities etc. represented often are (and should be) subject to customization according to the specific case. The most important aspect for this customization is the purpose of the roadmap that may differ broadly. Also, next to the most common visualization presented above, there are other methods, e.g. tables,graphs,flow charts and others, that may be better suited to represent the situation comprehensively in some cases.

Meaning - How to read Roadmaps

Typically roadmaps can be understood following a diagonal from the bottom-left to the top-right corner (as indicated in figure 01). Depending on the direction along this line, one obtains either an

• backcasting-approach (top-right to bottom-left corner) following the market/objective pull, or
• forecasting-approach (bottom-left to top-right corner) following the technology/resources push.

Following the top-down direction, the market/objective pull is first represented by the strategic business goal, that propagates through the product portfolio plan, and finally the technologies and resources to be developed (backcasting). Thus a holistic approach to fulfilling market needs can be tracked. The other way around (bottom up) one may estimate the effects of a new technology or resource and how it can affect future products and therefore shape markets (forecasting). In practise, both directions are often merged as there will always be some idea about future developments as well as strategic implications.

Technology Roadmapping in Program Management

According to the PMI-Standard, Program management is the centralized coordinated management of a program to achieve the program's strategic benefits and objectives with a program itself being a group of related projects managed in a coordinated way [...]. Comparing these definitions to the overall idea of technology roadmaps - namely the coordination of multiple elements on several layers, to support specific (business) objectives and/or to analyse effect of certain elements on those goals - it becomes clear, that roadmaps are a highly applicable tool for program management. Considering the different program performance domains, roadmaps can play out their strengths in program-strategy-alignment, as well as in benefit-orientation and holistic program design. That being said, they may also be used in the same way for projects (on a smaller scale) as well as to ensure fit within portfolios of projects and programs. To realize these benefits, roadmaps should be defined when initiating a program and constantly revised over the course of it, to manage the design as well as the execution. Therefore, especially in the program management context, roadmaps are to be seen as dynamic documents.

Note: Roadmaps in the PMI Standard: In the PMI standard Roadmaps (in contrast to Technology Roadmps) are presented as a useful tool to administer programs and ensure their benefit creation. While this connects to the approach presented in this article, it does focus on another aspect of roadmapping as it emphasizes the scheduling aspect and alignment of critical milestones, decision points and success criteria definition. Roadmaps in this context are more strictly time-oriented and represent the different projects instead of layers. As a result, the overall idea is to guarantee a smooth program progress (highest benefit and fewest interruptions/issues possible). Technology Roadmaps as presented here are less about carrying out the program efficiently (although they can serve as the base for that) but about finding effective pathways. For more on Program "administration" using Roadmaps, see .

Benefits - What they can do

The key benefit of roadmaps in program management is coordination and alignment. Their high-level scope and their focus on interdependencies enable an organisation to guarantee fit between the programs' elements.