research

ELSEVIER Research Policy 24 (1995) 521-542

policy

Technology integration: Managing technological evolution

in a complex environment *
Marco Iansiti
Hart,ard Uniuersity, Graduate School of Business Administration, Boston, MA 02163, USA
Final version received January 1994

Abstract

We report on an empirical investigation of product development in an environment characterized by discontinu-

ous technological change. Our sample is composed of field-based observations on 27 projects and 61 technical
problem solving attempts by all leading organizations developing high performance mainframe computers. Different
organizations attained very different levels of R & D performance, as indicated by development lead time, R & D
productivity and technical product improvement. We show that the differences in performance are correlated with
skills and routines aimed at technology integration. High project performance is linked to a broad approach to
resolving critical problems, merging deep technical knowledge with a detailed understanding of the specific
environment in which the new technologies would be applied. Effective organizations are characterized by a 'system
focused' approach. The approach involves an emphasis on project specification and concept development, a number
of specific routines that probe the systemic impact of technical options on the existing capabilities of the
organization, as well as the retention of individuals with direct experience of related product introduction efforts.

1. Introduction in well-established and sophisticated organiza-

Technological evolution is a subtle process,
frequently leading to shifts in the competitiveness
of firms. Several authors have shown that p r o d u c t
d e v e l o p m e n t in an environment u n d e r g o i n g tech-
nological c h a n g e is given to frequent failure, even
* Work supported by the Division of Research, Harvard
Business School. The author would like to acknowledge exten-
sive discussions with Kim B. Clark, Takahiro Fujimoto, Re-
becca Henderson, Tarun Khanna, Dorothy Leonard-Barton,
Susan Pope, Warren Smith, Marcie Tyre and Eric Von Hip-
pel. Takahiro Fujimoto, Kim B. Clark, Warren Smith and
Tarun Khanna were also instrumental in performing the field
work. David Williams and Paul Conway of the Loughborough
University of Technology were very helpful in arranging and
performing fieldwork at the European research sites.
tions (e.g. T u s h m a n and A n d e r s o n , 1986; H e n -
derson and Clark, 1990). In this work, we argue
that the effective m a n a g e m e n t of technological
evolution in such settings is f o u n d e d on a set of
skills and routines that make up what we call the
technology integration process.
A new p r o d u c t is the fruit of the fusion of new
and existing knowledge. Novel technical concepts,
such as may arise from the science base, can be a
critical contributor of new knowledge for p r o d u c t
development. However, to be used effectively,
these concepts must be carefully selected and
a d a p t e d to match the complex requirements of an
organizations's existing environment. This is the
focus of technology integration.
Technology integration consists of the set of

0048-7333/95/$09.50 © 1995 Elsevier Science B.V. All rights reserved

SSDI 0048-7333(94)00781-2
522 M. lansiti / Research Policy 24 (1995) 521-542
knowledge-building activities through which novel
concepts are explored, evaluated, and refined to
provide the foundation for product development.
The process is integrative since managing the
relationship between new and old knowledge may
require the combination of a variety of sources of
information, from fundamental science to the de-
tails of the manufacturing environment. It is
rooted in the early stages of a development pro-
ject, and results in the creation of specifications
which define the basic technological path to be
followed in a given project. The technology inte-
gration process frames the project, providing a
critical road map to guide design and develop-
ment activities. The activities, therefore, set the
direction for the evolution of knowledge in an
organization and provide a critical opportunity
for the management of technological evolution.
This paper reports on an empirical investiga-
tion of the impact of technology integration rou-
tines on the performance of product development
projects in environments characterized by discon-
tinuous technological change. The work is based
on field investigations of organizational processes
and problem-solving activities in projects aimed
at the development of technologically advanced
products. All projects fundamentally altered the
competence base of each organization, making
use of novel technologies and causing the obso-
lescence of established capabilities.
Our analysis shows the existence of striking
differences in project performance. For example,
we found a factor of three differences in the
productivity of different geographical groups of
projects aimed at the development of similar
products (Iansiti, 1992b, 1993). However, we
found that these differences were not correlated
with traditional drivers of development perfor-
mance such as project management and cross-
functional communication. They were, instead,
related to activities that took place before the
projects had reached the design and development
stages.
The more effective organizations followed a
process characterized by several factors. First,
they exercised a distinct and explicit emphasis on
technology integration activities, and dedicated
substantial resources to their execution. Second,
they followed a specific set of routines (which we
outline in some detail below) to investigate the
broad impact of novel technical possibilities on
product functionality and production system per-
formance. Third, they dedicated to the process a
group of individuals with rich experience of previ-
ous integration efforts and a detailed knowledge
of the organization's existing capabilities. We
characterized organizations following this ap-
proach as 'system focused' - i.e. focusing on the
systemic impact of novel technical concepts. Sys-
tem-focused organizations achieved a good match
between technical concepts, product architecture
and production process characteristics. This led
to effective project execution, short development
time, and high R& D productivity.
These results show that the ability to manage
product development is not only a function of
effective planning at the strategic level and strong
project management. Success is also linked to
routines and approaches for technology selection,
evaluation and adaptation. These ensure that the
details of an organization's knowledge base evolve
in an appropriate fashion to provide the right
foundation for product development activities.
Without the right foundation, product develop-
ment projects will be plagued by poor outcomes,
low productivity and long lead times.
The paper begins by developing a set of con-
jectures on the drivers of development perfor-
mance in complex environments characterized by
discontinuous technological change. The conjec-
tures, relating organizational processes and a
problem-solving approach to development perfor-
mance, are then tested using data from a cross-
sectional study of product development in the
mainframe computer industry. Our empirical
analysis is based on 27 case studies of develop-
ment projects and 61 case studies of technical
problem solving activities, and includes all major
competitors in the industry. We end by discussing
the implications of our results.
2. Development performance under discontinuous
technical change
Our work is aimed at studying environments in
which the development of new products involves
 M. lansiti / Research Policy 24 (1995) 521-542
