1. aoshima, y. industrial relations

8/17/2019 1. Aoshima, y. Industrial Relations

1/24

Transfer of System Knowledge Across

Generations in New Product Development:Empirical Observations from Japanese

Automobile Development

YAICHI AOSHIMA*

The objective of this article is to explore effective ways of retaining knowledge

involved in new product development. Although human-based mechanisms,

such as the direct transfer of project members, more effectively convey

knowledge required in design integration at the higher level of product systems,

the article shows that standardized mechanisms are more appropriate for

retention of lower-component knowledge. However, it is also argued that

product architecture affects these relationships through its impact on a locus of

design change in a product system. Such argument is partially tested in the

context of the Japanese automobile industry.

Introduction

Ever since effective new product development became crucial for competi-

tiveness in many industries, numerous researchers have explored factors

affecting new product development performance. Many of these studies focus

on development processes within a single development project at a specific

point in time. However, the transfer of technologies and other product-

related knowledge across different generations of projects has received littleattention. A new product, by definition, should involve ‘‘newness’’—be

different from past products. Thus, many researchers have addressed the issue

of how to break automatic knowledge flows from preceding projects, and

knowledge retention tends to be regarded as an obstacle to innovation or

*Institute of Innovation Research, Hitotsubashi University, Tokyo, Japan.

Industrial Relations, Vol. 41, No. 4 (October 2002). 2002 Regents of the University of CaliforniaPublished by Blackwell Publishing, Inc. 350 Main Street, Malden, MA 02148, USA, and 108 Cowley

Road, Oxford, OX4 1JF, UK.

605


2/24

something to be avoided (Allen and Marquis 1964; Leonard-Barton 1992;

Henderson and Clark 1990; Anderson and Tushman 1990; Dougherty 1992).

However, in most cases, new products are not ‘‘completely’’ new, neither

in terms of technology nor market concepts. A technology developed forone product subsequently may be used in a range of products (Cusumano

1991; Meyer and Utterback 1993; Uzumeri and Sanderson 1995; Cusumano

and Nobeoka 1998). Additionally, knowledge about existing customers can

be a useful basis for interpreting current customer needs (Christensen and

Rosenbloom 1995). Therefore, successful new product development at least

partially depends on the ability to understand technical and market

knowledge embodied in existing products, and the adaptation of this

knowledge to support new product development (Iansiti 1997; Iansiti and

Clark 1994).Drawing on examples from the Japanese automobile industry, this study

explores effective ways of retaining knowledge across different generations

of product development. In the subsequent sections, I discuss two broadly

defined mechanisms for knowledge retention—human-based and standard-

ized mechanisms—by illustrating some practices of Japanese automobile

producers. I then identify two factors that affect the relative effectiveness of

these two mechanisms. Next, I examine my argument empirically by using

data obtained from 223 engineers engaged in 25 new automobile develop-

ment projects at seven Japanese automobile producers.

Knowledge Retention Mechanisms

The existing literature proposes several mechanisms for retaining

knowledge (Walsh and Ungson 1991; Krippendorf 1975; Huber 1990,

1991; Garud and Nayyar 1994), but for the sake of simplicity, this article

will focus on just two of these mechanisms. The first is a human-based

mechanism. Knowledge obtained through past development activities may

be partially stored in individuals. Therefore, bringing persons who haveappropriate experience in past development into current projects is one way

to transfer knowledge across generations (Roberts 1979). In an extreme

case, the same group of people successively takes charge of multiple

generations of product development. There are, however, obvious limita-

tions in completely depending on a particular individual or group: when

people leave, knowledge disappears. To overcome this problem, companies

may partially overlap project members across different generations and

create a chain of overlapped common experience among their people. For

example, Nakayama (1997) investigated the history of Japanese aircraft

606 / Yaichi Aoshima


3/24

development from the Zero fighter in the 1930s to the FSX support fighter

in the 1990s and found that ‘‘development technology’’ has long been

retained either through continuity of key persons or by overlapping project

members across different generations of projects. In particular, he foundthat overlapped membership in the medium-scale intermediate projects,

which bridge the gap between large-scale next-generation projects, played

an important role in retaining development technology.

This study of the Japanese automobile industry reveals the same kind

of overlapped membership across generations of projects. For example,

Figure 1 shows the project manager groups on the Celica/Carina/Corona

projects in Toyota.

The figure shows that most project managers for these projects were

promoted from their former positions as subproject managers within thesame series development. At Toyota, project mangers and their staff

formerly worked in the Product Planning Office.1 Typically, engineers with

seven to 10 years’ experience in body design or chassis design move to the

Product Planning Office at around age 30. They then become responsible for

particular vehicle development projects, working as staff members of project

managers. New entrants to the Product Planning Office start from the Shu-

tantoin (a lower-ranked subproject manager). They are then promoted to

the Shusa-tsuki (a subproject manager) and Shusa (a project manager),

most often within the same product line.2 They are trained as candidates for

future project managers and learn how to coordinate and integrate theentire product development process. Once they become Shusa (now Chief

Engineer (CE)), they tend to be responsible for two successive product

generations. As a reason for this continuity of project managers,

Mr. Nakagawa, CE for the fifth generation of the Celica project, made

the following comment:

Even if the present Celica uses a different technological concept from the past, the

characteristics of users have some commonalty. To understand the characteristics

of users needs long experience [therefore, a project manager tends to stay in the

same project for a long time]. For example, although the current Celica sharesbasically the same 2.2 liter engine, 5SAF, with the Camry, we did not use the

balance shaft for the Celica engine, because I knew that Celica users require more

power at the cost of noise. Also, when we decided to carry over a part of the under-

