research policy - PBworks

ELSEVIER Research Policy 24 (1995) 521-542

research 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 discontinuous 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. Introduct ion

Technological evolution is a subtle process, f requently leading to shifts in the competi t iveness of firms. Several authors have shown that product development in an envi ronment undergoing technological change is given to f requent failure, even

* Work supported by the Division of Research, Harvard Business School. The author would like to acknowledge extensive 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.

in well-established and sophisticated organizations (e.g. Tushman and Anderson , 1986; Hen- derson and Clark, 1990). In this work, we argue that the effective managemen t of technological evolution in such settings is founded on a set of skills and routines that make up what we call the technology integration process.

A new product is the fruit of the fusion of new and existing knowledge. Novel technical concepts, such as may arise f rom the science base, can be a critical contr ibutor of new knowledge for product development . However, to be used effectively, these concepts must be carefully selected and adapted to match the complex requirements of an organizat ions 's existing environment . This is the focus of technology integration.

Technology integrat ion 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 details of the manufacturing environment. It is rooted in the early stages of a development project, and results in the creation of specifications which define the basic technological path to be followed in a given project. The technology integration process frames the project, providing a critical road map to guide design and development 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 investigation of the impact of technology integration routines on the performance of product development projects in environments characterized by discontinuous 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 obsolescence 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 performance 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 performance. Third, they dedicated to the process a group of individuals with rich experience of previous integration efforts and a detailed knowledge of the organization's existing capabilities. We characterized organizations following this approach 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 development 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 performance in complex environments characterized by discontinuous technological change. The conjec- tures, relating organizational processes and a problem-solving approach to development performance, 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 development 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 523

discontinuous technological change. By discontinuous, we mean that relationships between product functionality, process requirements and disciplinary expertise change, necessitating a substantial evolution in the knowledge base of the development 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 problem-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 discontinuous technological evolution causes the obsolescence of established capabilities in the organization. Many academics have studied the response and adaptation of organizations to technological 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 impact 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 second 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,

1989; Cusumano, 1992; Cusumano and Nobeoka, 1992; Bowen et al., 1993). This work demon- strates the effectiveness of several specific routines 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 routines 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 identified 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 evolution, and on the management of R&D organizations.

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 generation of new knowledge. We therefore begin from the basic premise that effectiveness in product development is linked to the problem-solving behavior 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 generation of solutions, and the generation of criteria (or frames) for evaluating those solutions. They pointed out that a characterization of both activities 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) argued that the evolution of frames of reference is the foundation for learning and technological evolution in an R&D organization. Schrader et


al. (1992) emphasized the difficult nature of problem framing and solving in situations characterized 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 situations, 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 problem-solving in a project characterized by technological 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 industry elevated the importance of the product's mechanical systems and changed fundamental linkages between component characteristics and product performance. This caused critical problems 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 traditional 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 proximity 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 previously 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 framing 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 characterized by technological discontinuities, high problem-solving efficiency (and development performance) will be associated with approaches that sample a broad base of disciplinary expertise - 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-solving 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 organization's product development activities (see also Clark and Fujimoto, 1991; Bowen et al., 1993).

We have found it useful to differentiate between two types of product development routines: 'project specification' and 'project execution'. 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 routines 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 hierarchy, while execution routines carry out the decisions imbedded in the hierarchy (Clark, 1985). Within Von Hippel's task-partitioning approach


(1990a), specification routines are aimed at partitioning the overall design problem into smaller subproblems, making up manageable tasks which can subsequently be executed.

If the knowledge base surrounding a development 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 critical source of difficulty encountered by organizations in responding to novel situations is their continued reliance on obsolete historical design approaches, which results in the suboptimal specification 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 execution begins, the most critical decisions regarding the approaches to be taken in a project are usu- ally made during the planning and concept development stages (Wheelwright and Clark, 1992). These decisions have an important explicit impact on a project, since they define its principal objectives. In addition, the decisions also carry a critical 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 project, 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 mechanical 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 evolution in the organization. Once the window is closed, the basic options and approaches will have been selected, tasks will have been partitioned and assigned, and the project will rapidly

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 decision 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 organization's capabilities. Moreover, project specification should be kept flexible until informed decisions can be made, avoiding closing the window prematurely.