discontinuous technological change. By discontin-
uous, we mean that relationships between prod-
uct functionality, process requirements and disci-
plinary expertise change, necessitating a substan-
tial evolution in the knowledge base of the devel-
opment organization (as in Anderson and Tush-
man, 1990; Henderson and Clark, 1990). In this
section, we will develop a set of propositions
which analyze the effectiveness of specific prob-
lem-solving patterns and organizational processes
in this type of environment. We will claim that
effectiveness is driven by a technology integration
process which proactively encourages the thor-
ough evaluation of a wide range of technical
possibilities and design approaches. This hinges
on a broad approach to problem solving and
decision making, which is open to the evaluation
of novel possibilities and to the reorganization of
design tasks. This is rooted in the management of
project specification activities, which may precede
the bulk of product development tasks, aimed at
project execution.
Little is known about which specific product
development approaches are effective if discon-
tinuous technological evolution causes the obso-
lescence of established capabilities in the organi-
zation. Many academics have studied the re-
sponse and adaptation of organizations to techno-
logical change (e.g. Burns and Stalker, 1961; Moch
and Morse, 1977; Ettlie et al., 1984; Clark, 1985;
Abernathy and Clark, 1985; Dewar and Dutton,
1986; Tushman and Anderson, 1986; Anderson
and Tushman, 1990; Henderson and Clark, 1990).
Their work clearly characterized the adverse im-
pact of technological discontinuities (e.g. Tush-
man and Anderson 1986; Henderson and Clark,
1990). However, it did not focus on how to coun-
teract these negative consequences and manage
technological evolution proactively. Nor did it
identify which specific routines could be effective
in integrating such technological change in the
development of new products.
This academic base is complemented by a sec-
ond stream of research aimed at exploring the
drivers of effectiveness in R & D management and
product development (e.g. Allen, 1977; Allen et
al., 1980a; Katz and Allen, 1985; Keller, 1986;
Clark and Fujimoto, 1989a,b, 1991; Fujimoto,
523
1989; Cusumano, 1992; Cusumano and Nobeoka,
1992; Bowen et al., 1993). This work demon-
strates the effectiveness of several specific rou-
tines and approaches. Allen and his collabora-
tors, for example, documented the impact of
communication patterns on the performance of
R & D projects (Allen, 1977, 1986; Allen et al.,
1980b). Clark and Fujimoto identified the critical
impact of internal and external integration rou-
tines on product development performance (e.g.
Clark and Fujimoto, 1991). However, most of this
research stream was performed in environments
in which the basic technologies were stable, and
did not specifically address the challenges identi-
fied by the literature on technological evolution.
This work aims to fill some of the gap between
these two bodies of knowledge: existing research
on organizational response to technological evo-
lution, and on the management of R & D organi-
zations.
2.1. Problem-soh, ing approach
Problem-solving activities are a fundamental
engine of technological evolution (e.g. Dosi and
Marengo, 1992; Iansiti and Clark, 1993). They
drive the evaluation of new ideas and the genera-
tion of new knowledge. We therefore begin from
the basic premise that effectiveness in product
development is linked to the problem-solving be-
havior of individuals in an organization.
Problem-solving processes have been studied
extensively by a number of authors (e.g.
Frischmuth and Allen, 1969; Mintzberg et al.,
1976; Simon, 1978). Frischmuth and Allen (1969)
developed a model of technical problem-solving
emphasizing two streams of activities: the genera-
tion of solutions, and the generation of criteria
(or frames) for evaluating those solutions. They
pointed out that a characterization of both activi-
ties is essential in understanding engineering
problem-solving strategies.
Recent authors have focused on the essential
role played by frames of reference in technical
problem solving. Dosi and Marengo (1992) ar-
gued that the evolution of frames of reference is
the foundation for learning and technological
evolution in an R & D organization. Schrader et
524 M. lansiti / Research Policy 24 (1995) 521-542
al. (1992) emphasized the difficult nature of prob-
lem framing and solving in situations character-
ized by high ambiguity (see also McDonough III
and Barczak, 1992). Efficient problem-solving in
ambiguous situations will require new reference
frames to allow for a recombination of new and
old disciplinary bases.
Projects involving discontinuous technological
change will give rise to ambiguous problem situa-
tions, the solution of which may require new
relationships between knowledge bases. This will
create the need for new search procedures and
information-processing patterns. Effective prob-
lem-solving in a project characterized by techno-
logical discontinuities will therefore require more
innovative frames, involving a greater breadth
and flexibility of approach than is appropriate in
an incremental environment.
We draw on an example from the work of
Henderson and Clark (1990) to illustrate this
point. Evolution from contact to proximity mask
aligners in the photolithographic equipment in-
dustry elevated the importance of the product's
mechanical systems and changed fundamental
linkages between component characteristics and
product performance. This caused critical prob-
lems for R & D organizations and the failure of
Kasper, the incumbent firm.
The essence of Kasper's problem was the fact
that technological evolution had altered the tradi-
tional linkage between problem-solving tasks. For
example, a contact mask aligner worked by hold-
ing the optical mask pressed directly against the
surface of the semiconductor wafer. In a proxim-
ity aligner, the optical mask was held away from
the wafer, but the mask still needed to be pre-
cisely parallel to it. This created a number of
subtle new interdependencies between design
tasks. For example, it linked the design of the
mask holder to the design of the wafer-holder
system. Two technical problems which were pre-
viously unrelated now had to be framed in an
integrated fashion.
We argue that Kasper's failure might have
been averted if it had been able to detect the
required changes in the pattern of problem fram-
ing and solving. To do this, Kasper would have
had to break away from the hierarchy and parti-
tioning of design tasks employed in previous
product generations (Clark, 1985; Von Hippel,
1990a). Problem-solving efforts would have
needed to be framed broadly to probe proactively
for potential new linkages between previously
unrelated knowledge bases. This leads to our first
proposition.
Proposition 1. In a complex environment char-
acterized by technological discontinuities, high
problem-solving efficiency (and development
performance) will be associated with approaches
that sample a broad base of disciplinary exper-
tise - involving the search for and processing of
information from disciplinary knowledge bases
which were previously unrelated.
Development performance is indicated by several
variables (including engineering productivity and
development lead time), as discussed in detail in
Section 3 and in the appendix.
2.2. Project specification
Many authors have argued that problem-solv-
ing patterns will reflect the routines present in an
organization (e.g. March and Simon, 1958; Ar-
row, 1974; Nelson and Winter, 1982). Problem-
solving behavior will therefore be linked to the
specific routines that characterize the organiza-
tion's product development activities (see also
Clark and Fujimoto, 1991; Bowen et al., 1993).
We have found it useful to differentiate be-
tween two types of product development rou-
tines: 'project specification' and 'project execu-
tion'. Project specification routines set the scope
and objectives of the project. Project execution
routines carry out the steps necessary to achieve
the specified objectives. While specification rou-
tines frame the problems in a development effort,
execution routines will complete the problem-
solving cycles within the specified frames (Iansiti
and Clark, 1993). Using Clark's design hierarchy
framework, specification routines define the hier-
archy, while execution routines carry out the de-
cisions imbedded in the hierarchy (Clark, 1985).
Within Von Hippel's task-partitioning approach
 M. lansiti / Research Policy 24 (1995) 521-542
(1990a), specification routines are aimed at parti-
tioning the overall design problem into smaller
subproblems, making up manageable tasks which
can subsequently be executed.
If the knowledge base surrounding a develop-
ment project is turbulent, project specification
routines will be difficult and critical, since the
structure of problem solving for a future product
will be substantially different from that for past
products (Clark, 1985; Von Hippel, 1990b). Clark
(1985), Henderson and Clark (1990) and Von
Hippel (1990a,b) have all pointed out that a criti-
cal source of difficulty encountered by organiza-
tions in responding to novel situations is their
continued reliance on obsolete historical design
approaches, which results in the suboptimal spec-
ification of development activities.
Project specification routines tend to occur in
the early stages of a development project (Iansiti
(1991), 1992a). While it is clearly impossible to
specify all tasks completely before project execu-
tion begins, the most critical decisions regarding
the approaches to be taken in a project are usu-
ally made during the planning and concept devel-
opment stages (Wheelwright and Clark, 1992).
These decisions have an important explicit impact
on a project, since they define its principal objec-
tives. In addition, the decisions also carry a criti-
cal implicit impact, since the specified objectives
may be achievable only through the execution of
certain activities, or the development of new
competences. In a disk-drive development pro-
ject, for example, specification decisions on the
size and weight of the subsystem will explicitly
influence future design tasks. They will also have
a critical implicit impact: making the drive small,
for instance, will necessitate redesigning the me-
chanical systems and developing miniaturization
capabilities.
We argue that project specification routines
will be essential to the effective execution of
technology integration. The routines provide a
critical 'window of opportunity' (Tyre and Or-
likowski, 1991) for managing technological evolu-
tion in the organization. Once the window is
closed, the basic options and approaches will
have been selected, tasks will have been parti-
tioned and assigned, and the project will rapidly
525
build up momentum to complete the project in
the specified direction.
Making use of this opportunity is the essence
of an effective technology integration process. To
do this, established routines should proactively
induce a broad and informed approach to deci-
sion making and problem solving. The approach
should consider a variety of options, and match
these to the frequently stringent limitations of
existing systems. The approach should emphasize
the early generation of information about the
potential impact of novel approaches on the orga-
nization's capabilities. Moreover, project specifi-
cation should be kept flexible until informed de-
cisions can be made, avoiding closing the window
prematurely.
2.3. Effective management of technology integra-
tion
The effectiveness of project specification rou-
tines will be linked to the generation of knowl-
edge about the interactions between new ap-
proaches and the existing capabilities of the orga-
nization. This will involve evaluating the impact
of specific changes in the technologies employed,
for example, to establish new needs and new
constraints. The effective execution of these tasks
will require a broad understanding of the existing
characteristics of the organization. Such under-
standing will allow the recognition of new poten-
tially beneficial interrelationships between knowl-
edge bases, as well as awareness of the emer-
gence of constraints in previously distant branches
of the design hierarchy for a product.
In the example from Henderson and Clark's
work on the photolithography industry (Hender-
son and Clark, 1990), we would argue that the
essential mistakes in the incumbent's approach
were made during project specification. Hender-
son and Clark describe the problem:
Kasper conceived of the proximity aligner as a
modified contact aligner. Like incremental im-
provements to the contact aligner before it,
design of the proximity aligner was managed as
a routine extension of the product line...
Kasper's failure stemmed primarily from fail-
526 M. lansiti / Research Policy 24 (1995) 521-542
ures of recognition (Henderson and Clark,
1990, pp. 25-26).
Kasper engineers had framed and specified the
development of proximity aligners just as they
had done with previous contact aligners.
We would speculate that Kasper's failure was
not inevitable, but a consequence of its develop-
ment process. Kasper would have benefited from
a technology integration process that proactively
encouraged the re-evaluation of the existing pat-
tern of design decisions, devoting both resources
and expertise to the tasks. Kasper's process ap-
pears to have been so focused on the design of
contact aligners that it missed the implications of
the new design on system architecture. We would
argue that the failure might have been averted if
Kasper's project specification process had been
more 'system focused': if it had proactively
searched for the possibility of discontinuous tech-
nological change, supported by a broad knowl-
edge base and a flexible approach to problem
solving.
A system-focused process for technology inte-
gration first of all emphasizes project specifica-
tion tasks by dedicating adequate resources and
time to them. As with Kasper, many organiza-
tions do not focus attention on this aspect of
product development, and the activities are per-
formed by a variety of organizational subgroups
System Focus
emphasis on project specification
generation of knowledge of systemic impact
of individual design choices
systematic retention and application of
system knowledge
P3
I°blemS°lvmgBad
sampling broad disciplinary expertise in
problem identification and solution
Fig. 1. A framework for development performance in environments characterized by discontinuous technological evolution.
in a scattered and compartmentalized fashion.
New technical possibilities are then selected for
their individual potential, not for their impact on
the product and production system as a whole. In
contrast, system-focused organizations emphasize
an extensive and proactive analysis of the impact
of individual design possibilities on the integrated
properties of the entire network of design deci-
sions. If circumstances require it, a system-focused
process will therefore break with past design ap-
proaches.
A system-focused process hinges on a thor-
ough (but flexible) foundation of 'system' knowl-
edge. The information required for evaluating the
interaction between novel technical approaches
and the existing environment is not easily stored
or transferred from individual to individual (see,
however, Leonard-Barton, 1988; Von Hippel,
1990b; Clark and Fujimoto, 1991; Von Hippel
and Tyre, 1993). The value of individual experi-
ence in such situations is very high (e.g.
Leonard-Barton, 1988). System-focused organiza-
tions will therefore retain individuals with the
experience base necessary to investigate the broad
impact of individual design decisions. These pro-
fessionals will drive project specification, becom-
ing the 'architects' or 'integrators' of the future
product. These will be individuals with knowledge
of past reactions to discontinuous technological
change-experience with incremental design will
Development Performance
 M. lansiti / Research Policy 24 (1995) 521-542