floor panels from the previous model, I learned from the past project several issues

1Toyota reorganized its product development organization in 1992 and divided it into three vehicle

centers and one advanced engineering center. The Product Planning Office was disbanded and absorbed

into each of three vehicle centers.2In the late 1980s, Toyota changed these titles. Since then, what was formerly a Shusa is called CE

(Chief Engineer); the former Shusa-Tsuki is called Shusa.

Transfer of System Knowledge Across Generations / 607


4/24

such as what kinds of problems occurred in previous projects both in technical and

user characteristics.3

This comment seems to indicate that continuity of project members may

be required to deepen the understanding of linkages between user needs andrequired design features.

Another mechanism for knowledge retention is a more standardized one.

Project members may document knowledge obtained from past development

activities in written or electronic form. A drawing or blueprint used in design

activities can contain important knowledge. Companies also can make use of

various others kinds of documents and reports for retaining past experiences.

Such documents and reports vary in terms of their formality. For example,

FIGURE 1

Project Management Groups of the Celica/Carina/Corona Projects

3Interview with Mr. Nakagawa, Chief Engineer, Toyota Motor Corporation, May 31, 1994.



5/24

documents and reports used at Japanese automobile producers can be

broadly classified into the following categories (although boundaries

between these categories differ somewhat across companies):

1. Companywide technical standards (e.g., Toyota Technical Standard).

2. Department-level design standards, standardized design (test) proce-

dures, and design (testing) tools (e.g., Layout Check List at Honda).

3. Formal reports and documents storing nonstandardized knowledge,

such as process and design know-how documents, testing reports, and

user-claim reports (e.g., Know-How Document at Mitsubishi).

4. Informal documents and memos to keep track of past problematic and

successful cases (e.g., Problem-Information Memo at Mitsubishi).

The first two documents describe standards and rules that engineers mustfollow. The last two documents are more flexible and describe design

know-how, testing results, and other problematic and successful cases found

in previous development activities. Japanese automobile producers use such

documentation extensively as a means to store knowledge about past

practices. Although engineers are not obliged to record information, it

seems to be a common practice for them to write down information

obtained from their development activities.

In addition to documents, an advanced computer-aided design (CAD)

system helps project members store and retain knowledge. CAD systems

serve not only as tools to help design and test, but also as facilities for

retaining prior knowledge obtained through design and testing experiences.

Data stored in the CAD system can be directly reused in future design work.

For example, since an automobile body consists of several separate body

panels (e.g., front, center, and rear floor panels), each of which has a

particular drawing stored in CAD, designers often reuse and edit designs

from existing body panels and recombine them with newly designed panels

to develop the entire body design. Similarly, computer-aided engineering

(CAD) models reflect knowledge obtained from the prior prototype testing.

Whether companies develop their own CAE models or use commercialpackages, it is critical to incorporate their experience of actual prototype

testing into CAE models to make it usable.

Factors Affecting Effectiveness of Transfer Mechanisms

When should companies depend on a human-based mechanism for

retaining knowledge in product development? When should they use a more



6/24

standardized mechanism? What determines the relative effectiveness of these

two methods? The following sections discuss two factors that have the

potential to affect effectiveness: the nature of the knowledge and the

frequency of design changes needed for a particular product architecture.

Nature of Knowledge Retained. First, some knowledge is inherently more

suitable for a human-based knowledge retention mechanism than for an

archival-based one, and vice versa. The inherent nature of knowledge

directly influences the effectiveness of retention mechanisms. This article

pays particular attention to the systemic nature of knowledge and the

associated context-specificity (Zander and Kogut 1995; Garud and Nayyar

1994; Badaracco 1991; Iansiti 1998).

As many researchers have pointed out, the design of new ‘‘systems’’products (i.e., products that contain numerous components and technol-

ogies that must work together) invariably depends on a complex interaction

among potentially fragmented individual knowledge bases (Clark and

Fujimoto 1991; Henderson and Clark 1990; Iansiti 1997; von Hippel 1994).

On the one hand, knowledge required for new product development comes

from various domain-specific and specialized disciplinary areas. Such

knowledge tends to be generalizable and independent of a specific context.

On the other hand, new product development demands the integration of

specialized knowledge with other information and its application to specific

contexts. This latter type of knowledge will be called ‘‘system knowledge.’’4

Architectural knowledge, defined by Henderson and Clark (1990) as

knowledge that is about the interactions between physically distinctive

components, is one special case of system knowledge.

Development of a printer, for example, calls for an understanding

of precision machinery engineering, mechanical engineering, optical elec-

tronics, material sciences, imaging science, and so on. However, a mere

collection of such specialized knowledge does not necessarily lead to the

development of a good commercial printer. For a printer to work well as a

coherent system, engineers must understand complex interactions and subtlebalances among such specialized technologies and knowledge, which must

be managed so as to adapt the end result to a particular use environment.

The system/domain-specific dimension of knowledge is closely connected

to the tacit/explicit dimension, which many management studies have

discussed (Nonaka 1994; Zander and Kogut 1995; Garud and Nayyar

1994). System knowledge tends to be tacit. It is difficult, if not impossible, to

articulate system knowledge because of its embeddedness in a specific

4Iansiti (1997) uses the same conceptualization of system knowledge.



7/24

context. This embeddedness is one element of ‘‘tacit knowing,’’ a concept

introduced by Polanyi (1966). According to him, we may say that we know

more than we can tell when we comprehend the entity (a whole) without

being able to specify its particulars (parts). He describes ‘‘achieving anintegration of particulars to a coherent entity to which we are attending.

Since we were not attending to the particulars in themselves, we could not

