IJEE1367

7/27/2019 IJEE1367

1/11

Facilitating Product DevelopmentKnowledge Acquisition: Interaction

between the Expert and the Team*

O ZGU R ERIS and LARRY LEIFER

Center For Design Research, Stanford University, Stanford, CA 93409, USA. E-mail: [email protected]

Product development knowledge cannot be embodied in a specific individual, a specific group ofindividuals, or a formal process. Those elements can only embody aspects of product developmentknowledge. Interaction of those elements is what assigns meaning to the aspects of knowledge andallows for their synthesis. Therefore, it can be said that product development knowledge emergesout of the combined interaction of the involved people and resources.

INTRODUCTION

BOTH IN RESEARCH and in industry, it iswidely assumed that product development expertspossess knowledge that can be transferred toproduct development teams. However, the speci-fics of what and how teams can learn from expertsare unclear. In order to document what actuallytakes place when product development experts arebrought together with product development teams,expert-team interactions at the vehicle develop-ment center of a US automobile producer werestudied. The goal was to gain a comprehensive

understanding of the content, motives and struc-ture of the interaction, and then to construct aproduct development knowledge acquisitionmodel based on the findings. Such a modelwould be grounded in practice and can be usedto assess the validity of the assumptions regard-ing knowledge transfer between experts andteams.

One way of reaching the desired understandingwas to consider the demands of the interaction onthe experts, and the strategies they employed tomeet those demands: what exactly were the expertsresponsible for, and how did they meet those

responsibilities? More importantly, how did thedifferent groups involved in the interactionexperts, teams, organization and researcherview those responsibilities? In this paper, aconceptual framework for analyzing the simila-rities and differences between the viewpoints isdeveloped in order to answer those questions.Data is presented in the form of several keyobservations and select transcripts from struc-tured interviews. Based on the findings, acomprehensive product development knowledgeacquisition model is constructed.

Four conclusions were drawn:

1. Formalized tasks and procedures embodied in aproduct development process need to beinterpreted and contextualized for productdevelopment teams.

2. Product development experts can be effective inaccomplishing that contextualization.

3. There are two prerequisites for effective expert-team interaction: experts need to be accepted atleast as welcomed outsidersif not as tempor-ary membersto the teams, and the mechan-isms experts utilize to facilitate the knowledge

acquisition of teams must be meaningful forexperts.4. Knowledge acquisition metrics should be devel-

oped before product development processesand experts are deployed so that their impacton product development practice can beassessed accurately.

The findings also indicate that product develop-ment knowledge cannot be embodied in a specificindividual, a specific group of individuals, or aformal process. Those elements can only embodyaspects of product development knowledge. Inter-action of those elements is what assigns meaning

to the aspects of knowledge and allows for theirsynthesis; product development knowledgeemerges out of the combined interaction of theinvolved people and resources.

ON THE ASSOCIATION BETWEEN APRODUCT AND A PROCESS

Prior to discussing the specifics of expert-teaminteractions at the large US auto producer(referred to as Giant for confidentiality), it isnecessary to communicate the context in whichthe interactions occurred. The main motivation for

deploying product development experts (PDEs)within vehicle program teams (VPTs) was to* Accepted 2 September 2002.

142

Int. J. Engng Ed. Vol. 19, No. 1, pp. 142152, 2003 0949-149X/91 $3.00+0.00Printed in Great Britain. # 2003 TEMPUS Publications.

7/27/2019 IJEE1367

2/11

facilitate the learning of a new product develop-ment process (GPDP) by the teams. Therefore, it isappropriate to briefly comment on the relationshipbetween products and product developmentprocesses.

Product development enterprises inevitablymetamorphose into product development opera-

tions when the organization developing theproducts, as well the market for the products,grows and the scale of the activity increases.At the enterprise level, the activity is relativelychaotic, thriving on ambiguity and limited struc-ture. Increasing the scale of the activity necessi-tates an increase in consistency and control, andhence, a higher degree of structure. The enter-prise transforms into an operation, and opera-tions run according to processes; productsbecome inseparably associated with processes.

Acting on that premise, what is of interest to thisstudy is how the link between the product and theprocess can be maintained through the utilizationof a process expert. How is the knowledge thatpresumably resides in a process transferred to, orrather, learned by the people who develop aproduct associated with that process? More speci-fically, can experts, who have extensive under-standing of a process, indeed facilitate theacquisition of the process knowledge by productdevelopers?

Much has been published regarding productdevelopment processes from an engineeringperspective [13]. However, the published materi-als tend to be prescriptivethe authors areconcerned with advocating specific processes they

have developed, and not with how productdevelopment processes evolve and are utilized inpractice.

The essential starting point for studying howsuch processes evolve and are utilized in practice isto realize thatas Bucciarelli and Brereton havepointed outsocial interaction shapes the processas well as the product [4, 5]. According to Bucciar-elli, the intersection of the individual perspectivesof the participants of the product developmentactivity is the determining factor for the processthat is being used as well as the resulting artifact.An implication of that argument is that identifyingthe participants, and their perspectives, of the

expert facilitated learning of a product develop-ment process would be revealing. This studyadopts that approach in forming an analysisframework.