2.3. Effective management of technology integration

The effectiveness of project specification routines will be linked to the generation of knowledge about the interactions between new approaches and the existing capabilities of the organization. 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 understanding will allow the recognition of new poten- tially beneficial interrelationships between knowledge bases, as well as awareness of the emergence 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 improvements 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-


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 development process. Kasper would have benefited from a technology integration process that proactively encouraged the re-evaluation of the existing pattern of design decisions, devoting both resources and expertise to the tasks. Kasper's process appears 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 technological change, supported by a broad knowledge base and a flexible approach to problem solving.

A system-focused process for technology integration first of all emphasizes project specification tasks by dedicating adequate resources and time to them. As with Kasper, many organizations do not focus attention on this aspect of product development, and the activities are performed by a variety of organizational subgroups

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 decisions. If circumstances require it, a system-focused process will therefore break with past design approaches.

A system-focused process hinges on a thor- ough (but flexible) foundation of 'system' knowledge. 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 experience in such situations is very high (e.g. Leonard-Barton, 1988). System-focused organizations 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

System Focus emphasis on project specification generation of knowledge of systemic impact

of individual design choices systematic retention and application of

system knowledge

Development Performance P3

I °blemS°lvmgB ad sampling broad disciplinary expertise in

problem identification and solution

Fig. 1. A framework for development performance in environments characterized by discontinuous technological evolution.


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 resources to technology integration, particularly during project specification; (2) 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) retains past knowledge of related technology integration efforts ('system knowledge').

We conjecture that in a discontinuous technical 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 characterized by a broader problem-solving approach than other organizations. A focus on project specification activities will engender the consideration of a broader set of alternative solutions in problem-solving attempts.

Proposition 3. System-focused organizations will be associated with a broader approach to solving problems than other organizations-this will involve information search and processing activities that cross a broader base of existing disciplinary expertise.

To summarize, we have developed a set of propositions that relate development performance to the problem-solving approach and other characteristics of an organization's development

process in situations characterized by discontinuous 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 performance in an environment characterized by discontinuous 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-defined 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 technological 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 environment 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 projects.

To obtain comparable observations, we focused on the development of technologies associated with the packaging and interconnect system of the mainframe processor, the 'multi-chip module'. Mainframe multi-chip modules connect individual 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 technical 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

development of modules for mainframe computers. These investigations were used to develop the basic conceptual and empirical frameworks for the study. In particular, we developed a precise indicator for system focus based on the factors outlined in Definition 1. After the end of the pilot phase, we collected observations on the major projects performed by firms in the industry over the past 10 years. Our sample was made up of all companies in the mainframe computer industry, 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 performed 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 completion 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 individual approaches to design choice and problem solving by gathering detailed case histories of 61 problem-solving efforts. We interviewed the individuals involved and cross-checked the information by examining written technical accounts. The problems were selected as being 'the most difficult 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-solving 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 performed 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-

Policy 24 (1995) 521-542

Table 1 Summary of principal variable definitions (see Appendix for details)

Total lead time

Concept lead time

Development lead time

Person years of engineering and scientific activity

Technical content

Time elapsed between the beginning of the project and market introduction. The project beginning is defined as the start of the first scientific investigations of new technologies specifically targeted for possible inclusion in the new product design effort

Time elapsed between the beginning of 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 product

Difference between total lead time and concept lead time. Indicates the time spent during the 'development' stage of the project. During this phase the activities focus on the detailed design of the product and associated processes, based on the concept and specifications established during the previous stages

Level of technical and managerial human resources used for the length of the entire project. Includes engineers, managers, scientists and technicians internal and external to the firm

Ratio of the number of 'logic 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 a good characterization of the overall functional 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 problem-solving attempts. Our approach was based on a technical analysis of the path taken in the 61 problem-solving cases captured during our empirical work. Our measure of problem solving