identify them (p. 18).’’ For example, we can identify physiognomy without

specifying its features.

The same concept can be illustrated by the development of products

consisting of various components and technologies. Throughout product

development processes, project managers try to find an appropriate way to

integrate components, technologies, and other elements so that all will

function together as a coherent product system that will be valuable totargeted customers. The appropriateness of this integration is understand-

able only in light of the context of the final product, which is mostly

provided by users of the product. The relationship between this context and

the product’s elements tends to remain tacit.

For example, in the case of automobile development, vehicle styling

solely for the purpose of maximizing aerodynamic performance can be

theoretically determined and generalizable. However, linkages between the

styling, the body structure, the engine shape, and the suspension type will

be different among vehicles, which will be of different sizes, for different

purposes, and have different customer bases. Without understanding sur-rounding contexts of the product, one cannot know how and why the

components are integrated in a particular way. In other words, we cannot

communicate what we know about the integration of components without

sharing the contexts.

Regarding the context-specific nature of system knowledge, von Hippel

and Tyre (1995) found that problems in the introduction of new process

technology were often discovered through learning by doing by field

engineers after process introduction. Since such problems are invariably

caused by subtle and specific interactions among particular attributes of machine design and user environments, they are difficult to predict. Since

field problems in production machines depend on context-specific factors,

scientific investigation to discover universal cause-effect relationships may

not be very effective.

For context specific-knowledge to be usable in other settings, people

need to retain and transfer information about numerous surrounding

contingency factors behind easily observable facts and results. Therefore, it

can be quite costly, if not impossible, to articulate context-specific system

knowledge.



8/24

The most direct way to transfer and retain less-articulable and context-

specific system knowledge may be to transfer or retain individuals who have

first-hand experience with the context. In some cases, system knowledge

may be held by a group of people who share the context. In other cases,system knowledge might be embedded in specific relationships between

people. This latter situation might make it necessary to retain the same

group of people for a long period of time. Wilson and Hlavacek (1984)

found that firms that benefited from technologies created in past projects

kept knowledge alive by the active presence of a core group of people.

Accordingly, I hypothesize that the more knowledge is systemic, the more

effective a human-based retention mechanism is, such as the direct transfer

of individuals or a group of people with shared experience. On the other

hand, the more knowledge is domain-specific and specialized, the best wayof retaining it is through the use of archival mechanisms, such as

documentation, standardization, and computerized systems.

Frequency of Design Change. The second factor affecting the relative

effectiveness of retention mechanisms is the frequency of design changes.

Retaining knowledge through standardized mechanisms often takes more

time than through human-based mechanisms because the former includes

articulation processes, abstraction from experiences, and knowledge

transformation between different media. If market conditions change

rapidly and fast product development cycles are critical to competition,retaining and quickly utilizing knowledge across generations of projects

may become particularly important. If companies devote too much time to

articulating past experience as, for example, propositions and causal

relationships, the experience may become outdated before it can even be

used.

As noted above, articulating knowledge is also costly. Design standard-

ization efforts, for example, often start by collecting the direct experiences

of first-ranked engineers. To promote standardization, companies may have

to ask such engineers to temporarily leave their current tasks, incurringhuge opportunity cost. If articulated and systematized knowledge is

applicable for a relatively long period of time, such costs can be justified.

If projects can use standardized designs for many generations, standard-

ization becomes an efficient way to retain knowledge. However, when

product change takes place frequently due to fast-changing environments,

the cost of maintaining and renewing articulated knowledge increases

considerably. Thus, the more frequent changes a product design receives,

the more efficient human-based mechanisms of knowledge retention become

compared to standardized mechanisms.



9/24

System knowledge can be retained through standardized mechanisms if

projects have very few design changes at the system level. However, project

development may have to depend on human-based mechanisms of

knowledge retention if there is considerable and rapid design fluidity.The relative frequency of change between the system level and the

component or subsystem level is influenced by the design strategy of

product architecture, whose role is discussed below.

Product Architecture and Locus of Change. Product architecture is one

characteristic of a product system that involves interdependency between

the constituent components. This interdependency is, in turn, determined by

the pattern of allocating product functions to constituent components and

the interfaces between these constituents (Ulrich 1995; Ulrich and Eppinger1994). Figure 2 classifies product architectures along these two dimensions.

FIGURE 2

Types of Product Architecture



10/24

Under a modular architecture, located in the upper-right cell, a product

system is divided into several physical chunks called modules, each of which

has a simple correspondence to a particular product function (Ulrich 1995).

Simple rule-based relationships among modules lower interdependencybetween constituents and maintain high design flexibility at the module

level. For example, a stereo system consists of a CD player as an input

device, an amplifier as an audio signal processor, and a speaker as an output

device. Each device or module has its own exclusive function and there are

standardized interfaces between them. As a result, users can improve

performance of a stereo system by independently upgrading each module

(Langlois and Robertson 1992).

The PC is also a relatively modularized product. Each product function is

mostly exclusively allocated: a short-term memory function is allocated toRAM; a long-term memory to a hard disk; a data-processing function to the

CPU; an input function to a keyboard; an output function to a monitor,

and so on. As long as designers keep interface rules, they can freely change

module designs without considering other module designs (Clark and

Baldwin 1997). Most of the recent dramatic performance improvement in

the PC comes from technological advancement at the component level, such

as the density improvement of the DRAM, the CPU, and the hard disk. In

other words, a design strategy of modular architecture is a decision to shift

sources of product improvement and design changes into lower levels of

product systems, such as modules and components. Changes of environ-ments are absorbed independently at the module level. Thus, a product with