Another prominent view in the field regardingexpert-team interactions is to treat experts asintermediaries of a knowledge transaction.Creighton, Jolly and Essoglou have argued thatexperts act as `linkers' who form the basis of atransfer mechanism that exists between the sourceof a body of knowledge (in this case, a productdevelopment process) and the utilizer of the know-ledge (product development teams) [68]. They call

the resulting one-way knowledge transfer model,the `linker model'. However, the underlying

assumptions of the linker model are not wellgrounded, and therefore, are problematic; suchmodels assume the pre-existence of a formulatedand transferable thing as knowledge. Thoseassumptions will be critiqued in detail in theAnalytical Framework section of this paper.

A more appropriate model is one that Hargadon

suggests regarding what he terms `knowledgebrokering' [9, 10]. According to Hargadon, know-ledge brokers are free agentsindividuals withinan organization, or organizations within indus-trywho establish links between different anddisassociated domains of practice and knowledge.They accomplish that by gaining access to themultiple domains, learning the characteristicproblems and solutions of each domain, and link-ing the `old problems with new solutions and newproblems with old solutions by sharing their know-ledge within the organization.' In other words,they `cross-pollinate'. Hargadon's argument ishighly relevant to this study since process expertscan be viewed as the brokers of product develop-ment knowledge. Studying the interactionsbetween experts and teams is crucial to under-standing how product development knowledge isbrokered. However, Hargadon does not elaborateon what is being brokereddefining knowledge interms of `problems and solutions' is not satisfac-tory. This paper will also address that issuedirectly, and attempt to formulate an understand-ing of what constitutes product developmentknowledge.

RESEARCH SETTING

Before introducing the analytical framework, itis necessary to outline the history and goals ofGPDP and the PDE function, and the organ-ization of product development teams at Giant.

Giant Product Development Process (GPDP)The Giant Product Development Process is

taken to be the main focus, or rather, content, ofthe expert-team interaction by the organization. Itslearning and application by teams was the mainreason for creating the PDE function; PDEs wereintroduced to the organization as `process

experts' in order to facilitate the deployment andapplication of it.

GPDP is not innovative in the sense that itembodies groundbreaking product developmentprinciples that are new to Giant. On the contrary,it is mostly based on practices that are already inuse. However, it is innovative in the sense that itrestructures and optimizes the ongoing practicesand presents them in a highly methodicalform. Therefore, GPDP, as well as the PDEfunction, can be seen is as inherent componentsof a restructuring effort.

In the mid-nineties, Giant decided to formalize

its product development process. That entailedunderstanding the way it has been developing

Facilitating Product Development Knowledge Acquisition 143

7/27/2019 IJEE1367

3/11

products, documenting that understanding, andoptimizing the resulting picture with respect tocost and development cycles time. In order toattain the required understanding, over onehundred managers and technical directors weretaken away from their jobs for a month, andwere asked to articulate how their groups

were getting their jobs done. The reports weresynthesized, and the overall structure emerged.

A core process group was formed to populatethe structure with any missing details. The processgroup members had extensive technical andmanagement experience with product developmentat Giant. They worked for over a year, andproduced a process that reflected the existingpractices at Gianta formalization of what wasmostly tacit. They improved that structure byremoving redundancies, setting more meaningfuland functional timelines and deliverables, andcoordinating better ways of using resources.

The most pronounced characteristic of theprocess is its comprehensive scope. Currently,all vehicles being developed at Giantdomesti-cally or internationallyare developed using thesame process, and when the sheer size of theorganization is taken into account, the impli-cations of such a standardized approach aresignificant.

Product Development Experts (PDE)The need for product development experts was

identified during the test application of the processwhen pilot teams experienced difficulties in under-

standing and applying its principals, and requiredguidance. It was clear that GPDP would notsimply diffuse throughout the organization fromthe core group, and that a more deliberate efforthad to be made to train the teams in what it wasand how to apply it. Since members of the coregroup had exclusive knowledge of it at the time,they were the only people who were qualified to actas consultants to the pilot teams. A few of themstarted doing so, and over time, their interactionwith teams proved to be crucial.

The initial confusion experienced by the teamsover process issues and the success of the tempor-ary solution of utilizing core group members asconsultants led to the forming of an official PDEfunction. A PDE group, working closely with

other process resource groups and teams wasformed.

The role requires the experts to have compre-hensive knowledge of product development as it ispracticed at Giant. Therefore, all of them arerecruited from the ranks of experienced employeeswho have been involved in multiple aspects of

product development at Giant as engineers andmanagers for a minimum of ten years. Four out ofthe five experts who were subjects in this study hadengineering backgrounds and advanced degrees inmanagement. Most of them had been working atGiant for over 20 years, and they all have held atleast five different positions.

Vehicle Program Team (VPT)The vehicle program teams at Giant are plat-

form specificthe people who make up a teamhave the development of a specific vehicle as theircore task. Naturally, teams vary in size and scopeas the vehicle program progresses, however, a chiefprogram engineer, a program manager and theirstaff are permanent members. It is their responsi-bility to make sure the team has the necessaryhuman and material resources for the program toprogress. Typically, an expert is assigned to a teamat the start of the program, and remains with itduring at least the initial third of the vehicledevelopment cycle. Depending on the needs ofthe team, an expert can be supporting one tofour teams at any given time.

ANALYTICAL FRAMEWORK

The product development knowledge learningthat took place between experts and teams atGiant can be modeled at different levels. Similarto Creighton, Jolly and Essoglou's `linker model'[68], a traditional approach would have been toassume that PDEs, the product developmentexperts, were the transfer mechanism for productdevelopment knowledge, GPDP, and VPTs, theproduct developers, acquired it via one-waytransfer (Fig. 1).

