PLOTTING AND NAVIGATING A NON-LINEAR ROADMAP:
KNOWLEDGE-BASED ROADMAPPING
FOR EMERGING AND DYNAMIC ENVIRONMENTS
Jeffrey D. Strauss and Michael Radnor
J. L. Kellogg Graduate School of Management
Northwestern University
and
John W. Peterson
Bell Labs (Lucent Technologies)
January, 1998
Revised May, 1998
Prepared for Conference on “Knowledge Creation Management in Asia”, Singapore,
March 6-7, 1998 and The Asia-Pacific Journal of Management.
ABSTRACT
Major best-in-class companies recognize that success will depend on their ability
to create and apply knowledge in ways that fit their increasingly complex and dynamic
market and corporate environments. Two valuable but still relatively separate
management toolsets have evolved - scenario planning and roadmapping. Both
approaches, but particularly scenario planning, strive to specify and challenge
assumptions and to develop a shared understanding of a conceptual framework within a
unit or a company. Roadmapping details implementation of plans, converting explicit
inputs, and, to an important degree, tacit knowledge, into more usable and
understandable explicit knowledge.
When "properly" implemented, either toolset can claim to merge into the other.
But this is rarely the case and it is particularly in the volatile environments found both in
emerging economies and in the knowledge-intensive industries, that neither approach
achieves its potential independently. More closely linked, the two approaches can
complement each other in important ways. Blending the advantages obtained from
scenario planning with roadmapping seems a natural next step. But scenario planning
tends to be carried out at the strategy development level whereas roadmapping tends to be
undertaken and applied at the operational level. The challenge of marrying the generally
high level and macro thinking of scenario planning with the micro planning of
roadmapping, though daunting in practice, appears worth the effort.
This paper will review each of the above toolsets. Two new methodologies are then
introduced that could provide the complementing conceptual and practical
implementation guidelines needed to overcome inherent limitations and maximize the
contribution to knowledge management. They may also bridge the toolsets’ disparate
organizational, environmental, industry, product life cycle and knowledge type contexts.
The new tools come from a consortium of US firms collaborating in the in-depth analysis
of management of technology and related organization processes, under the auspices of
the National Center for Manufacturing Sciences (NCMS) and from an emerging
economies research project at the Kellogg School.
2
2
1. Overview
It is the thesis of this paper that marrying the enhanced vision, flexibility and
environmental monitoring strengths of scenario planning with the clarity, integration
and attention to detail inherent in roadmapping can help overcome the limitations in
applying these tools independently. It is further proposed that two newly available
toolsets can provide the missing conceptual framework and implementation guidelines.
These toolsets can enable an effective blending and maximize the contribution to
knowledge creation and management, and, ultimately, the firm’s competitiveness. We
begin by examining the rationale and approaches inherent in each of these toolsets, as a
basis for presentation of a proposed unified approach. The empirical observations
regarding the use of existing tools and the development of new ones, derive from a
large scale study of technology process analysis and of how to better manage
technology and accelerate its introduction so as to reduce cycle time and provide value
chain advantages. The study is being carried out by a consortium under the auspices of
the National Center for Manufacturing Sciences and Kellogg faculty leadership [see
Levin, Radnor and Thouati, 1997; Radnor, Erikson and Peterson, 1998; Thouati, Radnor
and Strauss, 1998.] This consortium includes US firms (General Motors, Kodak, Lucent
Technologies, Bell Laboratories (Lucent Technologies), Rockwell and Westinghouse,
plus the US Airforce, NASA and other government agencies and several consulting
firms. Additional input comes from an on-going Kellogg School research program on
emerging economy planning.
Though approached from a somewhat different perspective, this presentation
clearly relates to and complements core concepts in knowledge management. Included
here is Nonaka’s view of the challenge in knowledge creation within corporations to
maintain a holistic perspective while converting tacit to explicit knowledge and
creatively recombining explicit and tacit knowledge to make a more desirable and
usable whole [Nonaka, 1991.] The focus of this paper is on how such concepts and
others can be applied through practical administrative and operational toolsets with
consideration of underlying functions, management processes and their
interrelationships.
1.1 Technology and Product Roadmapping
Major companies are strategically dependent on a smooth and rapid flow of
technology and innovation in their products and processes. To improve their ability to
respond to intense competition and to technology and market changes, many US firms
have increasingly turned to roadmapping. Roadmapping was originally developed to
help companies anticipate and clarify resource and performance requirements and to
3
3
plan and systematically manage and integrate complex projects [Willyard & MacClees,
1987; Barker and Smith 1995; Cochrane, Temple and Peterson, 1995.] The same
techniques were then adapted for use within companies to facilitate complex
technology planning and communications. Firms use many types of roadmaps
including manufacturing, financial, technology and product roadmaps as well as
industry roadmaps. This paper will focus on technology and technology-based
product roadmapping and will use “roadmaps” and “roadmapping” to mean these.
Such roadmaps provide linkage between units and are particularly helpful in
strengthening the connection between high level strategic planning and operational
strategy for required “sense making” cartography [Weick, 1993.]
Typically based on strategic plan requirements, roadmaps incorporate product
attributes and lay out goals, development requirements, allocation priorities and
defined evolution plans for flagship or core products and platforms. All are specific
steps for the company to optimize and coordinate efforts to realize pre-defined
objectives. Core competencies are highlighted along with important gaps and other
areas needing to be addressed in order to achieve growth and market advantage.
Companies may assess and establish a range of related roadmaps. For example, in
Lucent Technologies, a “product technology roadmap” may include hardware, software
and algorithm roadmaps as well as supporting business information and analysis. To
this array can be added financial roadmaps and many more. Roadmaps may exist at
offer, product, common technology and even at industry levels with varying degrees of
linkage between roadmaps [Eriksen, Peterson & Wofford, 1998.] Responding to strong
company interest, the NCMS Technical Conference in Orlando in May, 1998 was
devoted to industry sector roadmaps.
The process of developing the roadmaps can be valuable in and of itself in
encouraging thinking and cross-organizational communication. Indeed, some claim
that it is as much or more the process of engaging in the roadmapping activity than it is
the roadmap itself that provides the real value add. This is particularly so to the extent
it allows going beyond synchronizing and combining inputs and involves the desired
exchange between tacit and explicit knowledge to create a new shared commitment and
understanding of goals, requirements and possibilities [as in Nonaka, 1991.] Naturally,
who is involved in the process will vary based on organizational structures and
cultures. It is recognized, for example, that internal and external relationships in East
Asia are often quite different than in the West. Although roadmapping incorporates
technology trajectories and competitive environment inputs, as typically implemented,
it generally assumes a straight line, incremental assumption set [Kappel, Radnor and
Peterson, 1997.]
1.2 Scenario Planning
4
4
In the changeable environments of emerging economies and high growth
knowledge-based industries, another management tool, scenario planning, is often used
to enhance strategic planning. This approach originated in military area studies and
strategy and contingency planning before being more generally applied to corporate
strategy by the RAND corporation and Royal Dutch Shell in the early 1970’s
[Georgantzas and Acar, 1995.] Royal Dutch Shell’s use of this approach enabled the
company to be prepared to respond to the 1972 oil shock and other developments
[Schwartz, 1991.] Indeed, changes facilitated by scenario planning shifted Shell’s
strategic posture. Once one of the weakest of the big seven oil firms, it emerged second
only to Exxon in size and first in profits [Georgantzas and Acar, 1995.]
The tool’s function is to highlight the implications of possible future systemic
discontinuities, helping managers identify the nature, timing and implications of, and
prepare for, a range of changes. It does this by developing detailed, often proprietary,
pictures of alternative futures. Corresponding indicators including weak signals are
also specified to help the company recognize and respond to an emerging situation
before the competition (see discussion of environmental monitoring and the danger of
being blindsided below.) Scenarios are typically derived from a future perspective
rather than projecting from present situations. This allows consideration of systemic
change. A vice-president of the Futures Group observed that, contrary to what is
implicitly assumed in approaches that extrapolate from the present, reality (particularly
in volatile environments) “has a tendency not only to change the values of the relevant
‘variables’ but to change the very ‘equations’ on which the variables are organized and
the business is based” [Perrottet, 1996.]
As was also noted to be the case in roadmap development, significant value
derives from the process of working out the scenarios. Indeed, as discussed further
below, scenario planning can be properly viewed as a learning process, for the
individuals involved and for the organization. In developing and analyzing scenarios,
companies are encouraged to consider options beyond their traditional operational and
conceptual comfort zones. Properly done, scenario planning forces companies to make
explicit their tacit assumptions on product features, functions and price points,
competition, market structure and regulation and cost factors. Often, this highlights
significant, but perhaps unrecognized, underlying differences in perspective between
and among divisions, functions and managers. As a manager at Motorola Corporation
put it, a key goal in scenario planning is to find “a-ha’s and “uh-ohs” (comment during
a series of presentations and informal discussion at the Kellogg School with Motorola
personnel, 1996.) Thought of in another way, scenario planning forces a shift to a new
perceptual framework (a future perspective) creating an “umbrella concept” focus for
working teams. Using Nonaka’s terminology, teams are challenged to “articulate” the
scenario worlds as usable inputs for strategic planning. [Nonaka, 1991.]
5
5
It is critical to the successful application of this tool that the scenarios are chosen
appropriately. This requires a sophisticated identification of company response
tendencies and relevant environmental, competitive and corporate drivers. Once
scenarios are defined and assessed, the often complex, unexpected and cascading
impacts the scenarios might have on the organization and its approaches need to be
carefully and thoroughly reviewed, function-by-function and process-by-process.
Finally, step-by-step strategies and contingency plans must be worked out that fit the
scenarios and company capacities and weaknesses, enabling the company to prepare for
and work toward the range of possible developments. As in the case of Shell noted
earlier, those pursuing such approaches stand to benefit massively in the face of major
discontinuities. Not doing so can be very costly, even for firms that are only too well
aware of what might happen but that are not systematically prepared for the
occurrence. To be topical, although many companies in East Asia recognized the likely
scenario of the recent economic downturn with sufficient time to plan, few were
prepared and positioned to effectively respond when such events actually occurred.
1.3 Pointing Towards A More Comprehensive Approach; Facilitating Tools
A carefully designed and implemented combining of these two knowledge
management tools points towards the best of both worlds, i.e., more robust and
dynamic product technology architectures designed to fit across a range of even quite
different scenarios. These could feature "flex points" where adjustments in technology
can be anticipated and "forks in the road" where alternative scenarios may require new
products or approaches. However, blending these tools is not easily accomplished in
practice.
Not only are the two tools distinct from each other in thinking, scope and the
type of learning that occurs but also in the organizational level at which they are
developed and implemented. Thus, formal scenario planning is generally part of
corporate strategic planning while roadmapping falls in the domain of operational
business unit managers. And, while both roadmapping and scenario planning
processes are generally carried out by working teams (even sometimes “virtual”
working teams), the task of designing a given scenario is often given to an ad hoc team
which may include outside experts and constituencies, including customers and
suppliers. The extent to which the make-up of scenario design and roadmapping teams
varies, as well as the implications for buy-in and optimal use within a corporation, are
challenges for a unified approach.
There are also common shortcomings to be overcome. Particularly in volatile
and uncertain environments, both, still relatively new approaches tend to suffer from
insufficient recognition and credibility. Specification of company vulnerabilities,
strengths and drivers as well as sophisticated analysis of organizational processes is
required but is rarely done adequately. In consequence, there is a tendency to under6
6
consider, systematically and comprehensively, both the effects change may have and to
fail to identify vulnerabilities that may be evident on a process level. Both tools often
have insufficient leverage due to their relative newness and limited usage. Ironically,
this is especially true when, in a time of crisis, company vulnerabilities and weaknesses
are highlighted and traditional accepted strengths, market drivers and the adequacy of
current processes are challenged.
Thus, "blending" requires resolving a number of classical structural,
strategic/operational and macro/micro perspective and time-horizon differences.
Differences in incentive and recognition systems must also be considered. Moreover,
the task will present very different challenges in environments that vary in uncertainty,
length and shape of life cycles and life cycle positions. Also important are the vital
requirements for developing and applying the new approach, considering product
variations and complexity and the need to integrate across a company's multiple
technology, product, manufacturing and other roadmaps.
To address the concerns and limitations inherent in each tool, the inclusion of
other innovation management methodologies now being developed in the two
previously mentioned research and application programs is also recommended. These
new tools look across the organization defining critical management processes and how
they interrelate, enabling recognition (and shared understanding and acceptance) of
precisely where and how vulnerability to change can manifest. Also revealed is the
pervasive impact of change on the organization. Guidance can also be provided to
determine on a planning level the company's "stress points" (weaknesses, gaps) and
"opportunity points" (competitive strengths and skills), drivers and growth engines
where these exist [Thouati, Radnor and Levin, 1998], gaps and other critical blind spots.
The brief detailing of the roadmapping process and scenario planning which
now follows will both provide a common base of understanding of the tools for further
consideration and highlight the benefits/strengths and costs/weaknesses to be
considered in the “blending” process.
2. Explicating the Roadmapping Toolset
This review describes the roadmapping process, and reviews its application.
The primary focus is on technology and product roadmaps (hereafter referred to as
“roadmaps”.)
2.1 Definition and Context
7
7
Technology and product planning is becoming more critical to the technology
intensive enterprise. This is reflected in part in Moore’s Law and the rapid
development and obsolescence of electronic and processing technologies. With this in
mind, roadmapping provides a tool for selecting which technologies to pursue, and in
what time frames. Most major companies are facing attacks from global challengers. In
some cases, the threat is caused by the challenger operating more efficiently either alone
or in alliances. In other cases, a company’s positioning is being hurt by severe cuts in
research and development funding. This is occurring even as product complexity is
increasing, the time available to bring customized products to market is shrinking and
customers are pressuring for greater performance at significantly lower prices. In
addition, product life cycles are becoming shorter in many sectors and enabling
technology “S” curves shallower. Roadmapping provides a way to identify, evaluate
and select technology alternatives that can be cognitively used to address the need for
better, faster and cheaper enabling technologies.
2.2 Benefits of Roadmapping
An important benefit of roadmapping is that it provides a visual language that
allows the executive decision maker to participate more fully in technology decisions. It
is no longer necessary to reskill an executive in the mysteries of the technology in order
to make effective technology decisions. The necessary information can be displayed in
a format that identifies critical technologies and technology gaps on a product by
product basis. The process allows the technical evolution plan to be packaged with the
appropriate business information so that technology and product recommendations can
be considered in the context of business strategy and portfolio commitments. This, in
turn, allows the firm to leverage R&D investments by coordinating research activities
either within the business unit or across the company or among members of an alliance.
An additional benefit is that as a visual tool it can be displayed on a “read-only”
intranet site (i.e., a limited number of people authorized to make changes) and provide
a real-time record related to design and technology commitments.
As a result, roadmapping is a specific technique for business management, which
fits within, but does not replace, a more general set of business planning activities. It
leverages the identification of future critical product features and functions to drive
technology selection and development decisions [Peterson, 1998]. In most major
companies, the information and functions leveraged in the roadmapping process
already exist. However, they are typically gathered in an ad-hoc way and their use has
been controlled by the “keeper of the knowledge” rather than allowing its use to more
broadly improve decision making. Roadmapping provides a consistent methodology
to communicate and reinforce agreed-upon technology investment decisions.
Roadmapping at the industry level involves multiple companies, participating
either as consortium members or as part of an entire sector activity. By focusing on
8
8
common needs, participating companies can more efficiently leverage critical research
needs without incurring the massive fixed costs and expenses necessary to fund such
research by themselves. Collaboratively developed common technologies and
standards address the requirements for information products to openly connect to
information networks. Examples include the Semiconductor Industry Association (SIA)
Semiconductor Technology Roadmap which deals with requirements for semiconductor
manufacturing, the National Electronics Manufacturing Initiative (NEMI) Technology
Roadmaps and de facto European Commission efforts such as RACE (Research for
Advanced Communication) and Espirit (information technology.) Such activities allow
industry collaboration in the development of necessary enabling technologies without
violating the intellectual property rights or trade secrets of the participating companies.
2.3 What is a Product Technology Roadmap?
The output of the technology roadmapping process is typically a product-specific
roadmap which, in simple visual representations of hardware, software and algorithm
evolution, links customer-driven features and functions to specific clusters of
technologies. It depicts, in snapshot form, how it is currently anticipated that those
technologies will change over the product’s life cycle. The product technology
roadmap helps identify, select, and depict the sources of the enabling technologies
within the context of business strategy investments and business and product needs.
Prepared by a cross-functional team, it provides a standard framework for organizing
and presenting the critical technology-related data for executive decision making.
Product technology roadmapping also helps flag the need to develop or accelerate the
introduction of skills, concepts and new cross-product enabling technologies.
2.4 Strategic Context for Roadmapping
Roadmapping is an iterative process that fits within the broader business
management context. It is a management activity that links three critical elements:
customer/market needs and opportunities; product quality and competitive
positioning; and, corporate capabilities (including business and technology value chain
attributes.) A roadmapping activity goal is to mirror the outputs of the strategic and
business planning activities and present that data in a simple and actionable format.
Roadmapping is not a substitute for strategic and business planning. Nor is it a
cure-all for product and business management. It is a time-intensive activity, at least in
the initial iteration, and it’s use is often considered to be most appropriate for complex
and long-lived technology-intensive flagship systems, with technology “S” curves that
run over extended periods. Roadmapping time horizons are generally no less than oneand-a-half to two product life cycles. In this thinking, longer term requirements, i.e.,
more than five years out, can be addressed in directional terms, void of a great deal of
detail but specific enough to help flag discontinuities if there is an unanticipated change
9
9
in enabling technologies. In long-lasting platform businesses (e.g., for Lucent on largescale switches), the planning horizon may run from five to fifteen years. Some claim
[Willyard and MacClees, 1987] that roadmapping can also be used effectively with
products having shorter life cycles, such as the consumer products manufactured by
Philips Electronics [Groenveld, 1997.]
Such roadmaps are very important when it is not immediately clear which
technology alternative makes the most sense (e.g., enhance an existing technology or
replace it with a new one) or how quickly the technology will be needed. Relatedly, this
tool can be invaluable when there is a need to coordinate the development of multiple
supporting technologies. The process is based upon company-specific product
objectives and involves identifying industry expectations for the trajectories and timing
of changes in specific key technologies. Value is realized by relating company
capabilities and technology importance to the product technology needs. If timing is in
synch with industry availability, all that is required is an assured source of supply. If
industry availability is earlier than anticipated need, new entrants will attack and
reduce projected market shares and contribution. If industry availability is later, there
may be the opportunity to invest and achieve an intellectual property position or a
feature, function or cost position that will disadvantage the competition and increase
the company’s market share and contribution.
The extent to which roadmapping is actively supported, promoted and
integrated across units and across the organization varies considerably from
organization to organization. Philips has gone to unusual lengths to assess the fit
between technology development and market needs and to enhance roadmapping
through links to other strategic tools. As a consumer electronics company these tools
are strongly market driven. Two examples are Quality Function Deployment (QFD)
and the Innovation Matrix. QFD translates consumer requirements into product
(technical) characteristics. The Innovation matrix positions products and technologies
on a nine sector grid with the vertical axis being uncertainty (market, feasibility) and
the horizontal axis being technology availability/development. Time frames of 1-2
years, 3-5 years and 5-10 years are generally used and the matrix is completed
separately for products and for technologies and then mapped to each other. This is
then fed into roadmaps [see Groenveld, 1997.]
As noted further below, a process can be envisaged of mapping diversification
into new technologies with related learning and competency development linked to
roadmapping for current products and technologies. This could address expected
market developments [the growing need for this is indicated in Granstrand, Patel and
Pavitt, 1977.]
2.5 The Roadmapping Process
10
10
Figure 1 here
Figure 1 is designed to illustrate the inputs required to produce a given
roadmap, in the case shown a technology roadmap. Product and technology roadmaps
act as input to each other. As can be seen from the sampling of required inputs shown
in figure 1, roadmapping depends on a close inter-linkage and mutual learning with a
broad spectrum of analytical and action-focused planning and organizational activities.
These run the range from mission and strategy setting processes to those concerned
with implementation and communication of the strategic plans to a variety of analytical
inputs, on customer needs, competitive considerations, etc., with some of the inputs
having both analytical and action dimensions, e.g., market segmentation.
The richness implied is more than just a question of process complexity. These
input, and related output, requirements bring the roadmappers into relationships with
players and stakeholders from organizational units with differing organizational
experiences and knowledge bases, imperatives, incentive structures and cultures in a
context in which the “arms-length” and “throw-it-over-the-wall” approaches cannot
work.
A generalized roadmapping process can be described in terms of three phases.
Phase I: Define the Content
The first phase involves ensuring that there is a perceived need for, and a good
understanding of, the roadmapping process and that resources from the most affected
teams will be available. A preliminary review of the availability of the necessary
information should also be undertaken, but it is necessary that the information available
be used and that separate views not be developed exclusively for the product
technology roadmap development. Buy-in by the most affected units is a prerequisite
[Kappel, Radnor and Peterson, 1997.] Due to the time intensity and therefore the costs
of the first iteration, leadership/sponsorship by a high level executive from the unit that
will benefit most from the results of the decision making is necessary.
Roadmap scope and boundaries need to be identified and defined. This step
ensures that the context for the roadmap is appropriate and that it dovetails with the
enterprise strategy. That, in-turn, allows a small team e.g., of five or six representatives
(assuming a large multi-product company) of the appropriate business management,
marketing, and development teams to engage and, thereby, ensure that the appropriate
planning horizons and boundaries have been considered.
Phase II: Development of the Product Technology Roadmap
11
11
The second phase is the actual development of the product technology roadmap.
This is often undertaken in a series of distinct steps.

Identification of the "product" that will be the focus of the roadmap. Typically, this
means roadmaps will be developed for major or flagship products. The chief
technology officer of Bell Labs, Bob Martin, has indicated “By early 1998, roadmaps for
50 product lines should be completed” [Lucent Headline News, 1997.] The single most
critical step in roadmapping is to get the participants to identify and agree on the set of
customer needs driving the features and functionality for each of the products.

Specification of the critical system requirements and their targets. Since the product is,
by definition, complex, there will be multiple components, enabling technologies and
subsystems that the roadmap must address. Product/system design needs to be
focused on meeting customer critical needs by aligning appropriate clusters of
technology to address each of the needs identified in step 1. The critical system
requirements provide the overall framework for the visualization and are the high-level
dimensions to which the technologies relate.

Identification of the major technology clusters. These are the major technologies and
enabling components that help achieve the critical system requirements for the product.
Examples of technology clusters in the electronics sector may include enabling
technologies for software, physical interfaces, displays, power subsystems, design size
(i.e., miniaturization) and quality and reliability. Clusters need to be designed to relate
to the quality and cost requirements of the customer.

Specification of the enabling technologies and their performance targets. At this point,
the critical system requirements are translated into technology requirements for each
customer driver. These technology requirements are the critical variables that will
determine which technology alternatives are needed to deliver the necessary system or
product performance to the customer over specific time frames. Once identified in the
visual, the answer to technology requirements becomes more obvious. The system has
been designed to meet the essence of the customer drivers, and that simplifies the
technology evolution problem. How the product is to evolve and what technologies are
currently contributing to address those needs of the customer are specified. Time-line
estimates for transitioning to changing component and other enabling technologies
with improved price performance or capabilities can then be established. The
technology drivers and their targets are specified, and the alternative technologies that
can support those targets can also be identified. Some technology alternatives may
impact multiple targets and some may not yet exist. For each of the identified
technology alternatives, a time line estimate for its availability and for how it will
mature with respect to the technology driver targets is required.
12
12

Identification of the current relative capabilities of the firm with respect to the enabling
technologies and their performance targets. This can then lead to recommendations as to
which technology alternatives should be pursued via internal funding. This step selects
the subset of technology alternatives to be pursued. The assumption is that if a
technology is not critical, or if the firm is not willing to invest in developing a
competence in the critical enabling technology, the business development function
should be tasked with establishing a relationship that will ensure access to the
technology for the period in which the technology is needed. Technology alternatives
will vary in terms of quality, cost, schedule, and/or price performance. In some cases,
there may be company proprietary analytical and modeling tools to help determine
which technology alternative to pursue and when to shift to a different technology (i.e.,
when to jump to a new technology “S” curve.) In all cases, the trade-offs must be
determined by the product technology roadmapping team to assure congruency and
commitment to customer needs.

Creation of the roadmap visuals. In addition to the actual technology mapping to
customer drivers, where commitments have been made and where near term funding
decisions are required needs depicting. These techniques allow the appropriate
decision-makers to translate the mysteries of technology into workable considerations
that have real investment and time constraints. For example, an investment priority
analysis matrix can be constructed with a vertical axis of “rate of cash generated or
used” (by roadmap technology cluster or development project) and the horizontal axis
of technology availability and development, with time frames of 1-2 years, 3-5 years
and 5-10 years. The resulting matrix would chart impacts of technology investment
during the identified time frames. Visually, the roadmap identifies and describes each
technology area and its current status and specifies any potential discontinuities or
critical decisions that, if not made, will jeopardize the projected business plan market
share and contribution commitments.
Figures 2 and 3 here
Figures 2 and 3 give hypothetical examples of such a visual presentation. The
changes expected and/or needed in core technology areas that support the needs and
performance demands of the customer. The important components, subsystems and
enabling technologies, i.e., the technology clusters, are each described in a time horizon
(row) on the matrix. The cells in the middle show the expected evolution of the
technologies. The technologies can be shaded according to whether or not internal
funding commitment to the next improvement in the technology has been made. (This
provides a natural link to the more detailed development project plans but shading
could also be used to highlight other significant planning concerns.) Each technology
cluster is then identified by importance and relative competitive position of the firm
(now and in the future.) Then, based on the firm’s need (the importance of the
technology cluster) and the firm’s capabilities, decisions concerning funding or sourcing
13
13
of the enabling components can be reviewed. Such roadmapping allows quick
executive review and, done properly, prompts the asking of what one Bell Labs director
described as the “right questions.”
Phase III: Follow-up Activities
The third phase is the use of the roadmap to better mange the business. This
assumes that the roadmapping process provides positive results and provides a means
to mange, control and then follow-up on customer-driven product technology
decisions. As is done at Lucent, business unit roadmapping teams can be recognized
for having a product technology roadmap, for reviewing the roadmap with other key
stakeholders (such as Bell Labs researchers), and, importantly, for using the roadmap to
manage the business.
Some key steps here in this last phase involve:

Critiquing and validating the product technology roadmapping experience. This
requires that the output be reviewed with other affected teams and that validation, if
not consensus, concerning probable technology solutions is achieved.

Implementing the technology recommendations. After review, there will be a plan of
record concerning technology selection and investment. Executive review and
decisions concerning the development and sourcing recommendations can now more
readily be made. One approach to dissemination is, as noted, to post the roadmap, on
the intranet in a read-only format enabling it to become a real time “plan of record”, one
of the ultimate communication tools.

Maintaining, Monitoring and Updating. To retain legitimacy, roadmaps and plans
need to be maintained in real time and updated as changes occur. In addition, it is
usually recommended that a periodic review cycle be established. It can be helpful to
rotate new members onto the core team periodically to add fresh views concerning
needs and technology and to allow some non-incremental “out-of-the-box thinking”,
without disrupting organizational acceptance of team output.
2.6 Issues and Shortcomings
From the above process description, it would seem to follow that roadmapping
must be approached differently across the variety of organizational settings found in
practice. Organizations with strong, independent functional or technology units often
develop limited roadmaps geared only to the individual function or technology.
Similarly, organizations with cultures that discourage sharing of information have
14
14
difficulty in creating cross-business and common technology roadmaps. Other issues
include:
• Roadmapping may be viewed as a stand-alone deliverable that is often
initiated in response to a specific perceived crisis or need and may not
become inculcated into on-going management. Even when the desired
shared understanding is achieved in the process of developing the roadmaps,
particularly in dynamic and volatile conditions, such understanding must be
continually renewed to maintain the proper foundation for decisions.
• When the perception is that policy or assignments change suddenly and
arbitrarily, there may be little incentive to design or implement roadmaps. A
major cause of frustration on the part of R & D and other personnel
expressed in our interviews stemmed from what appears to them to be
arbitrary and sudden policy changes. They indicate that they could prepare
for a range of possible requirements if alerted to their potential need in
advance. When high volatility and rapid, systemic and unanticipated change
challenge planning, roadmapping can become unwieldy. Companies may
attempt to over-plan details. The effort to make the complex manageable can
then draw operational planners into an overly narrow, linear focus that limits
the sought-after innovative and effective response to change.
• Lack of explicit assumption sets concerning future needs may shift the focus
from the needs of the customers to the eloquence of the technology, i.e., the
comfort zone of the technical community.
• Critical gaps surface in knowledge and foresight regarding future conditions
and events. Managers often lack experience and may be uncomfortable
working in such unconstrained space. Strengths and opportunities may also
be overlooked due to lack of information or inadequate environmental
monitoring and analysis, particularly under the pressures of intense global
competition.

Important underlying and contextual factors related to the roadmap may
require presentations by, or discussions with, the roadmap developers to be
communicated.
2.7 Roadmapping Summary
Roadmapping is a valuable management tool in an increasingly complex
competitive environment. It allows the technologist to identify a technological solution
to a problem while allowing the market to ultimately define the form the solution takes.
It can provide simplicity and clarity when technology investment decisions are not
15
15
straight-forward. Properly designed and implemented, a roadmap can enable response
to customer demands for immediate change (particularly when changes are linear
and/or incremental.) Roadmapping is especially useful when the products and systems
are complex and when decisions must be made between several viable technology
options.
Further, the techniques allow the appropriate executive to translate the mysteries
of technology into workable considerations that have real investment and time
constraints. The roadmap is a visual tool that identifies and describes specific customer
requirement-driven technology clusters and specifies potential discontinuities and
critical requirements related to technology decisions. It can also flag decisions and
investments that will endanger plans and management expectations. Roadmapping can
be hindered by organizational cultures and structures as well as by poorly
communicated or strategic decision making that is perceived to be erratic.
3. Explicating the Scenario Planning Toolset
3.1 Definition and Context
In rapidly changing, uncertain and volatile times, companies need a means to
anticipate, assess and prepare for potentially dramatically different conditions.
Scenario planning is approached somewhat differently in different sectors and
companies. It differs from other commonly used planning methods such as
contingency planning and sensitivity analysis. Where contingency planning considers
an isolated uncertainty, presenting a base case with an exception, scenario planning
analyzes the potential impact of a number of uncertainties in combination. Similarly,
sensitivity analysis is concerned with what will happen if one variable changes with no
changes in other variables. Scenario planning illustrates the effect of several changes
happening at the same time [Shoemaker, 1995.] It is particularly useful when
uncertainty strains managers’ ability to predict developments with confidence, when
the company is having difficulty envisioning new areas of opportunity and when a
common language is needed to reconcile strong differences of opinion, where each
opinion has merit [ibid.] As a Motorola manager expressed it, this tool is best applied
to issues where the outcome is not predetermined and can evolve in fundamentally
different ways, where change is not under the control of the company, where the
change may be structural and long-lasting and where decisions may be difficult to undo [Motorola, 1997.]
3.1 What is a Scenario?
16
16
The tool seeks to develop vivid, detailed and internally consistent pictures of
diverse plausible futures relevant to a central issue. By “living” in these “worlds,”
managers can see unanticipated ripple and composite effects of changes. In the course
of development and analysis, biases and assumptions in strategic planning can be
challenged and managers forced to detail their own world views which are influencing
their decisions. They are able to “rehearse the future”, to develop new, more
appropriate mindsets [Schwartz, 1991.] The scenarios also provide novel contexts for
data acquisition by raising new questions. As one author puts it, “Scenarios help to
change the threshold of attention by creating a new sensitivity to relevant information a widened field of perception - so that this expanded range of knowledge can more
quickly become part of the thinking process of an organization “[Simpson, 1992.] As
discussed further below in considering additional tools, if knowledge can be classed in
terms of things we know, things we know we don’t know and things we don’t know we
don’t know, scenario planning helps the second but also, particularly, helps expose the
third [Shoemaker, 1995; Radnor, 1991.]
Figures 4 and 5 here
Typically, 3 - 4 scenarios are developed for each focal issue. Dimensions may
span economics, political, societal, technological, legal and industry factors. Figures 3
and 4 show two variations in approach. Often (as evident in figure 4), the scenarios are
captured in terms of a matrix with four axes, each axis representing diametrically
opposed conditions. Strategic implications are detailed for each axis, potentially
including likely resource requirements. Indicators that can signal that the scenario may
be coming into reality are also provided. In the example in figure 4, two dimensions are
depicted. On the horizontal axis, different potential industry setting are indicated - one
characterized by technology and product convergence and integration, the other
continued or even increased stratification. The vertical axis considers the geopolitical/economic environment where growth and opportunities are seen to come
from advanced or emerging economies. In this way, four quadrants are established
each representing a distinct scenario “world.” Multi-divisional companies may develop
corporate or platform-wide macro scenarios that act as an umbrella under which
corresponding SBU level micro-scenarios can be designed. This both enhances the
applicability to the business unit’s specific market and technology variables and
encourages buy-in by SBU managers [Wilson, 1992.]
3.2 Scenario Planning Process
This section provides an overview of steps commonly used in developing and
using scenarios [see Schwartz, 1991; Wilson, 1992; Shoemaker, 1995; also augmented in
previously cited Motorola discussions.]
17
17
 Defining focus is done in different ways. The first step is customizing the approach
to the specific needs and interests of the company. This includes selecting the target
issue, and defining the scope for scenario development in terms of point in the
future in which the scenarios take place, number and breadth of scenarios (and time
and resources to be allocated to their development and analysis) and the nature of
developments to be explored (i.e., new technologies and products, social/market
developments, competition, etc.) Some companies structure scenarios in terms of
the type of indicators they need, such as strength of key competitors, rate of market
growth, etc. [Boroush and Thomas, 1992.] Wilson describes “targets of opportunity”
or contexts in which scenarios will be used. Like us, he suggests that scenario
planning should be an integral part of strategic planning and that firms should,
implicitly, as part of the specification of issues, consider how corporate changes
indicated by the scenarios will be made [Wilson, 1992.]
Clearly this step is critical and a premise of this paper, as discussed under issues
for the proposed composite approach, is that, often, inadequate attention is given to
what goes into this decision. Too narrow a focus can restrict the desired mindexpanding output of the exercise. But too broad a focus can lead to difficulties in
selecting scenarios to analyze, vagueness in scenario detail and an increase in the
frequently already high level of skepticism encountered from corporate and,
particularly, operational, managers. As will also be discussed further below, it can
be vital to identify and question, to the extent feasible, underlying assumptions and
mindsets that lead to the determination of issues. Even though the scenarios are
intended to challenge assumptions, they may be skewed by assumptions already
embedded in the specification of targets.
An important pre-step or closely related step with similar concerns, is the
determination of individuals or, more typically, teams that will design the scenarios.
The make-up of the teams in terms of positions, units, levels and personalities
represented can have significant impact on results and eventual use of scenarios.
 The step of defining relevant environmental drivers/key decision factors should
specify the possible forces and uncertainties that impact on the system and its
environment or the focal issue. This could include demographic trends, social
unrest as a result of change, shifts in political power or regulation, market or
distribution system changes, emergence of new competitors or substitute
product/processes (using same or different platforms or core technologies),
technology shifts, etc. It is important that as little as possible be initially left out.
Often, the development of these factors is done through brainstorming. Only then
(sometimes described as a separate step) are the drivers ranked in terms of greatest
impact as well as greatest uncertainty. A limited number of factors are selected as
top priority. It is generally recommended that these should allow for the greatest
possible diversity in scenarios.
18
18
 The next step is usually the development of the framework or axis for the scenarios.
These cover the set of possible options highlighting central points of differentiation.
Examples given by Motorola include: global/regional, central/distributed,
regulated/deregulated.
 Finally, before scenarios are constructed, the framework is usually checked against
the focal issue and the major driving forces to ensure all are potentially covered and
that the framework is fundamentally logical.
 Scenarios are then developed (‘fleshed out”) for each axis. They are checked for
internal consistency and, on a basic level, for plausibility. While it is important to
cover the range of possibilities, it is neither desirable nor feasible to consider all
possible variations. Indicators are also specified. Some also develop scenariorelated forecasts suggesting trends and events which are fundamental to the
scenario and a loose timeline with estimates as to when such developments may
occur.
 Strategic implications of each scenario are developed. These are company- specific
and if micro-scenarios are developed, point to unit-specific issues. Often strategies
and resource allocations to address scenario requirements are recommended. (These
rarely have the depth of roadmaps.) Motorola may ask scenario teams to
specifically identify variations and implications in their scenario compared to a
central set of data points. In another example, during a recent simulation in the
Network Systems group of Lucent Technologies, interfunctional teams of business
and technical managers were formed to address emerging communications
networking opportunities. Each team was assigned a type of core technology and
given the task of fleshing out technology scenarios under the assumption that they
were part of the company that had a market profile and business structure similar to
the market leader employing that technical solution. The resulting technology
evolution plans, product solutions, and offensive and defensive strategies were then
compared to current Lucent plans. Value-added from this approach included
encouraging Lucent managers to think not like Lucent managers, but more like
strategic competitors.
 Finally, in the process as usually defined, the variations and strategies are
aggregated and used to form a single strategy which could be used across the
scenarios. Caveats are often indicated. Motorola for example often develops
specific “hedging” strategies to offset critical extremes or vulnerabilities not covered
sufficiently in the central strategy. Implicitly - and only at this stage - the various
scenarios may be given weights as to likeliness of occurring. It is naturally critical
that the indicators devised are fed into an environmental monitoring system and
that the scenarios are periodically revisited.
19
19
In what appears to be a very useful addition, Shoemaker explicitly adds the
development of ‘learning scenarios’ with specification of areas needing further research
including examination of possible blindspots [Shoemaker, 1995.] The need for this is
approached in more detail below. “Competency roadmaps” suggested in this paper
would relate well to such scenarios.
3.3 Issues and Shortcomings
Several factors may hinder successful design and use of scenarios. These include:
poor focus; insufficient commitment to the process and involvement on the part of
senior management (resulting in poor participation and poor eventual acceptance by
lower level management.) It is also suggested that buy-in from lower levels can be
critical and is facilitated by their direct participation in the scenario design process macro or micro-scenarios.) Simpson believes scenario planning should be done by line
managers rather than being left, as it often is, to the corporate planning department
[Simpson, 1992.] Scenario planning is a tool rather than a distinct organizational
function and since, at least in principle, its philosophy and assumptions are already part
of good strategic planning, it could (but often is not) be utilized at different levels
throughout the company. Other hindering factors can include: too much focus on the
scenario itself and too little attention on communicating the decision context in which it
developed (where the relevance is clear); ruffled feathers as scenarios challenge current
skills, knowledge and expertise; and the time and effort required to develop and assess
scenarios [Schreifer, 1995.] Similar organizational problems are experienced in
company efforts to promote earlier management science initiatives [see, for example,
Radnor 1972.]
4. The Rationale for a Composite Approach
Done properly, roadmapping can act as a foundation enabling a company to
respond to varying customer demands for new product features, functions and price
points. Similarly, scenario planning output should include: specification of resource
requirements and specific action appropriate to each scenario; the elements for a robust
strategy capable of addressing the range of scenarios envisaged; and, detail of likely
variations in the strategy - when indicators show a specific scenario is occurring. But
rarely does either approach achieve this potential.
Scenario planning could enhance the flexibility and vision of roadmapping and
enable anticipation of a broader range of possible changes. But scenario planning is
often poorly received by operational managers and R&D personnel who see it as too
soft, lacking in hard data and not relevant to clearly pressing concerns. As already
20
20
noted, scenario planning has generally been performed as part of corporate planning
and is rarely packaged to be readily applied with the detailed strategies, steps and
directions desired by operational managers. Linking to the integrative and operational
capabilities of roadmapping could address this weakness. (Relatedly, a link to strategic
benchmarking and/or portfolio management could also be valuable and a firm set of
internal metrics is needed, but these subjects will be left for another paper.)
Again as noted, both tools are challenged from the outset by poorly recognized
and articulated underlying assumptions and resistant corporate mindsets. Although
scenario planning is expressly intended to expose assumptions and their impact, preconceptions are often already embedded in the initial specification of issues.
Roadmapping teams are frequently hampered by the failure to recognize, anticipate or
effectively communicate potential changes with sufficient time and context-rich
information and direction to enable the appropriate inclusion in roadmaps. Such
breakdowns can often be traced to how companies and individual units perceive their
core business and their environment. This can be an important issue in the case of
industry roadmaps which, while intended to expand thinking and alert companies to
future requirements and opportunities, are constrained by the definition of the industry
domain. Perceptual limits of this type were explored in an earlier paper in the context
of technology development, adaptation and acquisition decisions [Radnor, 1991.]
figure 6 here
How difficult this perceptual topography of issues is to deal with is illustrated in
figure 6. “A” indicates the firm’s core business area, a domain in which a company
would generally be able to recognize its weaknesses. Even in its core business domain,
however, there are often perceptual “black holes“, indicated as “B” that are
unrecognized and are therefore potentially very dangerous “blind-siding” gaps.
Surrounding the core is a “recognized periphery”, “C”, where related but different
products and technologies are to be found. There are no significant personal or
organizational costs to admitting weaknesses in this area. The “unrecognized periphery
“, “D”, is similar to “B” but here the threats (and opportunities) are specifically from
new competitors or new technologies, etc. that could hurt the company. Finally, “E”
signifies new fields being developed or becoming relevant to the core business domain.
Although companies, particularly larger firms, are often aware of such developments,
they are only beginning to appropriately include them in scenarios and incorporate
consideration of their strategic implications in roadmaps.
Granstrand, Patel and Pavitt [1997] found that companies are becoming
concerned about important gaps in their experience-based knowledge and competency
in fields that extend beyond their product lines. Their study observed that large
companies in particular, are being pushed to expand their competencies well beyond
current core areas to address emerging market opportunities (and, implicitly, threats)
21
21
and to better select and manage suppliers and sub-contractors needed for new systems.
In turn, we recognize that it is often small companies that lead the way in developing
new fields and applications. Responding to this, several large firms have set up special
units to invest in and link to entrepreneurial firms. In concert with the above
discussion, a few firms are beginning to explore designing roadmaps that identify gaps
and potential and plan expansion into new technology and knowledge areas (including
assessment of organizational implications.) Such “competency roadmaps” can enhance
a company’s competitiveness and be a further bridge between product roadmaps and
scenario planning. The explication of such a roadmap is left for a future paper.
Relatedly, when business, economic, social or political environments change in
significant and unanticipated ways, long-standing and accepted procedures and
organizational relationships can, and should be challenged. But these procedures and
relationships are often not explicit and may not even be consciously recognized.
Different future scenarios may require significant organizational changes up to and
including shifts in business concentration. Through scenario planning, Motorola
recognized fundamental competitive vulnerabilities and is currently restructuring key
activities in a major business unit [Motorola, 1997.] Burgelman and Grove describe
discontinuities that may occur in terms of where strategy takes shape and how it is
implemented in an organization in response to different levels of awareness of market
changes. Such discontinuities tend to come to a head at “strategic inflection points”
where one key strategy or a core technology is supplanted by another. They describe
these points as creating a “valley of death” for supporters of the old approach because
growth trajectories, plans and competitive behavior patterns are fundamentally
challenged [Burgelman and Grove, 1996.] Nonaka, similarly, discusses the initially
disruptive but potentially positive impact of introducing new perspectives to teams
[Nonaka, 1991.] Christensen adds that some sustaining technologies clearly are so
expensive to develop and implement or so dependent on rare resources or proprietary
expertise, that some companies cannot successfully manage the transition [Christensen,
1997.]
To enable the proposed composite approach to work optimally, a deeper level of
analysis and understanding of how the organization has functioned and how
adjustments can be made smoothly is mandated. To address such concerns, additional
micro and macro-organizational analysis approaches are suggested.
5. Additional Tools for a Composite Tool-set
Linking the strategic environmental monitoring and planning (as we saw was
implicit in scenario planning) with the operational processes involved in innovation
project selection (and portfolio management), execution and transfer into use (that are
22
22
implicit in roadmapping) has always been a major challenge [Roussel, Saad and
Erickson, 1991; Rubenstein, 1989.] Such linkage is a fundamental aim of the composite
approach being proposed. As already stated and as will be further noted below,
roadmapping is an integrative “linchpin” process, and as such demands the
involvement of a network of players and stakeholders to be effective. Typically, firms
seek to achieve this through the use of cross-functional teams. Scenario planning as a
strategy development modality with important guidance linkage into environmental
monitoring also needs to reach across organizational functions, again generally
attempted through the use of cross-functional teams, but for different reasons.
Although similar sounding, the make-up and rationales for the teams used in the
two cases need not be, and generally are not, the same. In the case of scenario planning
a key goal is to obtain a richness of knowledge and creative thinking and perhaps “buyin” facilitation. Some rotation of personnel through temporary teams is often seen as
desirable to sustain “freshness.” Indeed as noted, it is common to include people from
outside the organization on scenario development teams. Yet, buy-in by upper and,
implicitly, operational managers is important if scenarios are to have the desired impact
on organizational planning and thinking. In roadmapping, while knowledge and
creativity are still critically important, buy-in by stakeholding operational players is
crucial and explicitly recognized; achieving a pervasive consistency over time is
important while the issue of team member turnover may be secondary. In both cases
however, the team solution is founded on an essentially extra-organizational project
team approach rather than one embedded into the essential fabric of the organization,
with all the attendant problems of legitimacy, responsibility, etc. Ultimately, if an
organizational routine is to succeed in pervading organizational thinking and practice,
everyone who should be involved is and, for many, on an on-going basis. How is this
to be achieved?
For the last two years, the NCMS consortium mentioned above, has been
evolving an approach that focuses on this type of challenge but concentrating on the
management of technology. Its five essential elements are:
1. Process Identification i.e., a model of those processes needed for a firm to
successfully carry out the full array of activities that enable it to: monitor and
respond to environmental conditions; translate this intelligence into general and
technology strategies reflective of its goals and competencies; translate and
communicate these to those who evolve and execute project portfolios; and,
transfer of the technologies for use to internal and external customers, and more.
Though this is easy to think of this as a linear sequence of steps, in reality, the
processes link in very much of a non-linear and interactive manner. For
simplicity, the model is currently structured to reflect corporate, business unit
and R&D levels of consideration, with an initial 27 processes that are defined
independently of how a given firm may be organized. Each process is described
23
23
in terms of required activities, linkage to other processes, stakeholders, typical
issues that arise, metrics, etc. What is known from the literature regarding such
processes and inter-process linkages has also been identified [NCMS, 1996.]
figure 7 here
2. Inter-process Linkages are shown in the MOAD diagram (figure 7.) An
important feature of this network model is the concept of “linchpin” processes
that act as system integrators. These have been identified, both conceptually and
empirically as “Roadmapping”, “Voice of the Customer”, “Portfolio
Management” and “Technology Transfer”. The process linkages for
roadmapping are shown in figure 8.
figure 8 here
3. Root-cause Process Analysis by which an issue or a specific process can be
analyzed in context by tracing the pathways back from the point of focus across
the organizational process network. Such a model might, for example, lead one
to look for the causes of a technology transfer problem to an inconsistent and
unclear strategy process as well as to the relationship problems between sender
and receiver on which researchers and consultants normally focus. This rootcause contextual basis is central to the identification of “best practices” and
“metrics”.
4. A Literature-informed/Practice-based foundation for conclusions. This feature
applies not only to the thinking being evolved by the NCMS project but also by
the collaborative academic/industry manner in which the project is being carried
out.
5. Lessons learned from the experience of core participants in implementation and
modification. This involves “rapid process prototyping” to adapt lessons
identified while using the practices and processes in the mid-to-large company
environment.
This MOAD approach provides our present endeavor with an organizational
process network mapping. It can be used to consider the information requirements and
flows and commensurate learning needed across the whole firm if the proposed
“blending” of toolsets is to be possible over an extended period and under fluctuating
conditions. It can also point to key players at critical parts of processes that may not
otherwise be recognized as important members of roadmapping and scenario planning
teams (of course, individual power and personalities must also be considered.)
24
24
Two other aspects of the approach may be of fundamental importance for us
here. The model emphasizes the role of roadmapping as a key integrative organizationwide planning process, while the scenario planning is recognized as a modality
embedded within the strategy making process. It strengthens our view of the direction
in which the “blending” we have proposed needs to happen, i.e., towards an enhanced
roadmapping process that is knowledge-rich and non-linear. By enabling cross-firm
root cause analysis, the MOAD model also provides the means to identify how and
where the environmental changes will impact, and when. It also indicates the likely
intelligence points where key alerts and indicators may become manifest and can be
helpful in pointing towards the needed integrative structural arrangements.
The MOAD also facilitates navigation across the different key activity domains of
an organization. Thus, strategic planning and environmental monitoring are done (and
indicated in the MOAD) at the corporate, the business unit and the R&D levels.
Implicitly, scenarios as a methodology in strategic planning should impact on each of
the above levels in terms of their environmental monitoring activities. Roadmapping,
done primarily in the business units, should link to activities at each of the levels. The
goal would be to actualize the high-level scenario and roadmapping exercises in such a
way that they can become institutionalized into the organizational fabric, but still
protect, for example, the continuing need to enhance and sustain the important, but
differing, “out-of-the-box” innovativeness required for each toolset. This MOAD
approach may be a key facilitator to make the desired result feasible. Much additional
research and new organizational design efforts will be needed and is planned and
organizations applying MOAD analysis must customize it to their unique processes and
procedures.
On a more macro-level, with modifications, a heuristic developed at Kellogg for
assessing emerging economy planning provides similar, but more basic, guidance in
identifying corporate drivers, defining characteristics and underlying assumptions,
requirements, vulnerabilities (“stress points”) collected as “flags” where change could
impact, and strengths (“opportunity points”) [Radnor and Strauss, 1997.] As in the
MOAD analysis, this heuristic applies a root-cause methodology. The use of both
analysis tools in conjunction with roadmapping and scenario planning is illustrated
below.
6. Explicating the Blend, an Illustrative Heuristic
The following illustrates how the various tools could be integrated. It is
important to emphasize that though presented as a sequence, the “steps” are highly
iterative and several activities may occur concurrently. Thus, preliminary identification
of target issues iterates back to the identification of corporate drivers, stress and
25
25
opportunity points and underlying concerns, allowing refinement and focus on relevant
needs.
How a company would actually use this approach would vary based on current
practices including the extent to which roadmaps already exist or are in the pipeline,
and the organizational structure and culture. The following assumes roadmapping and
scenario planning will be developed concurrently in a phased approach converging
toward and iterating with each other and supported by the other tools discussed. For
simplicity, only macro-level scenario planning and an individual roadmap is
considered. In actual practice it is likely development of, and integration between (in
the new context) multiple roadmaps and micro-scenarios (at the business unit level) will
be desirable. It is also assumed that scenario planning and roadmapping teams will
overlap in membership, facilitating iteration and exchange of insights as they surface,
and scenario development will be carried out with roadmapping in mind.
Key goals of the heuristic include encouraging new and deeper dialog between
stakeholders within the organization and recognition of underlying issues and
potentially limiting perspectives. At each “step”, the company should,
at a minimum, question:
Is this an over-riding concern?
What does this require or assume?
Is there an underlying issue?
What else (e.g., other processes) relates to this?
What change would significantly impact?
What could cause this change or accentuate it?
How would this change impact on my organization?
How could I prepare for or prevent such a change?
Would this open new opportunities?
What would taking related action mean for my organization (e.g., create other
stress points?)
Does this change my thinking related to another part of the heuristic?
Such questions should be iterated, “root cause” analyzed and, as issues are initially
selected for the composite process, development teams should seek input on them from
relevant stakeholders.
The output of the heuristic is a roadmap complete with flex points where
adjustments may be needed based on macro and micro-level assessment (using the
analytic tools noted.) It would indicate vulnerabilities to change and strengths that can
be exploited under different conditions. Scenario requirements would be specified and
linked to forks where parts or all of the roadmap may diverge based on indicators that
the scenarios are occurring. A more detailed heuristic is under development.
The flow of the heuristic is shown in figure 9.
26
26
figure 9 here
The sample heuristic includes the following steps:
•
Identify corporate drivers and company profile relative to its industry. (See note
below for detail on this point.)
•
Using the MOAD model, identify relevant processes (particularly related
lynchpin processes), assess the impact change could have at each point in the interlinked processes.
•
Specify underlying assumptions, stress points, opportunity points and flags
(items requiring further research or thought.)
•
Assess drivers of change in the environment (iterate with above)
•
Define initial issues for composite approach (iterate back through above analysis
and refine issue selection.)
•
Develop preliminary roadmap, identify issues if change occurs during roadmap
implementation (preliminary flex points.)
•
Develop scenarios (from issues but building on/challenging specified
assumptions stress/opportunity points and changes envisioned above.)
•
Iterate back to evolving roadmap (and re-visit corporate drivers and
assumptions.)
•
Identify indicators, likely timelines. Create central strategy and specify
variations for each scenario.
•
Refine roadmap, specify forks (and variations in roadmap as divergences take
shape along forks.)
Additional detail regarding the first item above, corporate drivers and company
profiles could include specifying:
- defining characteristics (a complex concept which may include core
competencies but goes further in specifying what the company believes
defines itself),
- risk tolerance, need for control (and over what),
27
27
- dependencies (resources, including key personnel and other strategic assets.
but also suppliers, partners or others upon whose actions the company
may depend),
- competitive and strategic position (innovator/leader, follower in terms of
technology development or follower of a key customer, cost/return
expectations),
- constraints (resource limitations, fundamental requirements, where a
company “draws the line”),
- objectives (including time frame considerations.)
“Drivers” also questions what fundamentally determines company activity (quality,
costs, technology superiority, service, unique market channels, etc.) It is recommended
the company consider similar factors for their industry and key competitors.
7. Concluding Comments
The twin roadmapping and scenario planning toolsets firms have been recently
using have the potential of providing operational and strategic level managers with
substantial assistance. But their inherent limitations have also been indicated, especially
when the tools are not well implemented or well linked. This is particularly the case
under highly fluctuating conditions. How these and other toolsets can be married to
overcome the weaknesses, deepen awareness of underlying issues and strengthen the
planning and implementation process has been demonstrated. The application of such
an approach can enable teams and companies to achieve the intuitive shared experience
of meaning that Nishitani [1982] deems critical to true understanding. They can also
enjoy the creativity and competitiveness Nonaka [1991] envisions, while creating the
needed foundation and process for making concrete and effective decisions. We have
made the case for a more robust and dynamic approach and, hopefully, taken a step in
that direction. The research on which the thinking and findings have been based is ongoing and can be expected to result in further developments. In this spirit,
collaboration with others concerned with the issues discussed and able to contribute
additional empirical inputs will be highly welcomed.
8. References
Barker, D. and D. J. H. Smith. 1995. Technology Foresight Using Roadmaps. Long Range Planning
28:2.
28
28
Boroush M. A. and C. W. Thomas, 1992. Alternative Scenarios for the Defense Industry After 1995,
Planning Review 20:3.
Burgelman, R. A. and A. S. Grove, 1996. Strategic Dissonance, California Management Review,
Vol. 38, No. 2.
Christensen C., 1997. The Innovator’s Dilemma: When New Technologies Cause Great Firms
to Fail, Harvard University Press, Boston MA.
Cochrane J. I., J. E. Temple and J. W. Peterson, 1995. Shapes and Shadows of Things to Come,
Proceedings of Telecom ‘95.
Eriksen, L., J. Peterson, and K. Wofford, 1998. On Recreating the Enterprise Technology
Management Infrastructure. International Association for the Management of Technology,
Orlando, February 1998.
Georgantzas, N. C. and W. Acar, 1995. Scenario-driven Planning, Quorum Books,
Granstrand, Ove, Pari Patel and Keith Pavitt. Multi-Technology Corporations: Why They have
“Distributed” Rather than “Distinctive Core” Competencies. California Management Review.
Summer, 1997.
Groenveld P., 1997. Roadmapping Integrates Business and Technology, Research-Technology
Management, 40:5.
Kappel, T., M. Radnor, and J. W. Peterson, 1997. Management of Technology through Roadmapping
Tools, Product Strategy Summit ‘97, Management Roundtable. Waltham, MA.
Levin, D. Z., M. Radnor and M. Thouati, 1997. Using a Process View of Organizations to
Understand the Management of Technology. Paper to Annual Meeting of Academy of
Management, Boston.
Lucent Headline News 1997.
Motorola 1996. Presentations at Kellogg School, Northwestern University.
NCMS, 1996. Management of Technology: Feasibility Study, Ann Arbor, MI.
Nonaka, Ikujiro. The Knowledge-Creating Company, Harvard Business Review. NovemberDecember, 1991.
29
29
Nishitani, Keiji. Religion and Nothingness. Translation, Jan Van Bragt. Los Angeles:
University of California Press. 1982.
Peterson, J., 1997. Strategy and Technology: One Company’s Experience, Technology Management.
Boston: RIA Group.
Peterson J. W., 1998. Through the Looking Glass, to be published in Research-Technology
Management, 1998.
Perottet C. M., 1996. Scenarios for the Future, Management Review, 85:1.
Radnor M. and J. D. Strauss, 1997. Planning Heuristics for Emerging Economies, Kellogg Working
Paper.
Radnor M., 1991. Technology Acquisition Strategies and Processes: A Reconsideration of the “Make
Versus Buy” Decision, International Journal of Technology Management, Interscience, London.
Radnor M., 1972. Shifting Patterns of Success and Failure of Management Science in Industry,
Management Science: Interfaces 2:4.
Roussel, P.A., K.N. Saad, and T. J. Erickson, 1991. Third Generation R&D: Managing The Link
To Corporate Strategy. Harvard Business School Press, Boston.
Rubenstein, A. H. 1989. Managing Technology in the Decentralized Firm, Wiley, New York.
Schreifer A., 1995. Getting the Most Out of Scenarios: Advice from Experts, Planning Review, 23:5.
Schwartz P. 1991. The Art of the Long View, Doubleday, New York.
Shoemaker P. J., 1995. Scenario Planning: A Tool for Strategic Thinking, Sloan Management
Review, 36:2.
Simpson D., 1992. Key Lessons for Adopting Scenario Planning in Diversified Companies, Planning
Review 20:3.
Thouati M., M. Radnor and D. Z. Levin, 1998. Corporate Growth Engines: Driving to Sustainable
Strategic Advantage, to appear in International Journal of Technology Strategy.
Thouati M., M. Radnor and JD Strauss, 1998. Coupling of Technology Management and Strategic
Management Processes: The State of the Art, to appear in Proceedings of 1997 PICMET
Conference.
Weick K., 1979. The Social Psychology of Organizing 2nd ed. MA: Addison-Wesley, Reading.
30
30
Willyard, C. H., and C. W. MacClees, 1987. Motorola's Technology Roadmap Process, Research
Management, September-October.
Wilson, I. 1992. Realizing The Power Of Strategic Vision., Long Range Planning, 25:5.
31
31
9. Figures
1. Roadmaps Reflect “All the Plans”
2. High Level Product Hardware Roadmap
3. High Level Software Roadmap
4. Sample Four Axes Scenario Space
5. Scenario Planning Matrix
6. Recognizing the “Blind Spots”
7. Technology Management Processes
8. Technology Roadmapping
9. Non-linear Roadmap Heuristic Flow Chart
32
32