Architecting roadmaps

How to architect a roadmap, or a family of roadmaps? A tough question, as roadmapping is a flexible approach, the context and purpose can vary enormously, and strategy is characterised by high levels of uncertainty, complexity and ambiguity. Not only a tough question, but an impossible one to fully answer, as there is no universal nor agreed theory that can be applied to all applications. A google search will reveal a bewildering array of uses (and misuses) and graphical options (the set below is illustrative of this), which can be confusing. However, there are some principles that can support the design of coherent and useful roadmap structures, which can be readily tested and refined through use.

Roadmaps can take many forms, depending on purpose and context (Phaal/Blackwell et al, 2009/8)

Roadmaps can take many forms, depending on purpose and context (Phaal/Blackwell et al, 2009/8)

Roadmap purpose and format

Examination of roadmaps reveals a great diversity in terms of the domains and purposes to which the method has been applied, and the graphical format, as illustrated below. This diagram, from the most highly cited academic paper on roadmapping, is often misinterpreted as a comprehensive taxonomy, which it is not. The diversity of purpose is much greater than that shown here, which are examples of roadmaps observed at that time. Most examples related to product planning and long range planning (foresight), with other examples illustrating the diversity of application observed, which has expanded greatly since 2004.

Roadmaps can vary a lot in terms of both purpose and format (Phaal et al., 2004)

Roadmaps can vary a lot in terms of both purpose and format (Phaal et al., 2004)

Complexity in roadmaps

In addition to purpose and format, to understand the diversity of roadmaps it is helpful to consider how complexity is dealt with, in terms of both information structure and content, as illustrated below. For example, some roadmaps have a very simple structure, but contain lots of information, while others have a complex structure populated sparsely. Generally, less complex roadmaps are useful for communicating key messages, providing the big picture, while more complex roadmaps are helpful for fleshing out the detail, providing the full picture, to enable strategic planning and implementation. It is helpful to work with both types, for successful communication and implementation of strategy.

Roadmaps can be positioned in terms of complexity in two dimensions - information structure and content (Phaal et al., 2009)

Roadmaps can be positioned in terms of complexity in two dimensions - information structure and content (Phaal et al., 2009)

The figure below categorises roadmaps into three broad types, with the most common (80% of a sample of 400) comprised of one or more time-based layers, which can be divided into sub-types of increasing structural complexity. Type 3 is more pictorial, using explicit metaphors to support communication, such as mountains, board games, funnels and the rather obvious cartographical roadmap metaphor (care should be taken with this type, which can be very powerful, but also not universally appreciated). Type 2 are called 'roadmaps', but do not include the time dimension and are generally building blocks of roadmaps, focusing on aspects of system structure, relationships and process.

Roadmaps can be divided into three types, with the most common (Type 1) comprising one or more time-based layers (Phaal et al., 2009)

Roadmaps can be divided into three types, with the most common (Type 1) comprising one or more time-based layers (Phaal et al., 2009)

Roadmapping as a dynamic systems framework

The roadmap 'lens' can be considered as comprising two 'surfaces' 1) information structure and 2) graphical style. Here the focus is on the underlying information structure of roadmaps, as represented in the standard multilayered time-based sub-types (1d&e above), rather than graphical style, which can dominate human perception (see News & Info - communication roadmaps)

For the multilayered format the main conceptual basis is 'systems thinking' (both 'hard' & 'soft' systems). Most roadmaps are of this type, as was the initial technology roadmap published by Motorola in 1987. Note that this format, as displayed, is a rather literal interpretation of the underlying systems-based data structures, which can be rendered graphically in many ways (e.g. as fishbone diagrams, polar charts, block diagrams). The underlying information architecture and graphical interface are separate 'layers' in the roadmapping 'lens', and the architectural thinking represented below can be applied to other formats, for coherence.

General purpose multilayered time-based dynamic systems framework (Phaal & Muller, 2009)

General purpose multilayered time-based dynamic systems framework (Phaal & Muller, 2009)