However, we identified two significant problemswith that approach. The first one was that, basedon preliminary observations, the process did notseem to be a thing that could be passed from onegroup to another. Even though it could be thought

Fig. 1. A traditional product development knowledge acquisition model based on one-way transfer.

O. Eris and L. Leifer144

7/27/2019 IJEE1367

4/11

to be formally documented in flow charts, resourceallocation tables, and task and deliverable defini-tions, its essence seemed to be the tacit definitionof a processa common informal understandingof a way of doing the things that were necessary todevelop a vehicle. Its meaning depended on theinteractions of the involved people. Therefore, to

assume that process knowledge was being trans-ferred from one party to another during theinteraction was too simplistic, and a more com-prehensive understanding accounting for the infor-mal as well as the formal aspects of knowledgeacquisition was necessary.

The second problem was that even though theorganization assumed the main content of theinteraction to be the process, preliminary observa-tions suggested otherwise. Judging from theirprofessional backgrounds, experts possessed more`product development' experience than `process'experience. More importantly, they seemed tovalue their product development experience overtheir process experience, and acted in the light ofthat judgement when interacting with the teams.Therefore, it would be more appropriate to callthem product development experts rather thanprocess experts, and that distinction has implica-tions for the product development knowledgeacquisition model.

In order to develop a more comprehensivemodel, it was necessary to understand moreabout the expert-team interaction. Focusing onexperts was a good starting point. Even thoughthere were many GPDP learning mechanismsavailable to teams such as classes and World

Wide Web resources, experts were essentialcomponents in virtually all process learning thattook place within teams by assuming an unusuallydiverse range of roles.

This finding led us to attempt to define theresponsibilities of experts. By determining thenature and boundaries of their responsibilities,we aimed to identify the demands of expert/team interactions on experts. However, thatproved to be challenging. The main difficultywith defining the responsibilities of experts wasprecisely what deemed them interesting in thefirst place: they got involved in a variety ofsituations and worked with many team members.

That meant that different people at the Giantproduct development center had different percep-tions of what experts did, and that there was noone representative view. We saw this as anopportunity, and decided to assess the expert/team interactions by studying the perceptions ofthe involved parties.

There were four groups with unique viewpointson expert/team interactions (Fig. 2). The mostvaluable one was, naturally, the viewpoint ofexpertsthey knew the most about what theyneeded to do and how they did it. However, theirperceptions alone could not be taken to be descrip-

tive of their function; the viewpoints of the organ-ization and teams needed to be considered as well.

(We assumed the perspective of the organization tomanifest itself in its policies and structuresprocess-specific and generalincluding GPDPand PDE role-related documentation, and organ-izational structures, resources and values.) Andfinally, the researcher's perspective was consideredto be unique and valid as well. It was the only

external basis for reflection, and there was noreason to treat the researcher as an objective andnon-intrusive narrator.

Our assumption was that documenting andstudying the perceptions of these four groupswould not only reveal the dynamics of the inter-action, but also the mechanisms that enable, orhinder, PD knowledge acquisition. Similaritiesamong the viewpoints might highlight the mutualunderstandings and unifying elements among thegroups, and point at the drives, enablers, andaffordances of knowledge acquisition. On theother hand, we assumed that the differencesamong the viewpoints might highlight unsharedunderstandings and contradictions, and point athindrances and conflicts.

RESEARCH METHODOLOGY

Three site visits totaling fifteen days over aperiod of nine months were made. Two methodsof data collection were used during the study. Thefirst method relied on ethnography, where theresearcher shadowed seven different experts.Observations were documented in the form offield notes and audiotape of meetings and informal

interviews. The qualitative insights gained from theinitial site visit enabled the development of theanalytical framework presented in the previoussection.

The other method relied on structured inter-views with experts and team members in order togather the data to be analyzed in light of thatframework. The interviews were specifically geared

Fig. 2. There were four groups with unique viewpoints onexpert-team interactions. Their viewpoints were analyzed in

order to understand the actual motives and content of expert/team interactions.


7/27/2019 IJEE1367

5/11

to expose their perspectives on their interactions.Experts were asked a variety of questions regard-ing their background, work habits, methods, andjob interactions, relationship to the process,conceptions of themselves as experts, and concep-tions of the PDE job function. Team memberswere asked questions regarding their interactions

with experts, conceptions of the PDE job function,and expert utilization.

The four perspectives and a grounded modelThe field notes and structured interview tran-

scripts were analyzed with the above framework inmind. The findings will be presented in twosections. In the first section, the similarities anddifferences between the viewpoints will be identi-fied. In the second section, those findings will beintegrated with higher-level observations, and acomprehensive product development knowledgeacquisition model will be constructed.

DISCUSSION OF THE FOURPERSPECTIVES

In order to compare the perspectives, eachgroup's views on the responsibilities of experts