modular architecture tends to show more design changes at the component

level than at the system level.

The lower-left cell of Figure 2 illustrates integrated architecture, in which

a product’s functions and physical constituents have a complex relationship,

with no simple rules specifying interfaces of constituents (Ulrich 1995). An

automobile has a relatively integrated architecture (Fujimoto 1998). For

example, the upper body of an automobile fulfills various functions, such as

shielding from bad weather, reducing air resistance, maintaining bodystrength, providing insulation from vibration, and so on. However, the

function of reducing noise and vibration is also spread over various other

components, such as the drive-shaft, the engine, the chassis, and so on. In

this way, the relationship between product functions and components, or

subsystems, in automobiles is complex and intertwined. This accounts for a

relatively high interdependence among automobile components. For

example, a change in suspension design will influence the designs for the

braking system, chassis, and body. Because of such high interdependence,

component designs are subject to more restrictions compared to modular



11/24

architecture designs. Since the interfaces between components are not

specified by explicit rules, there are opportunities for improving the

relationships between components. The entire product performance may be

continuously improved by finding better linkages among components.Thus, I conjecture that, compared to products with modular architecture,

products with integrated architecture show more frequent design changes at

the system level and less frequent design changes at the component level. As

an illustration, the average product life cycle of Japanese automobiles is

four years, that of engines and suspensions, which have a more integrated

architecture, often exceeds eight years.

Figure 3 summarizes the above discussions.

The more systemic and context-specific knowledge is, the more effective

are human-based retention mechanisms. Since system knowledge integratesvarious technological elements, such knowledge may be more critical in

design at the higher levels of product systems: more useful in subsystem

designs than in detailed parts designs, more useful in entire product designs

than in subsystem designs.

Although I conjectured that human-based mechanisms are more suitable

for system knowledge in the integration of design activities at higher levels

of product systems, their suitability also depends upon the locus of design

changes determined by product architecture. While a modular architecture

facilitates more frequent design changes at the lower level of product

systems, integrated architecture is expected to show a relatively highfrequency of design changes at the higher level. Thus, the question of

whether human-based mechanisms are suitable for retaining knowledge at

the higher levels of product systems or at the lower levels rests on both the

FIGURE 3

Determinants of Relative Eectiveness of Knowledge Retention Mechanisms



12/24

inherent systemic nature of knowledge and product architecture as a design

strategy.

Empirical Observations from Japanese Automobile DevelopmentProjects

This section conducts a partial examination of the above discussion; it is

‘‘partial’’ because it deals with only with one type of product, an automobile.

Assuming that an automobile has a relatively integrated architecture, I

conjecture that knowledge for integration at the higher levels of a product

system will tend to be retained through a human-based mechanism, whereas

retention of knowledge in designing constituents at the lower levels of theproduct system will tend to rely on standardized mechanisms.

Continuity of Core Project Members. Automobile development projects

involve numerous people with different engineering roles and functional

backgrounds. Different people invariably require different types of knowl-

edge to accomplish their tasks. For example, for project members primarily

responsible for integration and coordination of dispersed functional

activities, system knowledge should be more critical. On the other hand,

specialized and functional knowledge should be more important for people

whose primary task is to design particular component systems, such assuspension systems, braking systems, under-floor panels, and engine

components.

The discussion thus far has implied that transfer of system knowledge will

be associated with direct personnel transfers. I expect to observe that project

members primarily responsible for integration among different functional

and technical areas are more likely to continue in their positions for

successive generations of projects than are those responsible for functional

activities. In the case of automobile development, the following three types

of project members are defined as integrators: project managers, vehiclelayout engineers, and vehicle test engineers.

The role of project managers as system integrators is discussed in other

studies (Clark and Fujimoto 1991; Imai et al. 1985). Although project

managers’ responsibilities vary from project to project, my research on

Japanese automobile companies revealed that all project managers were at

least responsible for concept making, the basic vehicle plan, and coordi-

nation of development processes.

Vehicle layout design is an activity that involves complex adjustments

between conflicting engineering areas. The vehicle layout, basically, is the



13/24

design for how the mechanical components, body structures, luggage, and

passengers will be distributed throughout the vehicle. It involves key

decision making for platform designs, basic component configuration, and

major physical dimensions (e.g., wheel base, tread, hip point). The vehiclelayout determines the basic architecture of an automobile, which expresses

total vehicle concepts in physical terms (Clark and Fujimoto 1991).

Accordingly, vehicle layout significantly influences interfaces among differ-

ent component systems, for example, between suspension systems and

under-floor panels, between engines and engine mount. Therefore, layout

engineers thus require broad-based experience in different engineering areas.

Vehicle test engineers, as opposed to component test engineers, also

engage in extensive coordination activities cutting across different compo-

nent development areas. Since the overall performance of automobiles, asindicated by, for example, NVH (Noise-Vibration-Harshness), safety, body

strength, and driving stability, is derived from many complex interactions

among individual components, a vehicle test engineer has to interact with

related component engineers to achieve targeted performance levels.

This leads to the following hypothesis:

Hypothesis 1: The probability that project managers, vehicle layout engineers,

and vehicle test engineers are transferred from the previous generation of the

project is higher than that for the other project members.

Methods. To test this hypothesis, we obtained data on project members’

experiences in the previous generation of projects by a questionnaire survey.

The sample contains 223 project members representing 25 new product

development projects at seven Japanese automobile producers. The survey

was conducted between 1987 and 1995. A questionnaire was distributed to

the following 10 project members for each project, who represented their

own activity areas for that project. These members will hereafter be referred

to as ‘‘project core members.’’

1. Project manager.

2. Representative of vehicle layout designers/planners.