Roadmaps of this type provide a systematic structured 'language' (categories, defining layered structure, necessary for effective communication within and between organisations, for strategic alignment), set against time, from the past to the future. Considered in this way, roadmapping provides a general purpose 'dynamic systems framework' that can be applied to any developing, evolving or changing system (incremental to radical / transformative), including temporal relationships between elements of the roadmap, allowing synchronisation.

Layers typically represent various stakeholder perspectives, organisational structures and taxonomies, and generally it is sensible to use existing organisational structures and language in the roadmap design (unless a different perspective is desired - e.g. cutting across existing structures and perspectives).

Generic roadmap form

The most generic form comprises a 3x3 matrix defined by six broad questions, highlighted in red in the diagrams above and below. However, this is just the structure - the easy part. The content and associated strategy and organisational challenges that must be faced to implement strategy require a lot more than a diagram to address. Roadmaps have been referred to as "dirty mirrors", revealing unpleasant organisational truths that may need to be confronted to move forward; don't blame the messenger. 

Six fundmental strategic questions define the generic roadmap form - a 3x3 grid

Six fundmental strategic questions define the generic roadmap form - a 3x3 grid

A workshop template based on this generic form is available to download here (see template #10).

Depicting time in roadmaps

The time axis can be adjusted relatively easily, with some thought as to the rate of change in and of the system. There are no prescriptive rules, but often a roadmap might extend forward to at least two innovation cycles. The time frames considered in the roadmap will relate to the rate of change in the system - long term for software might be 2 years, while for infrastructure it can be decades. For many industrial applications 1 ('budget'), 3 ('strategy') and 10 year ('vision') timeframes work well. 

Care should be taken with the precision to which the roadmap is defined, as the future is uncertain (of course). Often short-, medium- and long-term epochs are sufficient, although sometimes it may be necessary to specify the first year down to the month. It's useful to include 'vision' on the right, to help set direction, and the past to at least capture the current status and recent experience (retrospective roadmapping can do more - see News & Info). 

Often a non-linear time scale is used, as there will be more knowledge of and interest in the short-term (actions and budgets), informed by the medium- and long-term, and vision (which is helpful as a direction setting 'beacon'). This pattern can be reversed if the intent and need is to focus on the long-term.  At the very least, it is important to sequence content, even if actual dates or timeframes cannot be established.

Structuring the roadmap

The vertical axis, defining the multilayered structure of the roadmap, is more challenging. One of the confusions associated with roadmap design is that there are three iterative dimensions associated with strategy, with only two dimensions available to represent these in a 2D diagram (the roadmap). Of course, software is more flexible, allowing multiple views of the same underlying data, and dynamic configuration of the view to suit the context.

Roadmap architecture design takes into consideration the inherent iterations associated with strategy and innovation management, in three dimensions that are compressed into two in the roadmap diagram (adapted from Phaal and Muller, 2009)

Roadmap architecture design takes into consideration the inherent iterations associated with strategy and innovation management, in three dimensions that are compressed into two in the roadmap diagram (adapted from Phaal and Muller, 2009)

It's not critical to get the roadmap design perfect first time (good enough will do), as testing it with content through several iterations may be necessary to stabilise the structure and language. Also, remember that any diagram (including those on this page) is just a representation and not the underlying conceptual framework itself. When structuring a roadmap diagram one has choices about what to show, where to put it, and how much space and emphasis to give it, based on judgements relating to purpose and context. For example, 'special' layers can be included where helpful - to highlight a particular aspect, such as key performance indicators, or risks, and also it may be useful to show two perspectives on the same thing - such as function and performance of a product (which in software could be switched according to the metadata chosen for display).

The underlying architectural elements that one considers as part of the design need not all be shown on the roadmap diagram - some may be implicit, used as organising principles but not explicitly depicted. Special interface layers may be be inserted for good reason - e.g. to highlight enablers and barriers to transferring new technologies to production. Wireframe diagrams using cartesian coordinates are widely used, essentially tabular in format, although there are other options - e.g. polar coordinates (transformation maps or 'sunshine charts'), and other tools and methods can be embedded or combined to create hybrid forms.

The deployed roadmap structure (see schematic labelled 'd' in diagram above) should 'fit the problem', which can only be demonstrated by 'stress testing' it with data (primary and/or secondary), to ensure that the 'canvas' or 'database structure' provided by the roadmap is suited to the kinds of discussion and decisions it is intended to support, and the context in which these occur.

1. Iterating across system hierarchy

The scope and focus of the subject of the roadmapping activity must be clear - where do the key concerns lie, and what needs to be considered (and what doesn't)? The focus and scope can be positioned in terms of systems hierarchy - for example, is the focus a product, platform, business, sector, technology or something else? See schematic 'a' in above diagram. At what granularity must the focal system be examined to address the issues of concern? It is generally necessary during strategy and innovation to consider both higher and lower level elements of the system. 

For example, if the focal topic is a component (e.g. engine) of a car, the overall vehicle will need to be considered - in particular the interfaces between the components (e.g. drivetrain), and also the wider system within which the vehicle operates (e.g. road network). Equally, the sub-components at lower levels (e.g. pistons) will need to included, as they influence the form and performance of the focal component. Choices must be made as to the degree of granularity that other elements of the overall system (as defined by the scope) need to be considered.

The various relevant perspectives represented in the roadmap (broad layers) typically obey different hierarchical principles. For example, markets might be organised by segment, products by function and technology by discipline.

Roadmap architecture used for aerospace company, focusing on manufacturing of one key vehicle system (Phaal et al., 2010)

Roadmap architecture used for aerospace company, focusing on manufacturing of one key vehicle system (Phaal et al., 2010)

For endeavours of scale (businesses, large programmes) a family of roadmaps will be needed to allow horizontal and vertical alignment and synchronisation. It is helpful to ensure that the core narrative for each roadmap is clear, and aligned with those above and below in the hierarchy, with a common underlying architecture. This is an enterprise architecture consideration, and without this being clear large scale deployment of roadmapping is challenging. It not uncommon to find pockets of roadmapping practice in large firms, often unaware of each other. It is rather easy to demonstrate the potential of the tool to support corporate alignment, but delivering it is another matter, requiring board-level support.

The systems-based architecture of roadmaps allows an hierarchical family of roadmaps to be developed, enabling aggregation and drill-down ('pan & zoom'), supporting vertical and horizontal alignment of strategy, process and toolkits

The systems-based architecture of roadmaps allows an hierarchical family of roadmaps to be developed, enabling aggregation and drill-down ('pan & zoom'), supporting vertical and horizontal alignment of strategy, process and toolkits

2. Iterating between demand and supply

The relationship (tension) between  'market pull' and 'technology push' (or more generally, 'demand pull' and 'supply push'), is a fundamental consideration for both innovation and strategy (see schematic 'b' in above diagram). The form, function, features and performance of products represents a 'balance' (tradeoff) between what is needed (or perceived to be needed before proven in the market - market pull), and what is achievable (technology push).

This fundamental dynamic is built into the general format of roadmaps, in terms of the overall structure, which comprises three perspectives as broad layers, relating to fundamental questions: why? what? and how? During innovation this iteration tends to occur over time, through demonstration in phase-review processes and in the market, with frameworks such as the 'stage-gate' product development, 'innovation funnel' and 'lean startup' (agile) approaches used to communicate and manage the process, with the aims of reducing risk, improving efficiency, and accelerating innovation. 

3. Iterating in time

Time is a fundamental consideration in strategy and innovation, and it's puzzling that this dimension is not included overtly in most strategy frameworks (e.g. SWOT and Strategy Maps). This is addressed in roadmaps, where time is an explicit dimension, with considerations for representing time in roadmaps discussed above. Iterations in strategy and innovation take time in themselves (it pays to iterate fast at the start), and also require consideration of the longer term future, the present (and possibly the past), along with the short- and medium-term.

Sector level roadmapping workshop, focusing on a key 'landmark' identified in the 'landscape'

Sector level roadmapping workshop, focusing on a key 'landmark' identified in the 'landscape'

Bringing it together

The above three dimensions that must be considered during strategy and innovation iterations are highlighted in schematic 'c' in the above diagram, with the path taken during the strategy or innovation process shown moving forward in time. The challenge is how to show these three dimensions in a 2D diagram (the roadmap structure). Time has its own dimension, with the other two defining the layered structure. The pull-push logic dictates the overall structure, in terms of three broad perspectives defined by the why, what and how questions. Within these, various hierarchical logics will apply, as appropriate - for example, products, services and other value-adding systems may all be positioned in the 'what' layer, but each will be subject to a different hierarchical logic. These layers may be broken down into sub-themes and further, to the level of granularity needed to address the focal issues (supporting decision making), where granularity is likely to be highest, and other adaptions made as appropriate from this basis.

Only a part of the overall architecture need be used at any one time - in a workshop, or for a software view. Keeping an eye on the overall governing architecture even when considering one application only (e.g. a business unit) will keep options open if the approach is to be rolled out to other parts of the organisation (e.g. other business units), to enable comparison and aggregation (e.g. to highlight synergies, or to create a corporate roadmap).

Roadmapping is just one tool, and as with all management tools it has strengths and weaknesses. Thus, toolkits are needed, combining and configuring tools so that the strengths of one addresses the weaknesses of another. The holistic, integrative and flexible nature of roadmapping makes it the ideal integrating platform for toolkits.

Second iteration, focusing on functional (production) strategy, with first-iteration inputs from other functions (digital composite top left, with first iteration production layer below, and other functional groups working in parallel in other small groups)

Second iteration, focusing on functional (production) strategy, with first-iteration inputs from other functions (digital composite top left, with first iteration production layer below, and other functional groups working in parallel in other small groups)

The underlying 3x3 framework and associated data structures and content can be rendered in many ways depending on purpose, context and preference - as illustrated below. A process has been developed to support the visual design of roadmaps, demonstrated for graphene (Nanoscale vol 7, no 11): Kerr, C. and Phaal, R. (2015), 'Visualising roadmaps: a design-driven approach', Research-Technology Management, 58 (4), pp. 45-54.

Roadmapping workshops are a useful part of strategy and innovation processes, but not sufficient - an immediate subsequent task is to transcribe the outputs to share with participants to confirm accuracy. Further work is needed to develop a presentable roadmap from the workshop and other sources in graphical format, and several may be required depending on audience and purpose. The above schematic examples are helpful for inspiration, as is an internet image search. At the early stages presenting roadmaps as drafts for comment is helpful for improving the roadmap and engaging stakeholders, as part of a wider consultation phase, and also to manage expectations - roadmaps can only ever be as good as the strategic thinking they convey, and are out of date as soon as created, as the world moves forward and events happen.

The product-technology roadmap example below was designed for detailed technical communication and programme management for an aerospace system (Type 1e), with key design features highlighted. It was created by the multidisciplinary programme team for this purpose, and is thus fairly complex in terms of structure and content. It was used as a resource for developing several simplified roadmaps in terms of format and content for senior management and broader dissemination. 

Full-life aerospace systems roadmap (Type 1e), showing technology and product options for a new system, with roadmap design features annotated. Key content has edited for confidentiality reasons.

Full-life aerospace systems roadmap (Type 1e), showing technology and product options for a new system, with roadmap design features annotated. Key content has edited for confidentiality reasons.

A consistent approach to roadmap and narrative structure can enable coherence across a large scale, as demonstrated by the Japanese Ministry of Economy, Trade and Industry (METI). Twenty-five major areas of technology and their applications were mapping at the national level using a consistent style and structure, enabling intersections between technology domains to be explored in terms of technology convergence ('C-Plan' approach).

 

If you have any queries regarding research, training, collaboration or other support please contact me at rob.phaal@eng.cam.ac.uk.

Rob Phaal