were captured, documented and analyzed. Thatentailed transcribing the interviews held withexperts and team members, collecting the docu-ments created and used by the organizationregarding the PDE function, documenting theresearcher's field notes, and analyzing them inrelationship to each other. Table 1 summarizes

the findings, where quotations representative ofthe four groups' views on responsibilities of expertsare presented.

The quotations are thought to be answers to thequestion, `Given the extent of your interactionwith experts, what do you see as their core set ofresponsibilities?' After reviewing all of the answers,and identifying the conceptual areas they fallunder, nine Èxpert responsibility' categories werecreated. Answers that are similar in meaning areplaced in the same Èxpert responsibility' category.If a group has not expressed a specific view on anexpert responsibility, the corresponding cell forthat group is left blank. This allows for a visualrepresentation of the similarities and differencesbetween the viewpoints. For example, the answersin the `Sharing of cross-vehicle program know-ledge' category are thought to be strongly asso-ciatedthe meaning they convey seems to be

Table 1. Views of the four groups on the responsibilities of experts. The quotations are thought to be the answer to the question,`Given the extent of your interaction with experts, what do you see as their core set of responsibilities?' Answers that are similar in

meaning are placed in the same Èxpert responsibility' category.

Expert Responsibility Expert View Team View Organization View Researcher View

Sharing of Cross-vehicleProgram Knowledge

`Reflect Best`Best Practices in

GPDP'

`Bring cross-vehicleprogram experience to

teams'

`Document and sharenew process experience

across teams'

`Broker vehicledevelopment and

process knowledge'Process Reference `Support teams in the

specifics of processdeployment'

Àssist teams in thetiming of events anddeliverables'`Translate process intoreality'

Ànswer programspecific processapplication questions'

`Facilitate theimplementation ofspecific processprocedures'

Process Training `Train teams on processmethods'

Ènsure that the teams'process training needsare met'

`Train or Facilitate thetraining of teammembers on theprocess'

Risk Management `Monitor team progress' Ìnform teams of risksdue to changes in thetiming of events'Àct as policeman'`Keep the team out of

trouble'

Gap Fill ing `Support necessary teamfunctions'

Àct as wildcard teammember'

Process Improvement Ìnitiate Process ChangeControl issues'

`Provide feedback forprocess improvements'

Gaining SocialAcceptance

`Become a welcomedoutsider within teams'

Solution Creation `Develop workaroundswhen processprocedures are notavailable'

Tool Utilization `Coordinate the team'susage of management

tools'


7/27/2019 IJEE1367

6/11

shared among the four groupswhereas theanswer given in the `Solution creation' categoryis emphasized strongly by the organization only,indicating an unshared meaning.

It is very likely that experts and team memberswould have provided more than three to fiveanswers each if they were given more time and

questioned more thoroughly during the interviews.However, our intent was to capture what came totheir mind immediately without having them feelthe need to ponder. And when analyzing thedocumentation and the field notes, our intentwas to highlight the points that were articulatedwell and came across more strongly as opposed tothose mentioned in broad terms.

Sharing of cross-vehicle program knowledgeThe main expert responsibility the groups

expressed similar views on was the sharing ofcross-vehicle program knowledge. All fourgroups perceived experts as interfaces to `cross-vehicle program experience' and knowledge, or as`knowledge brokers' within the institution.

The organization, and the experts themselves,were opportunistic in recognizing this need and inunderstanding how their position within theorganization as process experts, which allowsthem to interact with many program teams simul-taneously, could constitute a basic affordance formeeting it. Even though the rationale for the PDEfunction emerged from the need of creating andsharing process knowledge, its fulfillment extendedmuch beyond that. Because of the organizationalallowances and infrastructure-related resources

that were necessary to meet that need, the goalto facilitate the acquisition of process knowledgeconstituted a gateway for acquiring product devel-opment knowledge in general. The very nature ofthe PDE function declared experts `free-agents'within the organization, and perhaps somewhatunintentionally, created the possibility for productdevelopment knowledge brokering. More interest-ingly, all four groups were aware of that takingplace. Even though they used different terms suchas `sharing of cross-vehicle experiences', `best prac-tices' or `knowledge brokering' to describe it, theywere all referring to and acknowledging the sameinformal learning mechanism.

Process referenceAnother expert responsibility the groups

expressed similar views on was acting as processreference. All groups recognized that the availabil-ity of experts as process references was importantto the application of the process. A team memberexpressed this belief by stating `translating GPDPinto reality' as a key PDE responsibility.

Experts indeed acted like translators, constantlyinterpreting and contextualizing formal processprocedures for teams. Almost all team memberswho were interviewed lacked process understand-

ing thought their teams. The abstract, formal, andperhaps, even cryptic, nature of the documentation

on process tasks and procedures often confusedthem, causing them to question the meaningbehind what they were asked to do. Naturally,team members who lacked prior GPDP experienceencountered more difficulty in understanding itsprocedures, and sought the assistance of expertsfor clarification.

Experts saw themselves as `single point answercenters' who tried to answer questions that cameup in `dynamic situations' by providing `dynamicresponses' so that the teams could go on with theirjobs with minimum disruption. In one-on-onesituations, experts walked team members throughtasks or procedures until a clarification wasreached. In group situationsmainly during theweekly program steering meetings when all keyteam members were presentexperts answeredquestions to clarify process issues.