M. lansiti /Research Policy 24 (1995) 521-542 529

breadth is linked to the number of independent knowledge bases or disciplines sampled during each problem-solving attempt. We call our approach '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 processes 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 additional 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, semiconductor material science, metallurgy, polymer chemistry, structural engineering (mechanical design) and thermal engineering, t Three of the knowledge 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 reliability analysis and thermal engineering to the design of the critical cooling system.

information search and processing activities in each problem-solving effort. The number of knowledge bases sampled during the identification 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 analyzed 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 development 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 ceramicists 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.


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 between problem-solving breadth and project performance, and continue by looking at the relationship between system focus and project performance. We then close the logical loop by examining 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 problem-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 productivity). Technical content was included explicitly in the regressions, rather than using content-adjusted 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 intriguing. While context-specific breadth is highly significant (and negatively correlated with person years) context-independent breadth is not significantly 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 number of degrees of f reedom in analysis involving problem-solving indexes is therefore lower than that for the entire sample.

problem-solving breadth in Table 4. The relationship between development lead time and problem-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 significant and negative. However, model A6 indicates that the relationship between context-independent breadth and lead time is not significant. 5

The difference in significance between context-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 knowledge of the firm's manufacturing capabilities, knowledge of the firm's mainframe design (outside of the module subsystem), and knowledge of supplier capabilities. In contrast, context-independent breadth included general, universally ap- plicable, traditional disciplines, such as ceramic material science or thermal engineering. Our results indicated that the components of problem- solving breadth correlated with project performance are those specific to the firm's environment, such as the awareness of subtle design and manufacturing considerations.

This result is consistent with the likely evolution 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 resources to the project until they feel the deadline can be met. Productivity may therefore be a more representative performance 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 metallurgy, since the design of ceramic multi-chip modules 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 involve both knowledge bases.

In contrast with well-defined traditional disciplinary knowledge bases, context-specific knowledge 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 Individual with great depth and breadth of knowledge is in the integration group.

11. Technical expert is project manager

12. 'T' specialization

13. Continuous cycle (firm)