3. Representative of vehicle test engineers.

4. Representative of chassis design engineers.

5. Representative of body design engineers.

6. Representative of exterior/interior designers.

7. Representative of engine design engineers.

8. Representative of electronics component design engineers.



14/24

9. Representative of production engineers.

10. Representative of marketing/product planners.

All 10 responses were obtained from 17 projects, but there is some

missing data for the remaining eight projects. As a result, the sample

comprises 229 core members. Out of these, 223 responses included usable

answers with respect to experience in the previous projects.

I identified whether respondents had experience in the previous project by

asking them to list the names of past new product development projects on

which they had spent more than an average of 30 percent of their time for at

least six months. When the name of the direct predecessor model was on this

list, that respondent was treated as a project member in the previous

generation of projects. Respondents were not counted, even if they had

participated in the previous model development, unless they had devotedmore than 30 percent of their time for at least six months.5

Table 1 shows the number and the percentage of project core members

transferred from the previous project by each category of person.

Out of the 223 respondents, 83 project core members had experience in

the previous generation of projects. Out of 10 different types of core

members, layout engineers were more likely to be transferred from previous

projects (15 out of 20 layout engineers), followed by project managers (12

out of 24),6 and vehicle test engineers (11 out of 22). Being a layout

engineer, vehicle test engineer, or a project manager, as opposed to the otherfunctional engineers, makes a significant difference as to whether one will be

transferred from the previous generation of projects. This appears to

support my hypothesis that integrators are more likely to be in charge of the

same model development in successive generations.

To examine the validity of the above finding more precisely, a logistic

regression analysis was conducted. Three explanatory variables were

considered as predictors for whether project core members had experience

in previous project generations:

5This way of defining project members needs to be treated with care. Since some components, such as

electronics components, are often designed for multiple projects, engineers might not spend more than 30

percent of their time even on their principal project. We therefore considered these people as not having

worked for the preceding project unless they explicitly indicated otherwise in the questionnaire.6Some may wonder that only half the project managers are retained from previous projects despite

the importance of accumulated project management experience. One reason may be that a project

manager tends to be promoted to a higher position, especially when his project turns out to be successful.

Also, companies that do not have enough competent project managers rotate them to other key product

development projects. Additionally, if a product needs a significant change in terms of a market concept,

retaining system knowledge may have a negative impact on project performance. Aoshima (1997) reports

this effect.



15/24

• System Integrator: A dummy variable indicating system integrators

(1 if respondents are project managers, vehicle layout engineers, or

vehicle test engineers; 0 otherwise).

• Task Newness: Percent of design change from the previous model.Available Project: The number of available projects at the time of the

start of the focal project.

Ten project core members were divided into two categories: System

Integrators or functional engineers. As already defined, System Integrators

include project managers, vehicle test engineers, and vehicle layout

engineers. System Integrator was set equal to 1 if respondents were system

integrators, and 0 otherwise.

In addition to system integrator, two control variables were included. The

first control variable is a percentage of new design, Task Newness, whichindicates the degree of change in engineering tasks from the previous

project. The previous project members might be assigned to the current

project because the required engineering work is similar between two

successive projects. For example, it could be expected that project members

will continue in successive generations if the current project activity involves

only minor modification of the previous design.

Project managers assessed the degree of novelty of the design for their

new products. Answers encompassed 10 different component systems,

including exterior/upper body, interior/trim, steering, floor panels, braking

TABLE 1

Transfer of Project Members from Previous Generation of Project

Project members in the previous

generation of project?

Yes No Total

Project managers** 12 (50.0%) 12 (50.0%) 24

Layout engineers**** 15 (75.0%) 5 (25.0%) 20

Vehicle test engineers** 11 (50.0%) 11 (50.0%) 22

Exterior/interior designers 5 (20.8%) 19 (79.2%) 24

Chassis engineers 4 (17.4%) 19 (82.6%) 23

Body engineers 10 (43.5%) 13 (56.5%) 23

Engine design engineers 9 (37.5%) 15 (62.5%) 24

Electronics component engineers 4 (19.0%) 17 (81.0%) 21

Production engineers 9 (47.4%) 10 (52.6%) 19Marketing/product planners 4 (17.4%) 19 (82.6%) 23

Total 83 (37.2%) 140 (62.8%) 223

