Roadmapping in Program Management

From apppm
(Difference between revisions)
Jump to: navigation, search
(Types of roadmaps (150))
(Types of roadmaps (150))
Line 29: Line 29:
 
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 market pull or technology push. Following the top-down direction, the market 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 and how it can affects future products and therefore shape markets.
 
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 market pull or technology push. Following the top-down direction, the market 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 and how it can affects future products and therefore shape markets.
  
===Types of roadmaps (150)===
+
===Types of Roadmaps (150)===
  
 
#'''Product Planning Roadmap'''
 
#'''Product Planning Roadmap'''

Revision as of 16:39, 11 September 2016

Contents

Abstract (171/200)

A technology 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:

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

In this article, the key aspects of roadmaps and their purposes are described. Afterwards, the utilisation and the benefits of roadmapping for program management are discussed both for definition as well as administration purposes. As a third step, an approach to facilitate a continuous roadmapping process is presented alongside key aspects of best practises. Finally limitations are discussed including comparison with different program management approaches, and supporting measures.

Understanding Roadmaps (46/100)

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 (see "Types of Roadmaps"). Most roadmaps however share commonalities which are 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):

  1. Resource perspective (bottom-layers): e.g. technologies, resources
  2. Delivery perspective (middle-layers): e.g. products, services, systems
  3. 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, 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.

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 market pull or technology push. Following the top-down direction, the market 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 and how it can affects future products and therefore shape markets.

Types of Roadmaps (150)

  1. Product Planning Roadmap
    For long-term-planning of product (generations) and the diffusion of research and development initiatives.
    bottom-up: How to utilise/implement technologies for different products? How will technologies shape the products and markets?
    top-down: Which technologies need to be developed for certain products?
  2. Service/capability Planning Roadmap
    Similar to "Product Roadmap", but for service oriented companies.
    bottom-up: How do technologies contribute to capabilities to satisfy market needs?
    top-down: What capabilities are required for business drivers? Which technology developments are required for these capabilities?
  3. Knowledge asset planning Roadmap
    To analyse and/or plan the development of key capabilities.
    bottom-up: How can knowledge assets be utilised in projects and management systems to contribute to business objectives?
    top-down: For which knowledge assets ask certain business objectives?

Roadmaps for Program Management

(0/100) - Explanation why Roadmaps and Program Management goes along well

Roadmaps to define and design Programs (0/250)

Roadmaps to administer Programs (0/350)

Benefits of Roadmaps for Program Management (0/200)

Roadmapping Process (0/1.000)

- Explanation of approach (0/100)

Phase Model (0/800)

===Aspects of good Roadmaps (0/100)

Discussion (0/500)

Customization of Roadmaps

Continuous Roadmaps process

Comparison to different Program Management tools

Personal tools
Namespaces

Variants
Actions
Navigation
Toolbox