Roadmapping in Program Management
(→Technology Roadmapping in Program Management) |
(→Benefits of Roadmaps for Program Management) |
||
| Line 105: | Line 105: | ||
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: | 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; | + | *'''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; | + | *''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; | + | *'''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 | + | *'''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); | + | *'''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; | + | *''Contribute to risk management efforts,''' as ripple-effects are easier to foresee; |
| − | *''Improve collaboration,'' as they summarize key deliverables; | + | *'''Improve collaboration,''' as they summarize key deliverables; |
| − | *''Improve decision making,'' as consequences are easier to foresee; | + | *'''Improve decision making,''' as consequences are easier to foresee; |
| − | *''Clarify responsibilities,'' as they define clear tasks/milestones. | + | *'''Clarify responsibilities,''' as they define clear tasks/milestones. |
==Facilitating Roadmaps (0/1.000)== | ==Facilitating Roadmaps (0/1.000)== | ||
Revision as of 10:31, 15 September 2016
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.
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.
Technology Roadmapping in Program Management
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.
In the context of PPM, roadmapping influences several aspects as depicted in the Lucent-Maturity-Model (figure XX). They help analyse and forecast and therefore lead to benefits due to better communication and common understanding (first stage), help persuade others (not involved in the roadmapping process) to allocate resources and plan accordingly (second stage) and synchronise programs, planning and portfolio management (third stage). To fully benefit from roadmaps for program management experience and knowledge about the method is essential. However, also in the first and second level, roadmaps (indirectly) influence the process positively.
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.
How to use it
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 |
Program objective as the top-layer of the roadmap; |
Key technology(ies), asset(s) etc. as the basic starting point of the roadmap (often times bottom layer) |
| Guiding Question |
Which elements on the lower levels are required to comply with the next higher layers' requirements? |
How will the basis-elements shape the future development of the higher layers? |
| Other possible Questions |
How can we link the outputs of the different layers to the programs overall goal? |
How will certain technologies be used in the future? |
When to use it
Consequently, according to the different types of programs, namely Engineering Programs, Organizational Change Programs and Societal Programs Technology Roadmaps may be used as follows:
- Engineering Programs
- In engineering programs, technology roadmaps can be used to analyse the effects of emerging technologies on the industry/organisation, or (the other way around) to see which technologies need development to realise a strategic product portfolio or the like. For example:
- Phone manufacturers might analyse the probable impact of flexible displays in order to assess the need for programs to pursue this trend. They may also plan generation-spanning rollout-plans and there product (platform) development programs.
- Car manufacturers might examine which resources to acquire, capabilities and technologies to develop etc. to position them as a leading e-car-brand in the future.
- Organizational Change Programs
- In change programs, (next to IT and supporting technologies), methodologies and knowledge takes the place of "technology". It may therefore be used to assess if the current pathway complies with the company's vision of the future (and to define the corresponding program's elements to get back on track). Next to that, a strategic organizational change may be translated into the required projects (and therefore program). Examples might be:
- Companies may validate the impact of social networks for their internal structure and design a program that promotes, mitigates or direct the effects.
- Organizations may design programs that involve human resource strategies, IT-systems, new processes as well as training and education etc. to facilitate a learning organization.
- Societal Programs
- On a societal level, possibilities for roadmaps are broad and depend largely on the perspective of the roadmap owner. Mostly the face the question on how society will develop according to major trends or how "big issues" may be solved. For example:
- Governments may use the approach to assess the impact of smoking on an aging society (including social systems, health care etc. as layers).
- NGOs may develop roadmaps on which initiatives, farming methods and technologies may mitigate world hunger.
|
Note: Roadmaps in the PMI Standard: |
Benefits of Roadmaps for Program Management
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 (e.g. T-Plan-process, Integrated Roadmap process, Program roadmap process). They differ vastly due to the different purposes and types of roadmaps, however they all point out three 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 finding and/or filling gaps between current and future state
- Where are the gaps?
- Which layers need to be addressed?
- Often times organised in workshops per layer.
- 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. That does not mean though, that there is no need for a structured process. On the contrary, especially the quality of information and the combination of it is essential to a successful roadmap. Due to that, a roadmapping toolbox is presented containing models and processes that help facilitate the building process of a roadmap. Its focus is on the utilization of information that should mostly be available in an organization anyways.
Roadmapping Toolbox
If the necessary information is not at hand from the beginning, the following toolbox offers an array of supporting measures (see also figure XX). It is explained briefly how/for what to use the method for in the context of roadmapping.
- PESTLE-framework the factors political, economic, social, technological and environmental trends and drivers can be used to assess the top layers of the roadmap to find out key trends.
- Porter's Five Forces may be used if the competitive environment is highly relevant, e.g. when the roadmap is used to design strategic differentiation programs.
- SWOT-Analysis can be used to choose the right focus areas for the companies program (layers of the roadmap) as well as to indicate gaps within/between the layers.
- Portfolio-Analysis is useful to define the overall scope as well as to organize the options within the different layers (e.g. technology resources at hand).
- Valuation techniques such as value net-present value, discounted cash flow or the like should be used to assess the different options (projects, technologies, etc.).
- Scenario Techniques should be used to create different pathways and to assess possible future developments.
- Market and technology assessment should be utilised to estimate the "clockspeed" of development. Depending on that, the timeframe for the roadmap should be chosen.
- Delphi-method should be used to gather inside and outside expert's opinions on the initiatives and developments.
- Linking grids (similar to Quality Function Deployment) these grids (see figure XX) link and translate higher-level aspects into lower-level requirements. Thus, they are crucial when linking the roadmaps layers.