not suffice, as shown by the Kasper example.
System-focused organizations will emphasize the
growth of such experience over time and value
these individuals highly.
Our definition of system-focused organizations
is summarized in Definition 1.
Definition 1. System-focused organizations are
characterized by a development process that:
(1) emphasizes and dedicates adequate re-
sources to technology integration, particularly
during project specification;
(2) focuses on the early generation of knowl-
edge of the potential impact of individual deci-
sions on the broad characteristics of the exist-
ing product and production systems;
(3) retains past knowledge of related technol-
ogy integration efforts ('system knowledge').
We conjecture that in a discontinuous techni-
cal environment, system-focused organizations
will be more effective than other organizations in
developing new products (see Fig. 1).
Proposition 2. System-focused organ&ations will
be associated with high levels of development
performance in environments characterized by
discontinuous technological change.
To close the logical loop, we propose that
system-focused organizations ought to be charac-
terized by a broader problem-solving approach
than other organizations. A focus on project spec-
ification activities will engender the consideration
of a broader set of alternative solutions in prob-
lem-solving attempts.
Proposition 3. System-focused organizations will
be associated with a broader approach to solving
problems than other organizations-this will in-
volve information search and processing activi-
ties that cross a broader base of existing disci-
plinary expertise.
To summarize, we have developed a set of
propositions that relate development perfor-
mance to the problem-solving approach and other
characteristics of an organization's development
527
process in situations characterized by discontinu-
ous technological change. We will now go on to a
description of our empirical approach, and to an
analysis of our results.
3. Empirical approach
Our empirical work was designed to perform
quantitative and qualitative analysis of R & D per-
formance in an environment characterized by dis-
continuous technological change. The mainframe
computer industry, with a history characterized
by technical excellence and strong emphasis on
technology as a competitive weapon, is ideal for
this task. The mainframe has exhibited a well-de-
fined set of functional features that are simple to
track. Although measures of product quality and
technical performance have remained relatively
constant, the results achieved have increased dra-
matically over time. Performance improvements,
achieved through the introduction of novel tech-
nological concepts, caused substantial shifts in
the structure of the knowledge base required to
design the new products (Iansiti and Khanna,
1992). The industry therefore provides an envi-
ronment in which technological discontinuities
are common, while at the same time product
performance measures are stable enough to allow
for a good analytical comparison of different pro-
jects.
To obtain comparable observations, we fo-
cused on the development of technologies associ-
ated with the packaging and interconnect system
of the mainframe processor, the 'multi-chip mod-
ule'. Mainframe multi-chip modules connect indi-
vidual integrated circuits to each other and to the
rest of the computer. Their design is critical to
the speed and reliability of the system. In the
words of a senior executive at a leading company,
they are "the most critical subsystems in the
product, and among the most difficult to develop".
Our full-scale empirical research was preceded
by a year-long pilot study (Iansiti (1991), 1992a).
During that time, we had discussions with techni-
cal and industry experts and focused on extensive
informal investigations of two organizations, one
based in the US and one in Japan, involved in the
528 M. lansiti / Research Policy 24 (1995) 521-542
development of modules for mainframe comput-
ers. These investigations were used to develop
the basic conceptual and empirical frameworks
for the study. In particular, we developed a pre-
cise indicator for system focus based on the fac-
tors outlined in Definition 1. After the end of the
pilot phase, we collected observations on the ma-
jor projects performed by firms in the industry
over the past 10 years. Our sample was made up
of all companies in the mainframe computer in-
dustry, including US, European and Japanese
firms.
In each company, one or more projects were
analyzed in detail, for a total of 27 projects.
Structured and unstructured interviews were per-
formed with scientists, engineers and managers at
different hierarchical levels in the organization
and involved with the most critical aspects of
each project. A questionnaire was used to guide
some of the interviews. We recorded the histories
of each development effort, tracking the comple-
tion of each major step as well as the resources
used. We also gathered observations on the basic
characteristics of the organizations involved and
on the processes employed, as well as on the
behavior patterns of the managers and engineers.
These observations were used to develop esti-
mates of R & D performance and project-specific
indicators of system focus (see Tables 1 and 2 and
the appendix).
Furthermore, we captured examples of individ-
ual approaches to design choice and problem
solving by gathering detailed case histories of 61
problem-solving efforts. We interviewed the indi-
viduals involved and cross-checked the informa-
tion by examining written technical accounts. The
problems were selected as being 'the most diffi-
cult technical bottlenecks' in each project, as
evaluated by the engineering managers in each
firm. The problem-solving efforts were coded and
analyzed to develop an indicator of problem-solv-
ing breadth, which was used to test Propositions 1
and 3.
The empirical work comprised several full days
of interviews at each of the company sites per-
formed over multiple visits. The main empirical
part of the study was completed in a period of 2.5
years. The appendix develops more precise oper-
Table 1
Summary of principal variable definitions (see Appendix for
details)
Total lead Time elapsed between the beginning of
time the project and market introduction. The
project beginning is defined as the start
of the first scientific investigations of new
technologies specifically targeted for pos-
sible inclusion in the new product design
effort
Concept lead Time elapsed between the beginning of
time the project and the end of the technology
integration phase. The latter is signaled
by the emergence of a firm and detailed
technological concept for the new prod-
uct
Development Difference between total lead time and
lead time concept lead time. Indicates the time
spent during the 'development' stage of
the project. During this phase the activi-
ties focus on the detailed design of the
product and associated processes, based
on the concept and specifications estab-
lished during the previous stages
Person years Level of technical and managerial human
of engineer- resources used for the length of the
ing and scien- entire project. Includes engineers, man-
tific activity agers, scientists and technicians internal
and external to the firm
Technical Ratio of the number of 'logic gates' per
content square centimeter achieved by the pro-
ject to the best value achieved in the
industry (best in class) at the time of
product introduction. The measure is a
good characterization of the overall func-
tional performance of the device, and
depends on all critical aspects of the
design
ational definitions of the variables, and provides
additional details on our methodology.
3.1. Problem-solving path analysis
The test of Propositions 1 and 3 developed in
Section 2 necessitated developing a framework
for analyzing the disciplinary breadth of the prob-
lem-solving attempts. Our approach was based on
a technical analysis of the path taken in the 61
problem-solving cases captured during our empir-
ical work. Our measure of problem solving
 M. lansiti /Research Policy 24 (1995) 521-542