14. Continuous cycle (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


Table 3 Regression results on the association between person years, problem-solving breadth indexes and technical content

Dependent variable Person years Person years Person years

Model name Constant Problem-solving

breadth Context-specific

breadth Context- independent

breadth Technical content

F-test P Adjusted R 2 Residual degrees of

freedom

A1 A2 A3 364.46 294.08 110.03

-524 .80 *** (205.61)

-478 .99 ** (195.09)

63.37 (409.43)

576.28 **** 549.01 **** 589.21 **** (183.94) (186.22) (209.46)

8.46 8.13 4.07 0.002 0.002 0.031 0.374 0.363 0.197

23 23 23

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; ***** significance 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 ceramic 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

Dependent variable Development lead Development lead Development lead time time time

Model name Constant Problem-solving

breadth Context-specific

breadth Context- independent

breadth Technical content

F-test P Adjusted R 2 Residual degrees of

freedom

A4 A5 A6 5.73 5.46 3.98

- 3.28 **** (1.10)

- 3 . 4 5 **** (0.99)

1.98 (2.25)

1.46 1.24 1.45 (0.99) (0.94) (1.15) 5.67 7.51 1.32 0.010 0.003 0.285 0.330 0.343 0.103

23 23 23

The table displays regression coefficients unless otherwise indicated; numbers in parentheses are s tandard errors. * 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.


Tab le 5 Regres s ion resul ts on the assoc ia t ion be tween project perfor-

m a n c e var iables , sys tem-focus indexes and techn ica l con ten t

D e p e n d e n t va r iab le Pe r son years D e v e l o p m e n t lead

t ime

M o d e l n a m e B1 B2

Cons t an t 567.68 6.62

System focus - 5 2 . 6 4 ***** - 0 . 2 8 5 *****

(12.76) (0.0726)

Techn ica l con ten t 590.94 ***** 1.56

(155.03) (0.882)

F- tes t 15.95 9.33

P 0.0001 0.001

Ad jus t ed R e 0.535 0.391

R e s i d u a l deg rees of 24 24

f r eedom

The tab le d isplays regress ion coeff ic ients unless o the rwise

ind ica ted ; number s in p a r e n t h e s e s a re s t andard errors . * sig-

n i f icance at the 10% level; ** s igni f icance at the 5% level;

• ** s igni f icance at the 2% level; **** s igni f icance at the 1%

level; ***** s igni f icance at the 0 .1% level.

However, when the module was transferred to the pilot plant, the problem recurred. Once again, the material scientists were called in to refine the

composition of the metal paste. Once again the problem appeared to have been resolved. How- ever, when the substrate was transferred to the production facility, it recurred again, causing additional delays. These problems combined to de- lay the project for a total of 2 years.

A second organization experienced the same buckling problem. Rather than limiting the search for solutions to the field of metallurgy, however, the engineers involved in early project specification (the 'integration group') framed the problem broadly and searched for solutions in a number of different contexts. They examined the potential of using new materials, changing the architecture of the product, or modifying its production process. Moreover, they tried a combination of the above solution strategies. They had a very good awareness of how the different elements of the product and production system might have an impact on this problem. For example, members of the integration group had helped select the manufacturing equipment, and were aware that some of its characteristics might have a subtle

Tab le 6 The cor re la t ion be tween indiv idual ind ica tors of system focus and deve lopmen t speed and product iv i ty

Person years D e v e l o p m e n t

res idua ls lead t ime res idua l s

1. I n t eg ra t i on g roup exists - 0 . 6 3 ***** - 0 . 4 4 5 ***

2. I n t eg ra t i on t e a m ded ica ted - 0.439 ** - 0.393 **

3. Day- to-day contac t wi th p lan t - 0.525 **** - 0.539 **** 4. Fix p roduc t ion p rob lems - 0.446 **** - 0.392 **

5. M a n u f a c t u r i n g eng inee r ing - 0.432 ** - 0.402 **

g roup not on cr i t ical pa th

6. Re loca t ion at uncer t a in ty - 0.514 **** - 0.478 *** s o u r c e

7. Choose p roduc t ion vo lume - 0.343 * - 0.419 **

e q u i p m e n t 8. In te rac t s wi th sys tem group - 0.550 **** - 0.449 ***

9. In te rac t s wi th c o m p o n e n t - 0.447 *** - 0.667 *****

groups

10. Techn ica l exper t exists 11. Techn ica l exper t is project - 0 . 2 8 5 - 0 . 1 2 7

m a n a g e r

12. 'T ' spec ia l iza t ion - 0 . 5 4 6 **** - 0 . 5 8 2 ****

13. Con t inuous cycle (f i rm) - 0.149 - 0.205

14. Con t inuous cycle (group) - 0.503 **** - 0.576 ****

Person year and d e v e l o p m e n t lead t ime res idua l s are t aken f rom a regress ion be tween technica l con ten t and person years and

d e v e l o p m e n t lead t ime, respect ively. Ind ica to r n u m b e r 10 had zero va r iance and thus its co r re la t ion could not be computed . * s igni f icance at the 10% level; ** s igni f icance at the 5% level; *** s ignif icance at the 2% level; **** s ignif icance at the 1% level; ***** s ignif icance at the 0.1% level.


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 production equipment, which had only recently been delivered. After extensive analysis and the consideration of a variety of solutions, the integration 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 organization, 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 organizational process on performance. Our results are consistent with Proposition 2, and show that system 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 development projects more quickly and using fewer resources. As with the previous regressions, technical 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

project performance. Table 6 displays the correlation 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 correlation indicates that the system-focus indicators are indeed consistently associated with higher productivity 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 process for technology integration is linked with development performance in this environment. In other work (Iansiti, 1992b, 1993) we have investi- gated the impact of geographical origin on development 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 system-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-functional integration and project leadership (Allen et al., 1980b; Clark and Fujimoto, 1991). While the traditional factors did show occasional positive

Table 7 Regression results on the association between problem-solving breadth indexes and system focus

Dependent v a r i a b l e P r o b l e m - s o l v i n g C o n t e x t - s p e c i f i c Context-independent breadth breadth breadth

Model name C1 C2 C3 Constant - 0.0747 - 0.218 0.145 System focus 0.0615 ***** 0.0636 ***** - 0.0024

(0.0082) (0.0094) (0.0086) F-test 55.93 45.82 0.084 P 0.0001 0.0001 0.774 Adjusted R 2 0.687 0.656 -0.038 Residual degrees of 24 24 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; ***** significance at the 0.1% level.


correlation with productivity and development lead time, our analysis indicated (Iansiti, 1993) that only system focus was consistently associated with development performance.

These results are consistent with our conceptual framework. In this environment, dominated by discontinuous technological evolution, traditional organizational approaches to project management did not appear to be sufficient to achieve a fast and productive development organization. While effective companies appeared consistently characterized by good project management practice (as described, for example by Clark and Fuji- moto, 1991), these practices did not differentiate them from less effective competitors. The most critical activities in differentiating companies were instead rooted in the early stages of product development and were aimed at technology integration. The most effective organizations emphasized the critical role played by project specification tasks, a broad approach to the evaluation of design choices, and the value of accumulating knowledge of previous technology integration activities.

4.3. Development process and problem-solving approach

Table 7 displays the results of three regression models that relate an organizational approach to problem-solving breadth. In accordance with Proposition 3, the problem-solving breadth index is significantly associated with system focus. Simi- larly, context-specific breadth and system focus are significantly related. In contrast, context-independent breadth is not associated with system focus. These results are consistent with the regressions presented above and close the logical loop in linking problem-solving breadth, system focus and development performance.

Table 8 displays some important characteristics of the problem-solving attempts we analyzed, grouped by type of organization. The distinction between 'system-focused' organizations and 'other organizations' was based on the system-focus index. System-focused organizations were defined as having a system-focus index greater than sample average.

Table 8 Problem characteristics and outcomes for different organizational groups

The problem: Total System- Other sample (%) focused organiza-

organizations (%) tions (%)

Was identified before 69 75 62 concept selection Was worked on before 67 75 59 concept selection Was fixed before 44 59 28 concept selection *** Recurred after concept 25 16 35 selection * Caused delays late in 56 41 72 the project ***

Concept selection corresponds to the end of integration activities, which take place before detailed design has begun, as described in Section 2. Problems ' identified' were ones that project members had conjectured would be particularly chal- lenging during the project. Problems 'worked on before concept selection' were ones to which the organization had de- voted some resources before the integration phase was complete. Problems 'fixed' before concept selection were ones whose early solutions were robust enough to work in the final production environment. Problems which ' recurred ' were ones whose early solutions did not work in the final production environment. Problems which 'caused delays late in the project' were ones that were not 'fixed before concept selection'. *** indicates that values for the 'system focused' and 'other ' groups were significantly different at the 2% level, as indicated by a t-test. * indicates that the significance level was 10%.

The evidence from Table 8 indicates that system-focused organizations approach technical problems in a manner significantly different than the rest of the sample. The difference is not in problem identification, however. Organizations in the entire sample appeared to do a good job of identifying potential problem areas early in the project, before concept selection was completed. Most of the critical technical challenges in the project were apparently obvious enough to be targeted for early action. The real differences appear when one considers the robustness of early solutions. System-focused organizations were characterized by a significantly higher pro- portion of problems that were fixed by early efforts, and thus by a significantly lower percentage of late problems. In other words, system-


focused organizations actually fixed the problems in early efforts. In other organizations, individuals 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 organizations 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 between more or less effective problem-solving strategies. Much of the literature has focused on the importance of problem identification in approaching technically ambiguous problems (Hen- derson and Clark, 1990; Schrader et al., 1992). Our findings indicate instead that a broad problem-solving strategy must be carried out consistently 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 solution 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 routines 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 between 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 understanding 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 understanding that both materials engineering and production expertise may be needed. Instead, integration group members must have the experience and capability to realize that a given solder- ing material may have a subtle impact on a specific 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 manager in one of the most effective organizations, " . . .we no longer have the luxury to spend much time communicating-the problems are too complex 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 many . . . " 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 substantial decreases in market share. The role of


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 technology 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, specialization and decision making, and can therefore 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 linkage between system and components. Even if we view the processor module itself as a system, the basic elements that make it up (mainly the substrate, cooling system and integrated circuits) did not change. They still contributed to the functionality 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 'architectural' 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 specifically designed the latest module to minimize any

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 dynamic 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 production process. Instead, we go back to the work of Marple (1961) and Clark (1985) in using the entire 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 components, 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 development 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).


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 knowledge base required for development. This implies that our propositions could be tested in a broad variety of industries, not all of which entail products that are traditional 'systems', but whose knowledge base is complex and undergoes discontinuous 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 software applications is an example of a discontinuous evolution that fundamentally rearranged the structure of software development and its associated knowledge base.