Asterisks indicate results of the chi-square tests of independence between being each of three integrators, as opposed tothe other functional/component engineers, and being the previous project members (** p < 0:05, *** p


16/24

systems, suspension systems, transmissions, engine, engine control, and

instrument panels. Newness of each design was measured on a four-point

scale: 1 ¼ minor modification of less than 20 percent of the existing design,

2 ¼ major modification involving 20–80 percent of the new design, 3 ¼ newdesign involving more than 80 percent of the new design, and 4 ¼ entirelynew technology not applied to any model before. This scale was conceived

to capture the theoretical distinction between component system designs

that are purely ‘‘carry-over,’’ involved substantial redesign, or were entirely

new designs.

The novelty involved in activities of component engineers was calculated

by averaging newness of appropriate component designs in terms of the

number of new parts involved. We measured newness of System Integrator

activities by the newness of the platform design as indicated by newness of suspension systems and under-floor panels (Nobeoka 1993). The extent of

novelty in the design activities of production engineers was measured by the

percentage of new production equipment. Marketing/product planners were

excluded from the analysis since indicators could not be obtained for their

Task Newness that were comparable to those for the other core members.

As a result, values of Task Newness were assigned to 192 project members.

The second control variable, Available Project, is the number of available

projects at the time of the current project’s start. It is expected that the greater

the number of simultaneous ongoing projects in a company, the lower the

probability of project members being transferred within the same model line.Tables 2 to 4 summarize descriptive statistics of the dependent variable,

the explanatory variables, and two control variables.

Results. Table 5 shows the results of a fitted logistic regression analysis.

Model II in Table 5 involves only control variables. It shows that the

number of available projects has a negative effect on the transfer of core

project members, as expected. However, Task Newness does not have a

significant relationship with transfer of project members, although it does

have the expected sign for the coefficient.Model III, in the third row of Table 5, involves System Integrator as a

predictor. The parameter estimate of System Integrator is 1.10, which

TABLE 2

Descriptive Statistics for Experience with Previous Project Generation

Frequency

Cumulative

frequency

Cumulative

percent

0 ¼ not members of previous generation of project 107 107 58.5%1 ¼ members of the previous generation of projects 76 183 100.0%



17/24

indicates a positive relationship between System Integrator and previous

experience, as expected. The chi-square goodness of fit statistic was reduced

for 10.98 from Model II ð p


18/24

more retention of such knowledge will benefit from the use of standardized

mechanisms, such as documentation, standardization, and computerized

systems. This implies that component engineers may use documents,

reports, design standards, and computerized media to retain past knowledgemore frequently than do integrators, leading to the following hypothesis.

Hypothesis 2: Component engineers refer to documents and reports, and use

design standards and standard design procedures, more frequently than do

integrators.

To partially examine this, engineers were asked to rate, on a five-point

Likert scale (from 1 ¼ not refer at all to 5 ¼ refer very frequently), thefrequency with which they referred to documents and reports that described

design know-how and design solutions and problems identified in the pastdevelopment activities. Similarly, respondents rated how important were the

roles design standards and standard design procedures played in their

project activities, on a five-point Likert scale, from 1 ¼ not important at all to 5 ¼ played a very important role.

Based on these ratings, a series of OLS regression analyses was

conducted. Dummy variables were introduced into the analyses, each of

which indicates a particular type of engineer. The dummies were effect

coded so that the coefficients are deviations from the overall mean. In

addition, two control variables were taken into consideration: tenure of

project members and task newness. Tenure indicates the length of thesubject’s service in the current company. We used the same measure for task

newness as used in the previous section.

Next, individual dummies were substituted for a single dummy indicating

integrators versus component engineers to explore the effect of being

integrator. Integrators include layout engineers and test engineers.7 Table 6

shows summary statistics of some of these variables.

Table 7 shows the results. This table shows that layout engineers tend to

rate significantly lower the frequency of reference to documents and reports

in their development activities. Engine and body engineers reported morefrequent references to documents and reports for the purpose of learning

from the past design activities.

As for importance of design standards and standard design procedures,

layout engineers also rated these significantly lower. Combined with the

above result, this seems to suggest that knowledge regarding vehicle layout

design is less likely to be transferred through documentation and

7Project managers were excluded from this analysis because there are no standards available for

project managers that are equivalent to design standards or test codes.



19/24

standardization. Considering the findings of the previous sections that

layout engineers tend to continue their positions in successive generations of

projects, it appears that knowledge to design the total vehicle layout may be

less codifiable and its retention may tend to depend on personal experience.For example, one engineer responsible for vehicle layout design in the four

successive Familia (323) projects at Mazda, explained why it is important

for layout engineers to continue their positions in successive generations:

Since ‘‘Kikaku-sekkei’’ [basic design, which means the layout design in Mazda] is

related to the all engineering areas, it’s important to gain broad experiences [within

the same product line] to be able to capture a whole [complex relationships between

different engineering domains]. . . . Thus layout engineers tend to stay in the same

product line for long time.8

However, contrary to the second hypothesis, Table 7 shows that both

documentation and standardization seem to be important means of

capturing prior practices in vehicle test engineering. In particular, test

engineers rated significantly higher the importance of standards (in their

case, standards means test codes).

This may be partially because documents and reports have particular

meaning or usefulness to test engineers. While drawings are the primary

outputs for design engineers, testing reports are the primary outputs for test

engineers. Test engineers summarize test results in various forms of reports,

which they distribute to related engineering and design departments.

Knowledge related to testing activities, such as that about target perfor-mance setting, design, and production prototype evaluation, are thought to

be transferred through documentation. For example, Cusumano and Selby

(1995) report that software testers at Microsoft rely heavily on various types

of checklists and scripts.

The result also suggests that existing testing methods and established test

codes become a critical basis for testing new vehicles. Compared to design

work, testing work may require more consistency and thoroughness than

TABLE 6

Descriptive Statistics of Variables

N ¼ Mean SD Min. Max.

Frequency of reference to documents and reports 167 3.78 0.95 1.00 5.00

Importance of standards (design standards and

test codes)

165 4.06 0.94 1.00 5.00

Tenure 167 17.82 7.38 4.00 42.00

Task newness 167 0.55 0.28 0.05 1.00

8Interview with Mr. Morioka, Mazda Motor Corp., May 19, 1994.



20/24

creativity. Thus, standards and documents may become important.

Although it was assumed that vehicle test engineering involves complex

integrative efforts across many different component systems development,

the testing function itself may be a well-established discipline.

Because of test engineers’ reliance on standardized mechanisms, Columns 2and 4 in Table 7 show no significant difference between system integrators and

component engineers in terms of use of documents and standards. The second

hypothesis is not supported. Although the findings for layout engineers are

consistent to with the hypothesis, from the above analysis, this cannot be

attributed to the fact that they are system integrators. The tasks of test

engineers may have distinctive characteristics that call for the extensive use of

documents and standards, which might obscure the effect of being system

integrators. However, this cannot be confirmed from the available data.

Summary

The main objective of this article was to explore effective ways of

retaining knowledge involved in new product development. I discussed the

idea that retention of knowledge about the interactions among fragmented

functional domains may demand direct transfer of individual experience

bases, but that standardized mechanisms may be more beneficial for

retaining specialized and functional knowledge. This further implied that

TABLE 7

Regression Analyses for the Use of Documents and the Importance of

Standards

Frequency of reference

to documents and reports

Importance of standards

(design standards and test code)

Tenure 0:01 0.04 0:07 0:00Task newness 0:11 0:12 0:11 0:16**Chassis engineer 0:05 0:04

Body engineer 0.16* 0.08

Engine engineer 0.19 0.04

Electronics comp. engineer 0.04 0.05

Manufacturing engineer 0.11 0.19*

Layout engineer 0:23** 0:27***Test engineer 0.11 0.17*

System integrators 0:08 0:17df of residuals 157 163 155 161

Adjusted R2 0.05* 0.02 0.07* 0.01

* p < 0:1.** p < 0:05.*** p


21/24

although human-based mechanisms more effectively convey knowledge

required in design integration at the higher levels of product systems,

standardized mechanisms are appropriate for retention of lower-component

knowledge. However, it was also argued that product architecture affectsthese relationships through its impact on a locus of design change in a

product system. Modular architecture, for example, focuses design change

at the module and component levels. The resulting high frequency of design

changes at module and component levels may make human-based mech-

anisms of retaining component knowledge more suitable than archival-

based mechanisms despite its less systemic nature.

Two empirical analyses of data obtained from Japanese automobile

development projects were conducted to test these ideas. In these analyses,

first, it was found that project members responsible for integration activitiescutting across different functional domains tend to continue in their positions

for successive generations of projects. This implies that knowledge for

integration may tend to be associated with the transfer of people. On the other

hand, component engineers were less likely to be responsible for successive

generations of the same product. Second, it was found that layout engineers

tend to rely less on documents, reports, and standards to learn from past

design practices than do component engineers. These results may imply that

standardized mechanisms alone are not enough to retain knowledge

regarding interaction and integration among different design domains.

Limitations and Further Research

Limitations of this study are mostly due to considering only one industry

in one country. Because of this, the empirical part of this article has weak

connections to the theoretical discussions.

First, this study dealt with the automobile that, it is assumed, has integrated

product architecture, I did not examine knowledge retention practices in the

development of modularized products. There could be quite different results

in development projects of modularized products. For example, in the case of

PC development, there may be more dependence on human-based retention

mechanisms in the development of components such as hard disks, monitors,

CPUs and other semiconductor devices, and less on integration of those

components into final goods. Investigation of products that have been rapidly

modularized recently, such as the bicycle, may provide important additional

insights into the management of knowledge retention processes.

Focusing only on the automobile industry made it impossible to examine

the effect of the frequency of design change on retention mechanisms. The



22/24

theoretical discussions in this article suggest that industries facing higher

rates of design changes tend to rely more on human-based retention

mechanisms than on standardized mechanisms. To examine this, this study

needs to be extended to include a variety of industries in terms of speed of change, ranging from a rapidly growing industry to a mature one.

Second, this article focused on the benefit side of retention mechanisms.

However, there is a cost in using them, which may differ across different

institutional settings. For example, the cost of retaining a specific individual

across multiple generations of projects may be very high in countries that

have high labor mobility. Since this study includes only a Japanese sample,

such institutional influences could not be examined.

In our sample, only one project member out of 223 had working

experience in other automobile companies: almost all members had workedfor only one company. Further examination is needed to determine whether

this low mobility is common in Japan or specific to the Japanese auto

industry. The low labor mobility in our sample probably reduces the cost of

retaining a project member, which may generate some biases in favor of

human-based retention mechanisms. On the other hand, where labor

mobility is quite high, companies cannot help depending on standardized

mechanisms to retain knowledge even if it is systemic. Although the cost of

articulating system knowledge may be high, retaining people may be even

more costly. In that case, companies either invest in standardized retention

mechanisms or modularize and standardize a product itself to decrease theneed for context-specific system knowledge.

The third limitation is lack of project level analyses. If our interest resides

in performance of new product development, knowledge retention at the

project level needs to be considered. In particular, since system knowledge

can be stored in multiple people, knowledge retrieval may be triggered when

members with common experiences get together. Such a group-level

phenomenon was not considered in this paper.9 Once data is analyzed at

the project level, we can examine, for example, a relationship between the

generation linkage and the cross-functional integration that is been knownto exist in Japanese companies.10

9On project-level phenomenon, see Aoshima (1997).10By examining the same database at the project level, Aoshima (1996) examines the relationship

between the cross-functional integration and the cross-generation linkage, and finds a high correlation

between two. There, the cross-generation linkage is measured by the percentage of core project members

having experiences in the previous generation of projects, and the degree of common past project

experience among members. From this result it can be implied that the cross-generation linkage may be a

foundation for the cross-functional integration.



23/24

To overcome the above limitations, future research should make

comparisons across different industries in different countries, dealing with

data at the project level.

References

Aoshima, Y. 1996. ‘‘Knowledge Transfer Across Generations: The Impact on Product Development

Performance in the Automobile Industry.’’ Ph.D. dissertation. MIT.

———. 1997. Knowledge Retention: The Impact on New Product Development Performance. Working

Paper #97-08. Institute of Business Research, Hitotsubashi University.

Allen, T., and D. G. Marquis. 1964. ‘‘Positive and Negative Biasing Sets: The Effects of Prior Experience

on Research Performance.’’ IEEE Transaction on Engineering Management 11:158–62.

Anderson, P., and M. Tushman. 1990. ‘‘Technological Discontinuities and Dominant Designs: A

Cyclical Model of Economic Change.’’ Administrative Science Quarterly 35(4):604–633.Badaracco, J. L. 1991. The Knowledge Link: How Firms Compete Through Strategic Alliances . Boston,

MA: HBS Press.

Christensen, C. M., and R. S. Rosenbloom. 1995. ‘‘Explaining the Attacker’s Advantage: Technological

Paradigms, Organizational Dynamics, and the Value Network.’’ Research Policy 24:223–57.

Clark, K. B., and C. Y. Baldwin. 1997. ‘‘Managing in an Age of Modularity.’’ Harvard Business Review

September–October: 84–93.

——— and T. Fujimoto. 1991. Product Development Performance: Strategy, Organization, and Man-

agement in the World Auto Industry. Boston, MA: Harvard Business School Press.

Cusumano, M. A. 1991. Japan’s Software Factories: A Challenge to U.S. Management. New York:

Oxford University Press.

——— and K. Nobeoka. 1998. Thinking Beyond Lean. New York: Free Press.

——— and R. W. Selby. 1995. Microsoft Secret: How the World Most Powerful Software Company

Create Technology, Shapes Markets, and Manage People. New York: Free Press.

Dougherty, D. 1992. ‘‘Interpretive Barriers to Successful Product Innovation in Large Firm.’’ Organi-

zation Science 3(2):179–202.

Fujimoto, T. 1998. ‘‘Japanese Automobile Product Development in 1990s—Capability-Building Com-

petition by Front-Loading (in Japanese).’’ Business Review 46(1):22–45.

Garud, R., and P. R. Nayyar. 1994. ‘‘Transformative Capacity: Continual Structuring by Intertemporal

Technology Transfer.’’ Strategic Management Journal 15:365–85.

Henderson, R. M., and K. B. Clark. 1990. ‘‘Architectural Innovation: The Reconfiguration of Existing

Product Technologies and the Failure of Established Firms.’’ Administrative Science Quarterly

35:9–30.

Huber, G. P. 1990. ‘‘Organizational Learning: The Contributing Processes and the Literatures.’’

Organizational Science 2(1):88–111.

Huber, G. P. 1991. ‘‘Organizational Learning: The Contributing Processes and The Literatures.’’

Organizational Science 2(1):88–111.

Imai, K., I. Nonaka and H. Takeuchi. 1995. Managing the New Product Development Process: How

Japanese Learn and Unlearn. In K. B. Clark, R. H. Hayes and C. Lorenz, (Eds.). The Uneasy

Alliance: Managing the Productivity-Technology Dilemma. Boston, MA: Harvard University

Press.

Iansiti, M. 1997. Technological Integration: Making Critical Choices in a Turbulent World. Boston,

MA: Harvard Business School Press.

Iansiti, M. 1998. Technology Integration. Boston, MA: HBS Press.

——— and K. B. Clark. 1994. ‘‘Integration and Dynamic Capability: Evidence from Product

Development in Automobiles and Mainframe Computers.’’ Industrial and Corporate Change

3(3):557–605.



24/24

Krippendorf, K. 1975. ‘‘Some Principle of Information Storage and Retrieval in Society.’’ General

Systems:15–35.

Langlois, R. N., and P. L. Robertson. 1992. ‘‘Networks and Innovation in a Modular System: Lessons

from the Microcomputer and Stereo Component Industries.’’ Research Policy 21:297–313.

Leonard-Barton, D. 1992. ‘‘Core Capabilities and Core Rigidities: A Paradox in Managing New ProductDevelopment.’’ Strategic Management Journal 13(Summer):111–26.

Meyer, M. H., and J. M. Utterback. 1993. ‘‘The Product Family and the Dynamics of Core Growth.’’

Sloan Management Review 29(4):29–47.

Nakayama, T. 1997. ‘‘The Keisho of Development Technology: The Case of the Japanese Aircraft

Industry.’’ Journal of Product Innovation Management 14(5):393–405.

Nystrom, P. C., and W. H. Starbuck. 1984. ‘‘To Avoid Organizational Crises, Unlearn.’’ Organizational

Dynamics 12:53–65.

Polanyi, M. 1966. The Tacit Dimension. Gloucester, MA: Peter Smith.

Ulrich, K. 1995. ‘‘The Role of Product Architecture in the Manufacturing Firm.’’ Research Policy

24:419–40.

——— and S. Eppinger. 1994. Product Design and Development. New York: McGraw-Hill.

Uzumeri, M., and S. Sanderson. 1995. ‘‘A Framework for Model and Product Family Competition.’’Research Policy 24:583–607.

von Hippel, E. 1994. ‘‘‘‘Sticky Information’’ and the Locus of Problem Solving: Implications for

Innovation.’’ Management Science 40(4):429–39.

——— and M. J. Tyre. 1995. ‘‘How Learning by Doing is Done: Problem Identification in Novel Process

Equipment.’’ Research Policy 24:1–12.

Walsh, J. P., and G. R. Ungson. 1991. ‘‘Organizational Memory.’’ Academy of Management Review

16(1):57–91.

Wilson, T. L., and J. D. Hlavacek. 1984. ‘‘Don’t Let Good Idea Sit on the Shelf.’’ Research Management

27(3):27–34.

Zander, U., and B. Kogut. 1995. ‘‘Knowledge and the Speed of the Transfer and Imitation of Orga-

nizational Capabilities: An Empirical Test.’’ Organization Science 6(1):76–92.