breadth is linked to the number of independent
knowledge bases or disciplines sampled during
each problem-solving attempt. We call our ap-
proach 'problem-solving path analysis'.
Technical problem-solving processes were
studied in detail by Allen (1966) and by
Frischmuth and Allen (1969), who showed that
they proceed through a recognizable and codable
path. This is consistent with broader studies of
human problem-solving (e.g. Mintzberg et al.,
1976), which showed that problem-solving pro-
cesses may be modeled as cyclical activities in
which individuals frame the problem, search for
information, process that information, and either
select a solution or cycle back to search for addi-
tional information (see also Hauptman and Pope,
1992).
Our approach was based on tracking the path
of different problem-solving efforts and docu-
menting which knowledge bases were employed.
We first defined a set of fundamental knowledge
bases in the field of multi-chip module design.
After consultations with several technical experts,
we arrived at the identification of nine knowledge
bases. Six of the knowledge bases are established
disciplines in applied science and engineering,
and largely independent of firm-specific contexts.
These are ceramic material science, semiconduc-
tor material science, metallurgy, polymer chem-
istry, structural engineering (mechanical design)
and thermal engineering, t Three of the knowl-
edge bases are instead specific to the context of
each firm: knowledge of the architecture and
system design of the firm's mainframe computer,
knowledge of the firm's manufacturing process,
and knowledge of the capabilities of the firm's
suppliers.
After identifying these disciplines, we coded
which knowledge bases were sampled during the
1 Ceramic material science has been consistently linked to
ceramic substrate design, semiconductor material science to
the design of silicon substrates, metallurgy to chip bonding,
polymer chemistry to the application of thin-film polyimide
materials and to certain chip-sealing techniques, structural
engineering to the design of the module housing and reliabil-
ity analysis and thermal engineering to the design of the
critical cooling system.
529
information search and processing activities in
each problem-solving effort. The number of
knowledge bases sampled during the identifica-
tion of the problem-solving effort was used as the
indicator of the breadth of the problem-solving
path. A path was defined as being 'narrow' if only
a single knowledge base was employed. The path
was defined as being 'broad' if more than one
knowledge base was employed. Additionally we
made the distinction between context-specific
breadth and context-independent breadth. 2 The
analysis was aggregated to arrive at an index of
problem-solving breadth for an organization. This
was defined as the percentage of problems ana-
lyzed which were classified as broad. 3 Indexes of
context-specific breadth and context-independent
breadth were defined similarly.
3.2. Organizational ~,ariables
We used the ideal profile index method to
develop an index of system focus (e.g. Van de
Ven and Drazin, 1985; Venkatraman, 1987; Fuji-
moto, 1989; Clark and Fujimoto, 1991). The one
year pilot study was important in the develop-
ment of the index. Over this period of time, we
worked with experienced managers and engineers
to translate the three general factors described in
Definition 1 into a set of specific, measurable
2 An example may help to clarify our methodology. In one
instance, a group of metallurgists discovered that the copper
formulation they were using in their design developed trou-
blesome holes when processed at certain temperature ranges.
In response to this they developed a novel, proprietary copper
paste formulation which resolved the problem. This problem-
solving path was defined to be narrow, since only metallurgi-
cal knowledge was employed. In contrast, a group of cerami-
cists in a different firm found that the surface of the ceramic
substrate they had developed exhibited cracks which impaired
its structural stability. The resolution of this problem was not
limited to ceramic engineering. The researchers found out
that a polymer used in sealing the substrate cover would fill
up the cracks in the ceramic, eliminating the problem. This
problem case was classified as broad, since the identification
and solution of the problem combined different knowledge
bases (ceramic material science and polymer chemistry).
3 The analysis was not performed at the project level to
allow for a greater sample of problem cases for each breadth
calculation.
530 M. lansiti / Research Policy 24 (1995) 521-542
variables that applied to the mainframe module
environment (see Table 2). The indicators shown
in Table 2 (all 0-1 variables) were added to
construct the index. The individual impact of
each indicator was also analyzed independently.
4. Empirical results
We begin by investigating the association be-
tween problem-solving breadth and project per-
formance, and continue by looking at the rela-
tionship between system focus and project perfor-
mance. We then close the logical loop by examin-
ing the association between system focus and
problem-solving breadth.
4.1. Problem soluing and performance
Tables 3 and 4 present results consistent with
Proposition 1.4 Project performance, as repre-
sented by either person years or development
lead time, is significantly associated with prob-
lem-solving breadth in model A1. The coefficient
for problem-solving breadth has a negative sign,
indicating that the higher the breadth the lower
the person years (and thus the higher the produc-
tivity). Technical content was included explicitly
in the regressions, rather than using content-ad-
justed person year figures. Its relationship with
person years is positive (the higher the technical
content the more resources necessary for the
project) and significant at the 1% level.
Table 3 shows regressions including context-
specific and context-independent problem-solving
breadth indexes. The regression results are in-
triguing. While context-specific breadth is highly
significant (and negatively correlated with person
years) context-independent breadth is not signifi-
cantly associated with project performance.
These results are similar to those found in
regressions between development lead time and
4 The problem-solving path analysis was not carried out for
three of the organizations in our sample. The n u m b e r of
degrees of freedom in analysis involving problem-solving in-
dexes is therefore lower than that for the entire sample.
problem-solving breadth in Table 4. The relation-
ship between development lead time and prob-
lem-solving breadth is significant at the 1% level
and negative, indicating that greater breadth is
linked with development speed, in accordance
with Proposition 1. The relationship between lead
time and context-specific breadth is also signifi-
cant and negative. However, model A6 indicates
that the relationship between context-indepen-
dent breadth and lead time is not significant. 5
The difference in significance between con-
text-specific and context-independent breadth in
both productivity and lead time models leads to
an interesting interpretation of the results. Con-
text-specific breadth referred to the inclusion of
environment-specific knowledge bases in the
problem-solving effort. These included knowl-
edge of the firm's manufacturing capabilities,
knowledge of the firm's mainframe design (out-
side of the module subsystem), and knowledge of
supplier capabilities. In contrast, context-inde-
pendent breadth included general, universally ap-
plicable, traditional disciplines, such as ceramic
material science or thermal engineering. Our re-
sults indicated that the components of problem-
solving breadth correlated with project perfor-
mance are those specific to the firm's environ-
ment, such as the awareness of subtle design and
manufacturing considerations.
This result is consistent with the likely evolu-
tion of knowledge in an R & D organization. Over
time, as different generations of products are
developed, engineers involved in module design
are likely to develop an awareness of which basic
disciplinary knowledge bases are linked to each
5 Additionally, in contrast with the productivity regressions,
the impact of technical content in lead time regressions is not
significant. This may reflect the observation that organizations
are frequently forced to complete the module design by a
specific deadline, which is defined by the introduction of the
entire mainframe system. In response, they tend to add re-
sources to the project until they feel the deadline can be met.
Productivity may therefore be a more representative perfor-
mance measure for the organization. While development lead
time may be driven by managerial schedule, the total person
years required for project completion are a direct representa-
tion of the challenges and difficulties encountered.
 M. lansiti /Research Policy 24 (1995) 521-542 531

other. Ceramicists are going to learn some metal-
lurgy, since the design of ceramic multi-chip mod-
ules has always included layers of metallic circuits
to conduct electric signals. The design of ceramic
and metal layers has traditionally been closely
interlinked, requiring the integration of the two
knowledge bases. Over time, one would therefore
expect an organization to develop a hierarchy of
design decisions with branches in which metal
and ceramic choices are closely related, naturally
leading to problem-solving progressions which in-
volve both knowledge bases.
In contrast with well-defined traditional disci-
plinary knowledge bases, context-specific knowl-
edge is more subtle and changes more rapidly (as
new manufacturing equipment is introduced, or
as new suppliers are selected, for example). The
interactions between context-specific knowledge
and individual design choices are therefore likely
to experience more significant shifts as products
evolve. This makes the effective application of
context-specific knowledge a substantial chal-
lenge, leading to clear differences in performance
between projects.

Table 2
Indicators of system focus (see Definition 1 and the Appendix)
Factor 1. The organization emphasizes and dedicates adequate resources to technology integration, particularly during project
specification
1. Integration group exists The responsibility for project specification (integration) is localized in a single
organizational unit or core team. This unit is defined to be the integration group
2. Integration team dedicated The core scientist/engineer team is dedicated to integration activities for this
product line

Factor 2. The organization focuses on the early generation of knowledge of the potential impact of individual decisions on the
broad characteristics of the existing product and production systems
3. Day-to-day contact with plant Integration group is in on-going day-to-day contact with manufacturing plant
4. Fix production problems Integration group is responsible for major production problems on on-going
product lines. The group therefore has continuous awareness of the production
environment
5. Manufacturing engineering group not The core of the development of the production process is performed by the
on critical path integration group. The integration group has direct knowledge of process
development
6. Relocation at uncertainty source Integration group moves to the major sources of technical uncertainty, such as the
pilot or production facility. The group therefore has direct access to these sources
7. Choose production volume equipment Integration group drives production equipment choices. The integration group
therefore has direct knowledge of the production equipment
8. Interacts with system group Integration group interacts directly with mainframe system designers. The group
has rich contact (not through liaisons) with experts on system architecture
9. Interacts with component groups Integration group interacts directly with component designers, such as chip
developers. The group has rich contact (not through liaisons) with experts on
semiconductor design

Factor 3. The organization retains past knowledge of related technology integration efforts ('system knowledge')
10. Technical expert exists
11. Technical expert is project manager
12. 'T' specialization
13. Continuous cycle (firm)
14. Continuous cycle (group)
Individual with great depth and breadth of knowledge is in the integration group.
This technical 'guru' captures a rich experience base
The expert is a driver and champion of the entire project (more than an advisory
role)
Integration team members are deep in a specified technical area but are exposed
to a wide variety of activities
The firm markets a continuous stream of technically related products. The
potential for accumulating a rich experience base exists. This is not a 'first of a
kind' effort
The integration group works on a consistent stream of products, with continuity in
members. The individuals in the group become a rich repository of the impact of
technical change on the environment
532 M. lansiti / Research Policy 24 (1995) 521-542

Table 3
Regression results on the association between person years, problem-solving breadth indexes and technical content
D e p e n d e n t variable Person years Person years Person years
Model n a m e A1 A2 A3
Constant 364.46 294.08 110.03
Problem-solving - 5 2 4 . 8 0 ***
breadth (205.61)
Context-specific - 4 7 8 . 9 9 **
breadth (195.09)
Context-independent 63.37
breadth (409.43)
Technical content 576.28 **** 549.01 **** 589.21 ****
(183.94) (186.22) (209.46)
F-test 8.46 8.13 4.07
P 0.002 0.002 0.031
Adjusted R 2 0.374 0.363 0.197
Residual degrees of 23 23 23
freedom
The table displays regression coefficients unless otherwise indicated; numbers in parentheses are standard errors. * significance at
the 10% level; ** significance at the 5% level; *** significance at the 2% level; **** significance at the 1% level; ***** signifi-
cance at the 0.1% level.