Process trainingAll groups except teams saw process training as

a significant expert responsibility. Even thoughthere was a separate process training groupwithin the organization whose specialty was toprepare and deliver process training classes,experts were expected to monitor the impact ofthese training programs on teams, and modifiedexisting training schedules when they thoughtteams lacked the necessary understanding.However, their involvement went far beyondthat; they often played a personal role in customiz-ing the classes. In some cases, they took an evenmore active role by instructing or co-instructingtraining sessions.

Risk managementThis responsibility was well articulated and

emphasized by experts and teams, but not by theorganization and the researcher. It is plausible thatthe difference in the level of emphasis resultedfrom the issue being closely tied to practice; theneed to manage risk arises as the programprogresses, and in some cases, it is more effectiveto deal with the need as it comes up rather than toattempt to anticipate and account for it early on.

Teams had already dedicated timing and plan-ning personnel to account for issues that could beanticipated at an earlier stage when there was timeto consult with external resources (includingexperts) and make educated planning decisions.However, when programs were at a moreadvanced stage, they could not always analyzeand predict potential issues because they did notnecessarily possess the required breadth andexperiencenot only in the process but in productdevelopment practice in generalto be able toreact to situations that developed quickly. Expertsdid. Their 20 years of experience in vehicledevelopment allowed them to recognize and drawattention to risks as they were forming. A programmanager put this observation into perspective by

saying, `He (the expert) brings cross-vehicleprogram experience that you don't get within our


7/27/2019 IJEE1367

7/11

team' and he added, Ìf I'll be perfectly candid, theknowledge he brings is things I think I shouldprobably have myself, but don't. I don't havethat range of experience. He covers my back.'

Experts enjoyed this responsibility because itmade them feel the experience they had gainedover the years was needed and useful. An expert

remarked, Ì'd like to make sure that they have allthe things they need or require before taking theirnext step.' In program steering meetings, whenthey were not addressed directly, experts moni-tored the discussion within the group to ensure theteam was in compliance with the process. If theyfelt the team was overlooking a relevant procedureor deliverable, they intervened and clarified itsintent and implications so that the team recognizedits value and paid more attention to it.

For experts, monitoring teams and contextualiz-ing process and other vehicle development know-ledge for them in order to minimize risk was muchmore than just being an expert; it was an expert putto use. Experts preferred being risk managers toacting as process references since managing risk isproactive, whereas acting as a process reference byanswering questions is reactive. Another expertsaid, Ì get bored with redundancies. I get boredwhen people treat me as a library function ofinformation.'

Gap fillingAn efficient approach to platform-based vehicle

development is to structure product developmentteams so that they vary in size and scope. However,under certain conditions, variability in the compo-

sition and nature of the team might also limit itsability to be responsive. Gap filling refers toexperts taking initiative in finding and tacklingsuch issues facing teamsprocess related or not.When filling gaps, experts acted as `wildcard teammembers' who waited on the side, and searched foropenings developing within teams. It was anotherway for them to apply their vehicle developmentexperience and feel useful. An expert remarked, Ìgo to some meetings and bring some of my priorexperience and expertise into the meeting and tryto get things moving.' That entailed fulfilling therole of a design engineer, CAD consultant, projectplanner, manufacturing engineer, etc. An expert

explained, Ìf there is a hole someplace in theprogram, if there's something that needs to bedone, we just go in and try to help you do it.'

That required experts to take the initiativemeaning teams were not inclined to take advantageof experts as `reserve' members in this fashionunless they were approached by experts first.There were two reasons for that. The first onewas related to the organizational structure. Asdiscussed earlier, experts were, and needed to be,`free agents' within Giant to meet the diverse rangeof demands on them. That meant they were notnecessarily handed down specific tasks to accom-

plish. They were conveyed meanings and intentsa broader and qualitative description of what they

should accomplish. Therefore, they did not belongto a tight group, and their performance could onlybe measured indirectly by their manager; PDEmanagers contacted team managers personallyand received feedback on contribution of theexperts working under them. Therefore, expertsdid not directly report to teams. They could not

be `managed' or handed specific `work' by them.Some experts regarded that as being `dangerous'because they felt that at timesdepending on thestage of the program they were assigned totheycould easily drift into a state where they hadnothing to do unless they constantly pursued newresponsibilities.

The other reason for the reluctance of teams totake advantage of experts as reserve members isrelated to the socialization mechanisms betweenthem, which will be discussed in detail under the`Gaining social acceptance' expert responsibilitycategory.

Process improvementThe process was not static. It was constantly

being challenged while teams applied it to productdevelopment practice. As an abstract methodol-ogy, it contained elements that clashed with reality,with how things actually were and could be. Therewere parts of the process teams had difficultyunderstanding. In such cases, experts clarifiedand interpreted the meaning of the procedure inquestion for such elements. The basis of thoseinteractions was the elements of the process thatrequired negotiation to gain meaning and value.Newly introduced methodologies are bound to

have them. New methodologies are also bound tohave elements that simply do not apply, whichneed to be modified and reintroduced. GPDPcontained such elements. An example is a teammember objecting strongly to an expert regardinga tolerencing specification dictated by the process.The expert agreed with the objection, and laterremarked, Ìt (the specification) is an ideal methodof doing something that first of all within itselfdoesn't work, and the program teams don't use itthat way. A vehicle surface is not developed thatway.'

Experts had the potential of improving theprocess since they worked with teams, who identi-

fied such faulty elements, as well as with the coreprocess group, who maintained the process andcould modify them. The organization realized this,and perceived ìnitiating process change controlissues' as an expert responsibility. That couldhappen in two settings: during one-on-one discus-sions with core process group members, andduring `Process Change Control' meetings whereseveral core process members and experts could bepresent simultaneously. Even though all expertswho were interviewed acknowledged thesemechanisms, only one was motivated to facilitateprocess improvements and actually used them. The

