Roadmapping in Program Management
Contents |
Abstract (171/200)
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 Technology Roadmaps for the definition of programs. For that, the key aspects as well as popular forms 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 a to facilitate a (continuous) roadmapping process is presented. This is then illustrated using a practical example. Finally limitations are discussed including comparison with different program management approaches.
Understanding Technology Roadmaps (46/100)
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 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 of Roadmaps (160/160)
Roadmaps are time-based charts that depict projects, initiatives, technologies and other planning objects on several layers. Typically, these layers can be joined to 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 XX.
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.
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. For more information on that see XXX.
How to read Roadmaps (104/150)
Typically roadmaps can be understood following a diagonal from the bottom-left to the top-right corner (as indicated in figure XX). Depending on the direction along this line, one follows either the
- Top-Down-direction: market/objective pull or
- Bottom-Up-direction:technology/resources push 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. 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.
Roadmaps for Program Management
(111/100) According to the PMI-Standard, Program management ist 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 an 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.
For that, 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.
Technology Roadmaps to define and design Programs (364/250)
Even though programs contain distinct elements such as well-defined projects, it is key to program's success, to manage these elements mutual interdependence from the beginning. When defining and designing programs it is thus essential to guarantee effective links between the elements. Roadmaps provide this exact high-level scope and focus on the connections between elements. Depending on the company context, a roadmap similar to a product, knowledge asset or service roadmaps can be created in order to find out, if the elements content adds up to the given objectives. This can be seen as a effectiveness-oriented first step, which focuses more on the logical completeness of the programs and puts less emphasis on the timely coordination (see next section for that). Following the aspects underneath a program roadmap can be designed, reviewed, and improved.
| Top-Down-Direction | Bottom-Up-Direction | |
| Key Inputs |
|
|
| Guiding Question |
|
|
| Other possible Questions |
|
|
Top-Down-Reading-Direction
Key Inputs:
- Program objective as the top-layer of the roadmap;
- Key components of value creation chain as the layers (arrange according to perspectives mentioned above)
- Planned technologies, capabilities or else as elements of the roadmap (if applicable/if already decided)
Guiding question:
- Which elements on the lower levels are required to comply with the next higher layers' requirements?
Other possible key questions for the process are:
- How can we link the outputs of the different layers to the programs overall goal?
- Are there excess technologies that will not be used?
- Are there missing capabilities that cause gaps between intended products/services and technologies?
Bottom-Up-Reading-Direction Key Inputs:
- Key technology(ies), asset etc. as the basic starting point of the roadmap (often times bottom layer)
- Key components of value creation chain as the layers (arrange according to perspectives mentioned above)
- Extensive information about market and overall technology development to forecast the effects
Guiding question:
- How will the basis-elements shape the future development of the higher layers?
Other possible key questions for the process are
Example In order to realise the strategic objective to become the leading electrical car manufacturer in the EU (objective) a car manufacturer puts a program in place. To manage it, product releases, organizational capabilities, technologies as well as patent and human resources are considered as main contributors (see figure XX).
Following the guiding question, the goal may now be broken down into initiatives/content in the lower layers.
- Product-layer: To meet the goal, continuous launches of electrical cars every eight months are necessary;
- Capability-layer: To deal with that many launches, multi-project-development needs to be in place;
- Technology-layer: To make electrical cars happen, battery and charging must be understood; Also IT-solutions are to deal with multi-project-development;
- Resources-layer: To understand technology and to be able to deploy it, patents and/or licenses are needed;
Roadmaps to administer Programs (225/350)
Programs are dynamic, as the underlying projects and activities are evolving over time. Consequently, the program itself evolves. Roadmaps also are an interesting scheduling tool to administer and monitor programs, as a high-level overview over all activities. As a result - and in contrast to the aforementioned - when administering programs, Program Roadmapping is less about choosing the right content, but aligning and monitoring the resulting projects, their decision points and success criteria efficiently. In this context it is therefore a strictly time-oriented representation of activities (mostly projects). This way, this approach utilises more of a bottom-up-approach (reading direction) as it focuses on how projects link. The overall objective is therefore set as a smooth program progress (highest benefit and fewest interruptions/issues possible) to attain a strategic goal. For this purpose, program roadmaps may be designed as follows.
Key Inputs:
- Projects as the layers of the roadmap;
- Activities, Milestones and Decision Points as the elements of the roadmap (usually including detailed descriptions)
- Key Deliverables as elements and/or links between projects (usually including detailed descriptions)
Guiding question:
- When to schedule projects so the activities are well-aligned?
Other possible key questions for the process are:
- When can we start certain activities?
- Which information need to be included in the deliverable, so following projects can pick up?
- Are there missing decision points?
- How can we align decision-making without compromising on the program flow?
Example The car manufacturer has translated parts of its initial roadmap into a true program roadmap consisting of the four projects technology development, car development, and marketing with the roadmap in figure XX as a result. It is now easy to monitor what changes on a certain layer (in a certain project) may cause and to manage the effects for the program as a whole.
Benefits of Roadmaps for Program Management (147/200)
Altogether, roadmaps improve program management in many ways. Depending on which type of roadmap is chosen, different aspects will be more prominent, however, they always provide guidance as they summarize complex programs at a glance. Roadmaps therefore:
- Improve commitment and understanding, as they communicate a high-level overall scope and execution of the program;
- Help avoid costly mistakes, as they reveal gaps in the overall program;
- Provide direction and focus, as they link program elements to overall strategic objectives;
- Improve stakeholder/resource management, as they point out key contributors for program success and/or unveil hidden resources
- Help save unnecessary cost/guarantee return on investment, as they focus on benefit/value creation (therefore contribute to lean program management);
- Contribute to risk management efforts, as ripple-effects are easier to foresee;
- Improve collaboration, as they summarize key deliverables;
- Improve decision making, as consequences are easier to foresee;
- Clarify responsibilities, as they define clear tasks/milestones.
Facilitating Roadmaps (0/1.000)
Numerous process descriptions of how to carry out roadmapping exist (two of which are presented in the following). They differ vastly due to the different purposes and types of roadmaps, however they all point out two main aspects that are essential to any roadmap:
- Emphasis on the planning of the roadmap
- What is the scope of the roadmap?
- What is the roadmap's purpose?
- Who is the roadmaps owner and therefore responsible?
- Emphasis on proper implementation
- How to communicate the results?
- How to integrate the roadmapping activities into strategic/budgeting cycles?
- For what to use roadmaps implications?
However, since roadmapping is such a highly customizable undertaking, it is barely possible to define a universal approach. Because of that, the process-models presented are kept rather generic on purpose. Considering that though, an overview of supporting models to facilitate the roadmapping process and enrich a specific roadmap are presented as a toolbox when applying roadmapping.
A Roadmapping Toolbox
Process Models for Roadmapping(0/800)
- T-Plan process: The so-called T-Plan process originates in technology roadmapping and is thus most suitable when defining roadmaps that involve products and/or services. It facilitates a top-down approach, that examines each block of the roadmap separately. To link the stages, analysis grid are used to translate intended features/goals into requirements (see figure XX).
- Planning: In this first stage, ownership of the roadmap needs to be determined, also a common process should be decided. Furthermore, scope and purpose as well should be well defined. Even though this is an initial step, it is crucial to the success of the method.
- Workshop: A series of workshops along the roadmap-perspectives Market, Product and Technology (or corresponding customized layers) is to be carried out. For each, key drivers and features, priorities, strategies and gaps are to be analysed.
- Charting: In this last workshop, the results from the previous workshops are to be charted into the "first-cut" roadmap. At least rough time estimates and connections between tasks should be available.
- Implementation: It is recommended to update the roadmap periodically (at least once a year), if possible linked to strategy/budgeting cycles. Also, communication of the results is key.
- Integrated Technology Roadmap Process: Is a five-stage process and originally targeted at solving "big" social challenges and trends using technology (see figure XX).
- Scoping: Resizing the roadmap to reasonable dimension (scope (geographical, technological range, markets and the like) and time).
- Forecasting: Analysis of initial conditions, identification of trends as well as their exploration using expert interviews, Delphi surveys etc.
- Backcasting: Formulating of (different) future visions (scenarios) and analysing their necessary implications.
- Creation of Roadmap: Create time-line-based roadmap and review uncertainties.
- Transfer: Link operative activities to the roadmap.
- Program Roadmap Process: Derived from a generic roadmap process and specified to create roadmaps to administer programs.
- Understanding current state of program: What are goals, cost drivers, functional needs, business artefacts and processes?
- Aspired end state: Define performance goals and guiding principles.
- Gap Analysis: Team-based search for activities to be addressed in the fields of organization, function, technology and processes.
- Prioritization: Business-value / benefit-creation oriented analysis of the activities.
- Sequencing of events: Define dependencies and analyse the critical path. Maintain a realistic perspective and check for feasibility.