An example illustrates typical differences in
problem-solving approaches. One organization
began experiencing a problem during experi-
ments on a prototype of the ceramic substrate
early in the specification stage of the project. The
substrate would 'buckle', changing its shape dur-
ing the annealing process--this was due to a
difference in expansion rates between the ce-
ramic and the metal paste that made up the
module substrate. After much effort, material
scientists developed new metal paste composi-
tions and temporarily resolved the problem.

Table 4
Regression results on the association between development lead time, problem-solving breadth indexes and technical content
D e p e n d e n t variable Development lead Development lead Development lead
time time time
Model name A4 A5 A6
Constant 5.73 5.46 3.98
Problem-solving - 3.28 ****
breadth (1.10)
Context-specific - 3 . 4 5 ****
breadth (0.99)
Context-independent 1.98
breadth (2.25)
Technical content 1.46 1.24 1.45
(0.99) (0.94) (1.15)
F-test 5.67 7.51 1.32
P 0.010 0.003 0.285
Adjusted R 2 0.330 0.343 0.103
Residual degrees of 23 23 23
freedom
The table displays regression coefficients unless otherwise indicated; numbers in parentheses are standard errors. * significance at
the 10% level; ** significance at the 5% level; *** significance at the 2% level; **** significance at the 1% level; ***** signifi-
cance at the 0.1% level.
 M. lansiti / Research Policy 24 (1995) 521-542 533

Table 5 composition of the metal paste. Once again the

R e g r e s s i o n results o n the a s s o c i a t i o n b e t w e e n project perfor- problem appeared to have been resolved. How-
m a n c e variables, system-focus indexes a n d t e c h n i c a l c o n t e n t
ever, when the substrate was transferred to the
Dependent variable P e r s o n years D e v e l o p m e n t lead
production facility, it recurred again, causing ad-
time ditional delays. These problems combined to de-
Model name B1 B2
lay the project for a total of 2 years.
Constant 567.68 6.62
System focus -52.64 ***** - 0 . 2 8 5 *****
A second organization experienced the same
(12.76) (0.0726) buckling problem. Rather than limiting the search
Technical content 590.94 ***** 1.56 for solutions to the field of metallurgy, however,
(155.03) (0.882) the engineers involved in early project specifica-
F-test 15.95 9.33
tion (the 'integration group') framed the problem
P 0.0001 0.001
Adjusted R e 0.535 0.391
broadly and searched for solutions in a number of
R e s i d u a l d e g r e e s of 24 24 different contexts. They examined the potential
freedom of using new materials, changing the architecture
T h e t a b l e displays r e g r e s s i o n coefficients unless o t h e r w i s e of the product, or modifying its production pro-
i n d i c a t e d ; n u m b e r s in p a r e n t h e s e s are s t a n d a r d errors. * sig- cess. Moreover, they tried a combination of the
nificance at the 10% level; ** significance at the 5 % level; above solution strategies. They had a very good
• ** significance at the 2 % level; **** significance at the 1% awareness of how the different elements of the
level; * * * * * significance at the 0.1% level.
product and production system might have an
impact on this problem. For example, members
However, when the module was transferred to of the integration group had helped select the
the pilot plant, the problem recurred. Once again, manufacturing equipment, and were aware that
the material scientists were called in to refine the some of its characteristics might have a subtle

Table 6
T h e c o r r e l a t i o n b e t w e e n i n d i v i d u a l i n d i c a t o r s of system focus a n d d e v e l o p m e n t s p e e d a n d productivity
P e r s o n years Development
residuals lead t i m e r e s i d u a l s
1. I n t e g r a t i o n g r o u p exists -0.63 ***** -0.445 ***
2. Integration team dedicated - 0.439 ** - 0.393 **
3. D a y - t o - d a y contact with p l a n t - 0.525 **** - 0.539 ****
4. Fix p r o d u c t i o n p r o b l e m s - 0.446 **** - 0.392 **
5. Manufacturing engineering - 0.432 ** - 0.402 **
g r o u p not on critical p a t h
6. R e l o c a t i o n at u n c e r t a i n t y - 0.514 **** - 0.478 ***
source
7. C h o o s e p r o d u c t i o n v o l u m e - 0.343 * - 0.419 **
equipment
8. I n t e r a c t s w i t h system g r o u p - 0.550 **** - 0.449 ***
9. I n t e r a c t s w i t h c o m p o n e n t - 0.447 *** - 0.667 *****
groups
10. T e c h n i c a l e x p e r t exists
11. T e c h n i c a l e x p e r t is project -0.285 -0.127
manager
12. 'T' s p e c i a l i z a t i o n - 0 . 5 4 6 **** - 0 . 5 8 2 ****
13. C o n t i n u o u s cycle (firm) - 0.149 - 0.205
14. C o n t i n u o u s cycle (group) - 0.503 **** - 0.576 ****

P e r s o n y e a r a n d d e v e l o p m e n t lead t i m e r e s i d u a l s are t a k e n from a r e g r e s s i o n b e t w e e n t e c h n i c a l c o n t e n t a n d p e r s o n years and

d e v e l o p m e n t lead time, respectively. I n d i c a t o r n u m b e r 10 h a d zero v a r i a n c e a n d thus its c o r r e l a t i o n c o u l d not b e c o m p u t e d .
* significance at the 10% level; ** significance at the 5 % level; *** significance at the 2 % level; **** significance at the 1% level;
* * * * * significance at the 0.1% level.
534 M. lansiti/ Research Policy 24 (1995)521-542
impact on the annealing rate for the substrate. As
a result, they moved temporarily to the pilot plant
to characterize the problem on the new produc-
tion equipment, which had only recently been
delivered. After extensive analysis and the con-
sideration of a variety of solutions, the integra-
tion group solved the problem by adjusting the
equipment to control (but not eliminate) the
buckling and by planarizing the substrate using a
polymer layer. In contrast with the other organi-
zation, the solution was robust and the problem
did not recur. Integration group members had
managed to resolve a difficult problem early by
framing it broadly and by making use of a novel
combination of context-specific knowledge bases.
4.2. System focus and performance
Table 5 investigates the impact of organiza-
tional process on performance. Our results are
consistent with Proposition 2, and show that sys-
tem focus is significantly associated with person
years and development lead time (at the 0.1%
level). The association is negative, indicating that
system-focused organizations completed develop-
ment projects more quickly and using fewer re-
sources. As with the previous regressions, techni-
cal content is significantly associated with person
years but not with development lead time.
To probe the consistency of the system-focus
index, we now examine the relationship between
the individual routines making up the index and
Table 7
Regression results on the association between problem-solvingbreadth indexes and system focus
Dependent v a r i a b l e Problem-solving
breadth
Model name C1
Constant - 0.0747
System focus 0.0615 *****
(0.0082)
F-test 55.93
P 0.0001
Adjusted R 2 0.687
Residual degrees of 24
freedom
The table displays regression coefficients unless otherwise indicated; numbers in parentheses are standard errors. * significance at
the 10% level; ** significance at the 5% level; *** significance at the 2% level; **** significance at the 1% level; ***** signifi-
cance at the 0.1% level.
project performance. Table 6 displays the correla-
tion between the different 0 - 1 variables making
up the system-focus index, and the residuals of a
regression between the two main development
performance variables and the technical content
of each project. The uniformly negative correla-
tion indicates that the system-focus indicators are
indeed consistently associated with higher pro-
ductivity and lower development lead time. For
the majority of the cases, the association is
strongly significant. For variables 10, 11 and 13
there was a lack of substantial variation between
the projects.
Our results indicate that a system-focused pro-
cess for technology integration is linked with de-
velopment performance in this environment. In
other work (Iansiti, 1992b, 1993) we have investi-
gated the impact of geographical origin on devel-
opment performance. While Japanese companies
were, on average, more productive and faster
than US and European companies, regressions
including system focus as well as geographical
dummy variables indicated that only system focus
was significantly related to performance. A sys-
tem-focused development process could explain
performance differences between as well as within
geographical regions. Additionally, we investi-
gated the impact of more traditional approaches
to development effectiveness, such as cross-func-
tional integration and project leadership (Allen et
al., 1980b; Clark and Fujimoto, 1991). While the
traditional factors did show occasional positive
Context-specific Context-independent
breadth breadth
C2 C3
- 0.218 0.145
0.0636 ***** - 0.0024
(0.0094) (0.0086)
45.82 0.084
0.0001 0.774
0.656 -0.038
24 24
 M. lansiti / Research Policy 24 (1995) 521-542 535

correlation with productivity and development Table 8