others believed the influence they could have wasnot significant in either case.


7/27/2019 IJEE1367

8/11

Gaining social acceptanceExperts interacted with a wide range of per-

sonalities within teams, who had different concep-tions of them and the process. Some saw expertsand the process as resources to be utilized, otherssaw them as abstractions and as `policemen'. Somebelieved they could learn from them, others

thought they were complicating their work, andtherefore should be ignored. An expert describedthese differences by saying, `Every time I go to adifferent program team, it just blows me away.And I just cannot believe that there's one team thatwill sit on the edge of their seats and listen to youspeak and absorb every word, and other ones everytime you open your mouthbecause you're aprocess personthey don't want anything to dowith you. The polarity is there.' Such preconcep-tions regarding the process and experts were notonly individual and team dependent; they werealso situation dependent. Team members whowere receptive in one situation might not be sowilling in another.

Experts often referred to the importance ofgaining social acceptance from teams by pointingout the danger of remaining an outsider. Theybelieved the most effective position for them wasto be a `welcomed outsider' where they were notnecessarily considered a permanent team member,yet were valued and utilized as a knowledgeableresource.

Team members, on the other hand, were awareof some of their preconceptions. Some believedthey were biased for a good reason, others weresimply cautious and took a wait-and-see approach.

PDE managers were also aware of the socialbarriers, and thought of strategies to overcomethem. For example, they urged experts to step inand support teams in any way they can in `crisis'situations when team resources were stretched andinadequate in order to gain the trust of the teams.

However, none of the groups except theresearcher perceived gaining social acceptance asa PDE responsibility. Even though the othergroups recognized the importance of the topic,they perceived it as a common difficulty encoun-tered by experts in meeting their responsibilitiesrather than a distinct expert responsibility in itself.The researcher categorized gaining social accep-

tance as a responsibility because it constituted aprerequisite for realizing any of the other expertresponsibilities outlined in Table 1.

Solution creation and tool utilizationAlthough the organization perceived solution

creation and tool utilization as PDE responsibil-ities, there was not any evidence to point out thatthe groups perceived them as such, or that theywere even performed in practice. Some expertsmentioned that they like `thinking about differentways of doing business' and `solving teams'

problems', but they did not elaborate on howthey would achieve those other than through

fulfilling the responsibilities already discussed inthis section.

INTEGRATING THE FINDINGS: AGROUNDED MODEL

There was a strong consensus on the role expertsplayed in sharing cross-vehicle product develop-ment knowledge, providing process informationon demand, and assessing process proficiency ofteams and organizing training programs whennecessary.

As pointed out in the `Sharing of cross-vehicleprogram knowledge' category, experts wereconsidered to be free agents within the organ-ization. The implication is that they interactedwith several program teams at a time, and there-fore, had the opportunity to observe and learnfrom the application of a variety of productdevelopment concepts and the resolution of asso-ciated problems. The knowledge they acquiredwhile observing product development situationsas an expert, together with the knowledge theyhad accumulated developing products for overtwenty years at Giant, enabled them to interpretand contextualize the formal process knowledgefor the teams. Experts had the necessary vision tocontemplate the meanings behind the process, andto convey them to teams in tangible terms. Whatteams did with the conveyed meanings was up tothemexperts did not interfere with the specificsof their application. Therefore, experts can bethought of as interpreters; they relied on the tacit

knowledge they had gained while observing andparticipating in product development situations inorder to contextualize the meaning of formalprocedures for teams.

Under the `Process Reference' category, it waspointed out that experts acted as process referenceresources when teams approached them with speci-fic questions. Then, we should ask if the `Processreference' responsibility is related to the `sharing ofcross-vehicle program knowledge' responsibilitydiscussed above. Perhaps, the question is betterstated as: Did experts interpret and contextualizeprocess knowledge when they acted as processreferences? The answer is mainly no, and that is

why a distinction was made between the topics.Experts did not enjoy serving as process refer-encesas `library functions of information' asone expert put itprecisely because it did notgive them the opportunity to interpret and contex-tualize what they knew. They did not find meaningin relaying content-specific information, which washighly impersonal. Therefore, even though theyacted as process references at times, they did notsee much value in doing so.

As for the differences between the perspectives,the groups differed in the way they viewed the roleexperts played in managing risk, filling gaps and

gaining social acceptance within teams.In the case of risk management, experts paid


7/27/2019 IJEE1367

9/11