Additional research is needed to generalize our observations. While our propositions are general, 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 effective technology integration vary from environment 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 technology 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 discontinuities and dominant designs: A cyclical model of economic 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 production 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 organizational 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 development: 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-


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 innovation: 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 development, 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 capabilities, 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 adaptation 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

structure of 'unstructured' decision processes, Administra- tive Science Quarterly 21,246-275.

Moch, M. and E.V. Morse, Size, centralization and organizational 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 discontinuities 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 organizational 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 opportunity: Creating occasions for technological adaptation in organizations, MIT, Sloan School of Management (revised) 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 research: Towards verbal and statistical correspondence, Academy of Management Best Paper Proceedings.

Von Hippel, E., 1990a, Task partitioning: An innovation process variable, Research Policy 19, 407-418.

Von Hippel, E., 1990b, The impact of 'sticky data' on innovation and problem solving, MIT Sloan School of Manage- ment Working Paper No. 3147-90-BPS.


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 production process and the rest of the system. More- over, it provides an indication of the level of 'system knowledge' that converges into the generation 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 activities (indicators 1 and 2). It focuses on the 'integration group', which is defined as the group of managers and engineers responsible for specifying 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 information as to whether the role of integrator is singled out and emphasized by the organization.

The second subindex group indicates the integration 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 engineers performing the specification activities are in a position to obtain direct and complete information as to the uncertain impact of new capabilities on existing facilities and equipment.

