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.
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 in 2004. 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 that time.
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.
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.
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.
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.
A workshop template based on this generic form is available to download here.
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.
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.
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.
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.
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.
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.
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.
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).