special attention to the progress of teams bymonitoring their decisions, and to the potentialimpact of those decisions on program deliverablesand milestones. Although the organization and theresearcher failed to emphasize this as an expertresponsibility, experts and teams did not. That wasmost likely because the organization and the

researcher took a theoretical approach, whereasexperts and team membersthe practitionersreflected on a behavior that was necessitated bypragmatic needs.

Another expert responsibility necessitated bypragmatic needs, emphasized by the practitionersbut not the organization or the researcher, was`gap filling'. Experts filled gaps within teams whenresources were scarce and some tasks were uncov-ered. They saw those situations not only as oppor-tunities to utilize their subject matter expertise, butalso to gain team acceptance as `welcoming out-siders'. Likewise, PDE managers believed the crisissituations within teams to be excellent opportu-nities for experts to demonstrate their value in anyway they could to earn their trust. In that sense,gap filling helped experts to gain social acceptancefrom teams.

The researcher thought of gaining social accep-tance as a critical requirement for experts to meetany of the other responsibilities. However, expertsand the organization did not emphasize its impor-tance as a difficulty rather than a distinct respon-sibilitythey perceived as a difficulty instead. Thereason for this difference was unclear, and needs tobe studied. However, it was clear that no matterhow much `expertise' an expert might have had, it

was difficult for him to be effective and useful in ateam without being and feeling welcome. If anexpert was not considered a member of the team,any biases of the group toward him and what hewas thought to representa highly methodical,and somewhat intrusive, processwas bound toinfluence what the group could learn through him.Therefore, gaining social acceptance from teamswas one of the initial challenges experts met whenthey were assigned to a new program, and hadconsiderable effect on how product developmentknowledge was acquired.

When these findings are viewed in light ofconstructing a comprehensive product develop-

ment knowledge acquisition model, it can be seenthat the type of knowledge exchange presented inFig. 1 is indeed far from being representative ofwhat took place. What becomes clear is thatexperts did not necessarily possess an inert formof product development knowledge to be trans-ferred, and that, instead, they facilitated the acqui-sition ofemergingproduct development knowledgeby interpreting the meanings contained in theprocess and contextualizing them for teams. It isimportant to realize that the `free-agent' status ofexperts within the organization allowed them toobserve a variety of product development prac-

tices. That, in return, performed two functionsbringing in relevant cross-platform knowledge

from other teams who were dealing with similarissues, and constantly grounding experts in practiceso that they could develop the vision to bridge thegap between formal process knowledge and infor-mal product development knowledge for teams.Apart from the facilitator/interpreter role, expertsalso servedat least, had the opportunity of serv-

ingas an interface between teams and the processby feeding the reactions of teams on the processback to the core process group for improvement.

Teams, on the other hand, were primarilyinvolved in applying the product developmentknowledge they acquired to product developmentpractice. There were two mechanisms for teams toacquire such knowledge: learning from the processprinciples contextualized for them by experts, andlearning from observing their own involvement inproduct development. The first one concerns theirinteraction with experts, and the second theirinvolvement in product development practice.Overall, it was difficult to assess how muchproduct development knowledge they acquiredthrough which mechanism. It is plausible tothink that the expert interaction is not necessaryfor them to acquire PD knowledge; instead, it canbe thought to augment it. The contribution of theexperts was unclear. No metrics were developed bythe organization to assess expert effectivenessregarding this, and surprisingly, any otherprocess-related learning mechanism.

And finally, the organization can be thought tobe the link between PD practice and PD History: itretained the informal PD knowledge generatedduring PD practice over time, accumulating a PD

history, and reduced it later to a formal productdevelopment process, GPDP. The specifics of howit might retain the informal PD knowledge andform a history was not a part of this study, andtherefore, was not investigated.

A new product development knowledge acquisi-tion model emerges from these findings (Fig. 3).The model makes a distinction between formal andinformal aspects of practice and knowledge.Organization, product development history, andGPDP are seen to be predominantly formalelements, and PDEs, VPTs and product develop-ment practice informal elements. The arrowsrepresent the `acquisition' or `co-generation' of

PD knowledge. PDEs appear at the boundarybetween formal and informal domains, and playa critical role in transforming the formalizedaspects of the process to the informal mediumteams prefer to work with. There is no specificnode or interaction where PD knowledge is`created'. Instead, it is thought to emerge fromthe combined interaction of the representedelements.

CONCLUSIONS

In addition to the product development know-ledge acquisition model presented in the previous


7/27/2019 IJEE1367

10/11

section, there are four conclusions that can bedrawn from the findings of this study:

1. The formalized tasks and procedures embodiedin a product development process need to beinterpreted and contextualized for productdevelopment teams. Otherwise, what the pro-cess suggests does not appear tangible andvaluable to teams, and runs the risk of beingperceived as an overhead. What is of value tothe teams is to contemplate the intent of the

processthe rationale behind the suggesteddefinitions and procedures. The intent of aproduct development process is not necessarilywhat can be formally captured and representedin flow charts, resource allocation tables, andtask and deliverable definitions. On the con-trary, it is mainly a common informal under-standing of ways of doing the things that arenecessary to develop a product, and reliesheavily on the interactions of the involvedparties.

2. Product development experts can be effective inaccomplishing that contextualization by draw-ing on their own past as well as ongoing

product development practices. In fact, it iscritical that experts engage inat least as anobserverthe ongoing product developmentpractices of the teams; the relevance of theirinterpretations increases when they aregrounded in the situations they are interpretingfor. Thus, for experts, an Observe-Interpret-Contextualize cycle forms the basic mechanismfor facilitating the knowledge acquisition ofteams.

3. However, when experts are deployed in order tofacilitate the product development knowledgeacquisition of the teams, two conditions arise

as prerequisites to the effectiveness of theinteraction:

. No matter how much PD `expertise' expertsmight have, it is difficult for them to beeffective in facilitating the PD knowledgeacquisition of teams without being and feel-ing welcome. If experts are not accepted atleast as welcomed outsidersif not as tem-porary membersto teams, biases teamsmight have toward what they are thoughtto represent is bound to influence how muchthey can learn from them.