lead time, our analysis indicated (Iansiti, 1993) Problem characteristics and outcomes for differentorganiza-
tional groups
that only system focus was consistently associated
The problem: Total System- Other
with development performance.
sample (%) focused organiza-
These results are consistent with our concep- organiza- tions (%)
tual framework. In this environment, dominated tions (%)
by discontinuous technological evolution, tradi- Was identified before 69 75 62
tional organizational approaches to project man- concept selection
agement did not appear to be sufficient to achieve Was worked on before 67 75 59
a fast and productive development organization. concept selection
Was fixed before 44 59 28
While effective companies appeared consistently
concept selection ***
characterized by good project management prac- Recurred after concept 25 16 35
tice (as described, for example by Clark and Fuji- selection *
moto, 1991), these practices did not differentiate Caused delays late in 56 41 72
them from less effective competitors. The most the project ***
critical activities in differentiating companies were Concept selection corresponds to the end of integration activi-
instead rooted in the early stages of product ties, which take place before detailed design has begun, as
development and were aimed at technology inte- described in Section 2. Problems 'identified' were ones that
project members had conjectured would be particularly chal-
gration. The most effective organizations empha-
lenging during the project. Problems 'worked on before con-
sized the critical role played by project specifica- cept selection' were ones to which the organization had de-
tion tasks, a broad approach to the evaluation of voted some resources before the integration phase was com-
design choices, and the value of accumulating plete. Problems 'fixed' before concept selection were ones
knowledge of previous technology integration ac- whose early solutions were robust enough to work in the final
production environment. Problems which 'recurred' were ones
tivities.
whose early solutions did not work in the final production
environment. Problems which 'caused delays late in the pro-
4.3. Development process and problem-solving ap- ject' were ones that were not 'fixed before concept selection'.
proach *** indicates that values for the 'system focused' and 'other'
groups were significantly different at the 2% level, as indi-
cated by a t-test. * indicates that the significance level was
Table 7 displays the results of three regression
10%.
models that relate an organizational approach to
problem-solving breadth. In accordance with
Proposition 3, the problem-solving breadth index The evidence from Table 8 indicates that sys-
is significantly associated with system focus. Simi- tem-focused organizations approach technical
larly, context-specific breadth and system focus problems in a manner significantly different than
are significantly related. In contrast, context-in- the rest of the sample. The difference is not in
dependent breadth is not associated with system problem identification, however. Organizations in
focus. These results are consistent with the re- the entire sample appeared to do a good job of
gressions presented above and close the logical identifying potential problem areas early in the
loop in linking problem-solving breadth, system project, before concept selection was completed.
focus and development performance. Most of the critical technical challenges in the
Table 8 displays some important characteris- project were apparently obvious enough to be
tics of the problem-solving attempts we analyzed, targeted for early action. The real differences
grouped by type of organization. The distinction appear when one considers the robustness of
between 'system-focused' organizations and 'other early solutions. System-focused organizations
organizations' was based on the system-focus in- were characterized by a significantly higher pro-
dex. System-focused organizations were defined portion of problems that were fixed by early
as having a system-focus index greater than sam- efforts, and thus by a significantly lower percent-
ple average. age of late problems. In other words, system-
536 M. lansiti / Research Policy 24 (1995) 521-542
focused organizations actually fixed the problems
in early efforts. In other organizations, individu-
als thought the problems had been eliminated,
although these had in fact only been postponed
to later project stages. In resolving the problems
at these early stages, system-focused organiza-
tions made more proactive use of technology
choice and project specification activities.
These findings are consistent with our expecta-
tions that a broader approach to problem solving
is linked to the organizational routines that guide
technology selection activities. Moreover, they
paint an intriguing picture of the difference be-
tween more or less effective problem-solving
strategies. Much of the literature has focused on
the importance of problem identification in ap-
proaching technically ambiguous problems (Hen-
derson and Clark, 1990; Schrader et al., 1992).
Our findings indicate instead that a broad prob-
lem-solving strategy must be carried out consis-
tently throughout the testing stages. It may not be
enough to identify a potential problem through
broad discussions, say by conducting a brain-
storming exercise, and then designating a special-
ized professional to problem resolution. The
identification and implementation of a robust so-
lution may require search strategies and testing
routines that are as broad as those involved in
problem identification.
5. Discussion
5.1. System focus, technology integration and the
integration group
Our results have shown that in an environment
characterized by discontinuous technological
change, development performance is related to
the process of technology integration. The rou-
tines and problem-solving approaches linked with
high performance focus on the development of a
good match between new technical possibilities
and the organization's existing capabilities. They
emphasize the integration of deep knowledge of
the existing environment (i.e. context-specific
knowledge) with the specification of project tasks.
The capability to perform these activities ef-
fectively appears to hinge on the ability to nur-
ture a critical group of individuals, which we have
called the 'integration group'. These individuals
retain knowledge of the complex interactions be-
tween the disciplinary bases involved in a se-
quence of development projects. While they will
not possess the complete knowledge necessary to
execute all project tasks, they have a good under-
standing of how the bases are related, and the
capability to integrate the effort of others.
Effective technology integration is not carried
out at a strategic level. Rather, integration group
members are involved in the day-to-day problem-
solving activities, specifying their direction and
scope. For example, what counts is not just un-
derstanding that both materials engineering and
production expertise may be needed. Instead, in-
tegration group members must have the experi-
ence and capability to realize that a given solder-
ing material may have a subtle impact on a spe-
cific inspection machine. The subtlety is in the
details of the interaction between knowledge
bases.
Ensuring good cross-functional communication
is not enough for effective integration at such a
microscopic level. In the words of a project man-
ager in one of the most effective organizations,
" . . . w e no longer have the luxury to spend much
time communicating-the problems are too com-
plex and the time is too tight... To solve this
problem we try to develop individuals with a
T-shaped pattern of skill: deep in one area, broad
in m a n y . . . " This 'T-shaped' skill pattern charac-
terizes effective integrators: while they have the
depth of knowledge necessary to understand
technical options, they also have experience of
how their discipline base interacts with other
knowledge bases and context-specific factors.
These findings add evidence to the discussion
by Henderson and Clark (1990) suggesting that
certain firms fail by not recognizing the impact of
subtle evolutions in product architecture. In our
environment, each late problem in a project may
be thought of as a microscopic failure. While
these failure instances are not dramatic, when
aggregated, they do contribute to major project
delays and inefficiencies, which may lead to sub-
stantial decreases in market share. The role of
 M. lansiti / Research Policy 24 (1995) 521-542
the integration group is to lead the evolution of
the development project so as to avoid such fail-
ures, by applying its rich knowledge base and
achieving robust technical solutions.
5.2. Managing the structure of knowledge
Our empirical work has indicated that technol-
ogy integration routines in the specifcation of a
development project can have a critical impact on
the structure of decision making in the remainder
of the project. This has important implications
for the evolution of knowledge. Over time, an
organization's aggregate knowledge base and its
information-processing capability will adapt to the
structure of the design tasks (Lawrence and
Lorsch, 1967; Galbraith, 1973; Clark, 1985). Pro-
ject specification decisions have the potential to
alter the structure of knowledge distribution, spe-
cialization and decision making, and can there-
fore be a critical link in managing the structure of
the organization's knowledge base.
Henderson and Clark emphasized the subtle
but critical impact of technological discontinuities
on the competitiveness of firms. However, their
focus was on the physical architecture of the
product, emphasizing the linkage between spe-
cialized knowledge and component design. Our
work investigates what we believe is a similar
fundamental phenomenon, but with a different
manifestation. The projects in our sample were
not characterized by reconfigurations in the link-
age between system and components. Even if we
view the processor module itself as a system, the
basic elements that make it up (mainly the sub-
strate, cooling system and integrated circuits) did
not change. They still contributed to the function-
ality of the product in the same way as they had
in previous generations. On the other hand, we
argue that the projects had a critical 'architect-
ural' impact on the product's knowledge base,
shifting relationships between new and existing
disciplinary expertise.
The subtle impact of technological evolution
on the knowledge underlying the manufacturing
process was especially important. In one example,
managers explained to us that they had specifi-
cally designed the latest module to minimize any
537
change from previous generations: they 'simply'
substituted new materials for existing ones. The
project incurred dramatic delays and cost over-
runs, however, because the managers had not
realized that their substitutions completely re-
structured the knowledge base required to manu-
facture the product. This was not obvious, since
the new materials could in fact use the bulk of
the existing manufacturing equipment. What the
managers did not realize was that the equipment
would have to be used in a very different way.
The new materials were more sensitive to process
parameters, and their final quality was critically
dependent on different aspects of the equipment
than the older generation. For example, in the
new product generation, there was a much closer
linkage between the details of metallization and
ceramic sintering processes than ever before. Ad-
ditionally, while the sintering ovens used were
largely unchanged, precise control of their dy-
namic temperature profile had suddenly become
critical.
Approaching innovation from our perspective
allows consideration of a broad set of issues not
linked to the physical architecture of the product.
The potential is not limited to the analysis of the
interaction between technical choice and produc-
tion process. Instead, we go back to the work of
Marple (1961) and Clark (1985) in using the en-
tire set of design choices to analyze the impact of
technological evolution on product and process
design. 6 Products, in this framework, should not
simply be thought of as an aggregation of compo-
nents, but the integrated outcome of a complex
system of knowledge.
Additionally, we emphasize that the evolution
of this knowledge system can (and should) be
managed proactively throughout the process of
technology integration. As product requirements
evolve, R & D organizations should make use of
this opportunity to specify the direction of devel-
opment activities. Integration group members will
impact the evolution of knowledge by influencing
6 Marple, for example, included choices concerning the
manufacturing system in his hierarchy of product design (Mar-
pie, 1961).
 538 M. lansiti / Research Policy 24 (1995) 521-542