The third subindex group (indices 10-14) indicates whether knowledge of the interactions of new choices with the characteristics of the product and production system is retained over subse- quent product generations. For example, indicator 14, continuous cycle (group), provides information 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 characterize the evolution and performance of the different organizations and development projects (see Table 1). Measures were estimated from company records and interviews. Interviews were cross-referenced to test the accuracy of the figures. 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 productivity 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 present in these early stages of the project, which made the application of structured CAD/CAE systems difficult.


bilities for a new product and its market introduction. 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 product. 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 objectives. 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 basic 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 product 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 itself 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 execution tasks will take place in any of the development 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 degree of project specification is possible after the development stage has begun, we rarely wit- nessed such situations. In practice, once a framework for the project has been specified, basic tasks have been partitioned, and organizational subgroups have started working on project execu-

tion, respecifying the basic structure of design choices can be quite difficult in a complex project.

The fundamental development performance measures we used in our analysis were development lead time and engineering productivity. Pro- ductivity figures indicate the efficiency of an organization 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 concept. This offers an important advantage in the ability to adjust to evolving customer preferences and to sample the latest available technical information in the choice. Additionally, the development 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 development cost and productivity advantages. Both productivity 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 productivity 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 influence 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 considerations. The technical content measure is emphasized in this manuscript. It is based on a primary functional performance variable charac- terizing the module: the number of logic gates


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 mechanical and thermal characteristics of the system. 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 density is not critical, however. Other technical measures (based on the line density or machine cycle

time, for example) were also used, which indicated no substantial differences. We also developed 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-

8 suits in a substantial manner.

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.

Documents

research policy - PBworks