. The mechanisms experts utilize in facilitating

the product development knowledge acquisi-tion of teams must be meaningful for them.That entails the utilization of experts insituations where they are given the chanceto interpret and contextualize the knowledgethey are expected to convey to the teams.Utilizing experts as reference resourceswho respond to inquiries by merely `relaying'information is not meaningful to them.

4. In such expert-team interactions, it is impera-tive that PD knowledge acquisition metrics aredeveloped before product development pro-cesses and experts are deployed within theorganization. Otherwise, it is very difficult todifferentiate the improvements in productdevelopment practice due to expert facilitatedknowledge acquisition from other factors suchas the natural knowledge acquisition activity ofteams and external conditions to the organ-ization. The situation at Giant constituted anexample where reliable metrics for assessing theeffectiveness of the process and experts were notin place, and measuring their impact on productdevelopment practice proved to be problematic.

These findings indicate that product develop-ment knowledge cannot be embodied in a specific

individual, a specific group of individuals, or aformal process. Those elements can only embody

Fig. 3. A product development knowledge acquisition model based on the findings.


7/27/2019 IJEE1367

11/11

aspects of product development knowledge. Inter-action of those elements is what assigns meaning tothe aspects of knowledge and allows for theirsynthesis. Therefore, it can be said that productdevelopment knowledge emerges out of the

combined interaction of the involved people andresources.

AcknowledgementsThe research was supported (in part) bythe MIT Center for Innovation in Product Development underthe NSF Cooperative Agreement Number EEC-9529140.

REFERENCES

1. V. Hubka, Principles of Engineering Design, Translated by W. E. Eder, Butterworth Scientific,Guildford, (1982).

2. S. Pugh, Concept selectiona method that works, Chapter 14 from Creating Innovative Productsusing Total Design, Addison-Wesley (1996) pp. 167176.

3. David Ullman, The Mechanical Design Process, McGraw-Hill, Inc. (1992).4. L. Louis Bucciarelli, An ethnographic perspective on engineering design, Design Studies, 9(3), July

1988, pp. 159168.5. Margot Brereton, David Cannon, Ade Mabogunje, and Larry Leifer, Collaboration in design

teams: how social interaction shapes the product, Analyzing Design Activity, N. Cross, H.Christiaans, K. Dorst (eds), Wiley (1996) pp. 319341.

6. J. W. Creighton, J. A. Jolly, and S. A. Denning, Enhancement of research and development outpututilization efficiencies: linker concept methodology in the technology transfer process, NPS-55CF72061A, Naval Postgraduate School, Monterey, CA, June 1972 (AD 756694).

7. J. A. Jolly and J. W. Creighton, Technology transfer and utilization methodology: further analysisof the linker concept, NPS-55Jo74061, Naval Postgraduate School, Monterey, CA, June 1974,(AD 003867).

8. M. E. Essoglou, The linker role in the technology transfer process, Jolly J. A., Creighton J. W.(eds.), Technology Transfer in Research and Development, Naval Postgraduate School, Monterey,CA (1975) pp. 115.

9. B. Andrew Hargadon, Firms as knowledge brokers: lessons in pursuing continuos innovation,California Management Review, 40(3), 1998, pp. 209227.

10. B. Andrew Hargadon, Technology brokering and innovation in a product development firm,Administrative Science, 42, December 1997, pp. 716734.

Ozgur Eris is a Ph. D. candidate in Mechanical Engineering at Stanford University. Hereceived a BS from University of Washington, and a MS from Stanford University inMechanical Engineering. His research interests include the role of question asking in design

activity, design team performance metrics, design knowledge generation and capture, andthe interdisciplinary aspects of creativity.

Larry J. Leifer is Professor of Mechanical Engineering at Stanford University. He isdirector of the Center for Design Research. He received a BS in Mechanical Engineering, aMS in Product Design, and a Ph. D. in Biomedical Engineering from Stanford University.He has published in the areas of diagnostic electrophysiology, functional assessment ofvoluntary movement, rehabilitation robotics, design team protocol analysis, design know-ledge generation and capture, and concurrent engineering. He has worked at Hewlet-Packard, General Motors, NASA Ames Research Center, the MIT-Man Vehicle Labora-tory, and the Swiss Institute of Technology in Zurich. A member of the Stanford facultysince 1976, he has taught product design, Smart Product Design, and industry sponsoredmechatronics systems design.


Documents

IJEE1367