the scope of problem-solving activities and the
specification of projects. Their role is to be the
architects of the organization's knowledge base,
creating a good foundation for the evolution of
product development activities.
In generalizing the results of our study to
other environments, the critical factor should
therefore be the structure of the whole knowl-
edge base required for development. This implies
that our propositions could be tested in a broad
variety of industries, not all of which entail prod-
ucts that are traditional 'systems', but whose
knowledge base is complex and undergoes dis-
continuous change. These range from advanced
materials to chemicals and plastics, and from
biotechnology to software. The impact of object-
oriented programming on the evolution of soft-
ware applications is an example of a discontinu-
ous evolution that fundamentally rearranged the
structure of software development and its associ-
ated knowledge base.
Additional research is needed to generalize
our observations. While our propositions are gen-
eral, further work is needed to translate them
into hypotheses and substantiate their applicabil-
ity outside the mainframe computer industry. Ad-
ditionally, it would be interesting to study system-
atically how the specific routines underlying ef-
fective technology integration vary from environ-
ment to environment. These considerations will
have to await future study in a multi-industry
context.
6. References
Abernathy, W.J. and K.B. Clark, 1985, Innovation: Mapping
the winds of creative destruction, Research Policy 14,
3-22.
Allen, T.J., 1966, Studies of the problem-solving process in
engineering design, IEEE Transactions on Engineering
Management, EM-13 (2) 72-83.
Allen, T.J., (1977), Managing the flow of technology (MIT
Press, Cambridge, MA).
Allen, T.J., 1986, Organizational structures, information tech-
nology and R&D productivity, IEEE Transactions on En-
gineering Management, EM-33 (4) 212-217.
Allen, T.J. and O. Hauptman, 1987, "The Influence of Com-
munication Technologies on Organizational Structure".
Communication Research 14, (5) (October): 575-578.
Allen, T.J., D.M.S. Lee and M.L. Tushman, 1980a, Technol-
ogy transfer as a function of position in the spectrum from
research through development to technical services,
Academy of Management Journal 22 (4) 694-708.
Allen, T.J., M.L. Tushman and D.M.S. Lee, 1980b, R&D
performance as a function of internal communication,
project management, and the nature of work, IEEE Trans-
actions on Engineering Management, EM-27 (1).
Anderson, P. and M. Tushman, 1990, Technological disconti-
nuities and dominant designs: A cyclical model of eco-
nomic change, Administrative Science Quarterly (Decem-
ber).
Arrow, K., 1974, The limits of organization (Norton, New
York).
Bowen, H.K., K.B. Clark, C. Holloway and S.C. Wheelwright
(Editors), 1993, Vision and capability: High performance
product development in the 1990s (Oxford University
Press, New York).
Burns, T. and G.M. Stalker, 1961, The Management of Inno-
vation. (Tavistock Publications, London).
Clark, K.B., 1985, The interaction of design hierarchies and
market concepts in technological evolution, Research Pol-
icy 14 (5) 235-251.
Clark, K.B. and T. Fujimoto, 1989a, Overlapping problem
solving in product development, in: Kasra Ferdows (Edi-
tor), Managing international manufacturing (North-Hol-
land, Amsterdam) 127-152.
Clark, K.B. and T. Fujimoto, 1989b, Lead time in automobile
product development: Explaining the Japanese advantage,
Journal of Engineering and Technology Management 6,
25 -58.
Clark, K.B. and T. Fujimoto, 1991, Product development
performance, (Harvard Business School Press, Boston,
MA).
Cusumano, M.A., 1992, Shifting economies: From craft pro-
duction to flexible systems and software factories (Else-
vier, Amsterdam) 453-480.
Cusumano, M.A. and K. Nobeoka, 1992, Strategy, structure
and performance in product development: Observations
from the auto industry (Elsevier, Amsterdam) 265-293.
Dewar, R.D. and J.E. Dutton, 1986, The adoption of radical
and incremental innovations: An empirical analysis, Man-
agment Science (November).
Dosi, G. and L. Marengo, 1992, Toward a theory of organiza-
tional competencies, Mimeo.
Ettlie, J.E., W.P. Bridges and R.D. O'Keefe, 1984, Organiza-
tional strategy and structural differences for radical vs.
incremental innovation, Management Science 30 (6) 682-
695.
Frischmuth, D.S. and T.J. Allen, 1969, A model for the
description and evaluation of technical problem solving,
IEEE Transactions on Engineering Management, Em-16
(2) 58-64.
Fujimoto, T., 1989, Organizations for effective product devel-
opment: The case of the global automobile industry, Un-
published D.B.A. Dissertation, Harvard Business School.
Fujimoto, T., M. Iansiti and K.B. Clark, 1991, External inte-
 M. lansiti / Research Policy 24 (1995) 521-542
gration in product development, Harvard Business School
Working Paper No. 92025.
Galbraith, J.R., 1973, Designing complex organizations (Ad-
dison-Wesley, Reading, MA).
Gibbons, M. and R.D. Johnson, 1974, The role of science in
technological innovation, Research Policy 3, 220-242.
Hauptman, O. and S.L. Pope, 1992, The process of applied
technology forecasting, Technological Forecasting and So-
cial Change 42d, 193-211.
Henderson, R.M. and K.B. Clark, 1990, Architectural innova-
tion: The reconfiguration of existing product technologies
and the failure of established firms, Administrative Sci-
ences Quarterly 35, 9-30.
Iansiti, M. (1991) 1992a, Technology integration: Exploring
the interaction between applied science and product de-
velopment, Harvard Business School Working Paper No.
92026 (revised).
lansiti, M., 1992b. Technology development and integration:
An empirical study of the interaction between applied
science and product development, Harvard Business
School Working Paper No. 93024.
Iansiti, M., 1993, Science-based product development: An
empirical study of the mainframe computer industry, Har-
vard Business School Working Paper No. 92083.
Iansiti, M. and K.B. Clark, 1993, Integration and dynamic
capability: Evidence from product development in auto-
mobiles and mainframe computers, Harvard Business
School Working Paper No. 9304 7.
lansiti, M. and T. Khanna, 1992, Technological evolution,
system architecture and the obsolescence of firm capabili-
ties, Harvard Business School Working Paper No. 93005.
Katz, R. and T.J. Allen, 1985, Project performance of project
groups in the R&D matrix, Academy of Management
Journal 29 (1) 67-87.
Keller, R.T., 1986, Predictors of the performance of project
groups in R&D organizations, Academy of Management
Journal 29 (4) 715-726.
Langrish, J., 1971, Technology transfer: Some British data,
R&D Management 1, 133-136.
Lawrence, P.R. and J.W. Lorsch, 1967, Organization and
environment, Harvard Business School, Classics.
Leonard-Barton, D., 1988, Implementation as mutual adapta-
tion of technology and organization, Research Policy 17,
251-267.
March, J.G. and H.A. Simon, 1958, Organizations (Wiley,
New York).
Marple, D.L., 1961, The decisions of engineering design,
IEEE Transactions of Engineering Management 2, 55-71.
Marquis, D.G. and D.L. Straight, 1965, Organizational factors
in project performance, MIT Sloan School of Management
Working Paper.
McDonough, E.F. Ill and G. Barczak, 1992, The effects of
cognitive problem-solving orientation and technological fa-
miliarity on faster new product development, Journal of
Product Innovation Management, 44-52.
Mintzberg, H., D. Raisinghani and A. Theoret, 1976, The
539
structure of 'unstructured' decision processes, Administra-
tive Science Quarterly 21,246-275.
Moch, M. and E.V. Morse, Size, centralization and organiza-
tional adoption of innovations, American Sociological Re-
view (October 1977), 16-725.
Nelson, R. and S. Winter, 1982, An evolutionary theory of
economic change (Harvard University Press, Cambridge,
MA).
Rosenberg, N., 1982, Inside the black box: Technology and
economics (Cambridge University Press, New York).
Saviotti, P.P. and J.S. Metcalfe, 1984, A theoretical approach
to the construction of technological output indicators,
Research Policy 13, 141-151.
Schrader, S., W.M. Riggs and R.P. Smith, 1992, Choice over
uncertainty and ambiguity in technical problem solving: A
framework and propositions, MIT, Sloan School of Man-
agement, May.
Sherwin, E.W. and R.S. Isenson, 1967, Project hindsight,
Science 156, 1571-1577.
Simon, H.A., 1978, Rationality as process and as product of
thought, American Economic Review 69 (4) 1-16.
Stalk, G. Jr., 1988, Time--the next source of competitive
advantage, Harvard Business Review (July-August) 41-51.
Tummala, R.R. and E.J. Rymaszewski (Editors), 1988, Micro-
electronics packaging handbook (Van Nostrand, New
York).
Tushman, M.L. and P. Anderson, 1986, Technological discon-
tinuities and organizational environments, Administrative
Science Quarterly 31,439-465.
Tyre, M.J., 1989, Managing innovation in the manufacturing
environment: creating forums for change on the factory
floor, MIT Sloan School of Management Working Paper
No. 3005-89-BPS.
Tyre, M.J. and O. Hauptman, 1990, Effectiveness of organiza-
tional response mechanisms to technological change in the
production process, MIT Sloan School of Management
Working Paper No. 3050-89-BPS.
Tyre, M.J. and W.J. Orlikowski, 1991, Windows of opportu-
nity: Creating occasions for technological adaptation in
organizations, MIT, Sloan School of Management (re-
vised) March.
Uttal, B., 1987, Speeding ideas to market, Fortune (2 March)
62-66.
Van de Ven, A. 1986. Central problems in the management of
innovation, Management Science 32 (5) 590-607.
Van de Ven, A.H. and R. Drazin, 1985, The concept of fit in
contingency theory, Research in Organizational Behavior
7, 333-365.
Venkatraman, N., 1987, The concept of fit in strategy re-
search: Towards verbal and statistical correspondence,
Academy of Management Best Paper Proceedings.
Von Hippel, E., 1990a, Task partitioning: An innovation pro-
cess variable, Research Policy 19, 407-418.
Von Hippel, E., 1990b, The impact of 'sticky data' on innova-
tion and problem solving, MIT Sloan School of Manage-
ment Working Paper No. 3147-90-BPS.
540 M. lansiti / Research Policy 24 (1995) 521-542
Von Hippel, E. and M. Tyre, 1993, How 'learning by doing' is
done: Problem identification in novel process equipment,
MIT, Sloan School of Management Working Paper No.
BPS 3521-93.
Wheelwright, S.C. and K.B. Clark, 1992, Revolutionizing
product development (Free Press, New York).
7. Appendix: Empirical design
This appendix provides additional details on
the methodologies employed in this work.
7.1. The system focus index
The system focus index is the unweighted sum
of the 14 discrete variables listed in Table 2. It
probes into the mechanisms that exist for captur-
ing and accumulating knowledge about the pro-
duction process and the rest of the system. More-
over, it provides an indication of the level of
'system knowledge' that converges into the gener-
ation of project specifications. The index is made
up of three subindexes, each corresponding to
one of the factors in the definition of system
focus.
It is not feasible, within the scope of this work,
to provide a detailed description and motivation
for all of the indicators in Table 2. However, it
may be useful to discuss a few examples. The first
subindex explores the organization's emphasis on
the most fundamental project specification activi-
ties (indicators 1 and 2). It focuses on the 'in-
tegration group', which is defined as the group of
managers and engineers responsible for specify-
ing the detailed technological concept for the
new product. The group therefore sets up the
most critical project specification tasks and de-
fines the basic structure of the design hierarchy
for the new product (Iansiti (1991) 1992a). Indica-
tor 1, integration group exists, provides informa-
tion as to whether the role of integrator is singled
out and emphasized by the organization.
The second subindex group indicates the inte-
gration group's degree of focus on the discovery
of interactions between new design possibilities
and the organization's existing capability base
(indicators 3-9). It therefore gives an indication
of the extent to which the organization is assess-
ing the full impact of new choices on the design
hierarchy. For example, indicator 6, relocation at
uncertainty source, explores whether the engi-
neers performing the specification activities are
in a position to obtain direct and complete infor-
mation as to the uncertain impact of new capabil-
ities on existing facilities and equipment.
The third subindex group (indices 10-14) indi-
cates whether knowledge of the interactions of
new choices with the characteristics of the prod-
uct and production system is retained over subse-
quent product generations. For example, indica-
tor 14, continuous cycle (group), provides infor-
mation as to whether members of the integration
group work on a stream of products, facilitating
learning across projects and a seamless transfer
of system knowledge. 7
7.2. Measures of development performance
We developed several measures to character-
ize the evolution and performance of the differ-
ent organizations and development projects (see
Table 1). Measures were estimated from com-
pany records and interviews. Interviews were
cross-referenced to test the accuracy of the fig-
ures. The person years measure indicates the
level of engineering productivity of each project:
the lower the person years figure (given a specific
level of project content), the higher the productiv-
ity of the organization. The measure includes all
human resources used in the project, including
engineers, scientists, technicians and managers.
Supplier contributions were also included in the
figures.
Total lead time indicates the time elapsed
between the first explorations of technical possi-
7 It may be surprising that there is no indicator in the list
that deals with the impact of information technology. We
found that the impact of information technology tools such as
CAD systems in retaining system-level knowledge was quite
limited in this context. While the application of CAD was
extensive in performing basic design tasks such as circuit
layout, application of information systems was very limited at
the technology integration and concept development stage.
This appeared to be related to the extensive ambiguity pre-
sent in these early stages of the project, which made the
application of structured C A D / C A E systems difficult.
 M. lansiti / Research Policy 24 (1995) 521-542
bilities for a new product and its market intro-
duction. Total lead time is divided into concept
lead time and development lead time. Concept
lead time measures time elapsed between the
first technical explorations and the choice of
technical concept. The technical concept is a
specification of how individual technical ideas
and possibilities will be combined or 'integrated'
(Iansiti (1991) 1992a) to make up the new prod-
uct. The concept establishes which design and
manufacturing technologies will be used in the
product and outlines how these will function as
an integrated system to deliver the project objec-
tives. Furthermore, it also outlines how different
organizational subgroups (internal and external
to the firm) will combine to develop the product.
The technical concept therefore establishes a ba-
sic structure for the design hierarchy of the new
product. The choice is a major milestone in the
development process and is easily identifiable
from interviews and project records.
The development lead time indicates the time
spent performing the detailed design of the prod-
uct and its associated production processes. We
define it as the time elapsed between the estab-
lishment of the technical concept and product
introduction. It therefore indicates the time
elapsed after the organization has committed it-
self to a specific set of technological possibilities,
and performed the complex set of activities that
are required to transform a concept of the future
system into a real, functional.and manufacturable
entity. The development lead time also indicates
the time during which the bulk of the resources
are allocated to a project.
While project specification and project execu-
tion tasks will take place in any of the develop-
ment stages outlined, the bulk of activities before
the development of the technical concept are
aimed at project specification. On the other hand,
the bulk of the activities after concept selection
are aimed at project execution. While some de-
gree of project specification is possible after the
development stage has begun, we rarely wit-
nessed such situations. In practice, once a frame-
work for the project has been specified, basic
tasks have been partitioned, and organizational
subgroups have started working on project execu-
541
tion, respecifying the basic structure of design
choices can be quite difficult in a complex pro-
ject.
The fundamental development performance
measures we used in our analysis were develop-
ment lead time and engineering productivity. Pro-
ductivity figures indicate the efficiency of an or-
ganization in developing products. Differences in
development lead time are also important. A
shorter development stage allows an organization
to commit later to a particular technological con-
cept. This offers an important advantage in the
ability to adjust to evolving customer preferences
and to sample the latest available technical infor-
mation in the choice. Additionally, the develop-
ment stage in the process tends to require a much
higher level of human and capital resource com-
mitment than the exploration and integration
stages. A shorter development stage therefore
has the potential to lead to substantial develop-
ment cost and productivity advantages. Both pro-
ductivity and lead time measures were statistically
adjusted for differences in project content which,
as described below, offers a precise indication of
the technical functionality (performance quality)
of the subsystem.
7.3. Measures of project content
The choice of a highly standardized technical
environment was instrumental in allowing us ac-
curately to measure the lead time and productiv-
ity of different development projects. Given that
all projects in the sample were aimed at the
development of similar and well-characterized
products, data gathered on the person years of
effort and years of time elapsed could easily be
normalized for the relatively minor differences in
the content of the different projects. As we show
in our analysis, content adjustments did not influ-
ence our basic results, although they did improve
the statistical significance of the relationships.
We developed several independent measures
of project content, based on very different consid-
erations. The technical content measure is em-
phasized in this manuscript. It is based on a
primary functional performance variable charac-
terizing the module: the number of logic gates
542 M. lansiti / Research Policy 24 (1995) 521-542
packaged in a given area of substrate (number of
gates per square centimeter). The measure is a
good characterization of the overall functional
performance of the device, and depends on all
critical aspects of the design: the electrical me-
chanical and thermal characteristics of the sys-
tem. The technical content is defined as the ratio
of the number of gates per square centimeter
achieved by the project to the best value achieved
in the industry (best in class) at the time of
product introduction. The measure is expressed
as a ratio to account for the significant time-lags
between product introductions (given the rapid
pace of technological change in the industry, ab-
solute standards (time-independent) do not exist).
The use of a measure based on the gate den-
sity is not critical, however. Other technical mea-
sures (based on the line density or machine cycle
time, for example) were also used, which indi-
cated no substantial differences. We also devel-
oped measures which focused on the relative
functional performance of the new products at
the time of technical concept choice (concept
content), rather than at product introduction. Fi-
nally, we developed a measure based on internal
company evaluations of the project's difficulty
(process content; see Iansiti (1991) 1992b). Use of
these alternate measures did not change our re-
suits in a substantial manner. 8
8 The different measures of content defined were highly
correlated, indicating that they indicated a consistent level of
difficulty in each project. Both process and concept content
were significant at the 2% level in regressions with technical
content.