Download - Understanding the complexity of knowledge integration in collaborative new product development teams: A case study

Understanding the complexity of knowledge integration incollaborative new product development teams: A case study

Maaike Kleinsmann *, Jan Buijs, Rianne Valkenburg

Department of Product Innovation Management, Delft University of Technology, Faculty of Industrial Design Engineering,Landbergstraat 15, 2628 CE Delft, The Netherlands

1. Introduction

Consider a telephone. From the 1940s till the 1990s, a phone did not change much with regard to itsproduct functionality and product architecture (Valkenburg, 2000). However, in the last 15 years, theproduct had changed in many ways. The switch from a shared house phone to a personal phone hashad a significant impact on both the product appearance as well as product use. People do not use theirpersonal phone only for calling, but also for taking pictures, making movies, playing games, listeningto music and as an agenda. This has changed the consumer attitudes towards a phone. What once wasa rather functional product has become a product that expresses one’s personality. Therefore,customers required their phone to be modern, easy to use, and of good quality. In the meantime, theydid not want the phone to be expensive, as they would like to buy a new one every 2 years.

These customer needs reflect increasing customer demands and increasing product complexity,requiring a far-reaching integration of the different knowledge domains of the actors from different

J. Eng. Technol. Manage. 27 (2010) 20–32

A R T I C L E I N F O

Article history:

Available online 8 April 2010

JEL classification:

0.32

Keywords:

Collaborative new product development

Knowledge management

Shared understanding

Multidisciplinary teams

A B S T R A C T

Knowledge integration is important in collaborative new product

development (Co-NPD). The research literature shows that the way

actors create a shared understanding about the new to create

products is a quality indicator of Co-NPD. This study investigates

what factors influence the creation of a shared understanding in Co-

NPD. The results show factors at three different levels; the actor,

project and company level. Additionally, there exist relationships

across the factors. The related factors form four different types of

interfaces. The interfaces differ from each other since different

types of collaborative mechanisms exist within them.

� 2010 Elsevier B.V. All rights reserved.

* Corresponding author. Tel.: +31 15 2788657.

E-mail address: [email protected] (M. Kleinsmann).

Contents lists available at ScienceDirect

Journal of Engineering andTechnology Management

journal homepage: www.elsevier.com/locate/jengtecman

0923-4748/$ – see front matter � 2010 Elsevier B.V. All rights reserved.

doi:10.1016/j.jengtecman.2010.03.003

mailto:[email protected]

http://www.sciencedirect.com/science/journal/09234748

http://dx.doi.org/10.1016/j.jengtecman.2010.03.003

disciplines during collaborative new product development (Co-NPD) (Garcia and Calantone, 2002;Swink, 2000; Veryzer, 2005). Granstrand et al. (1992) found that the first generation of cellular phonesin the 1980s only required electronic skills to be developed. However, in the 1990s, the developmentof the third generation of these phones demanded knowledge in physical ergonomics, electronic,mechanical, and computer engineering, and physiological and psychological aspects. In the last 10years, the knowledge needed to develop today’s mobile phones had increased yet again.

Since the increased product complexity requires knowledge and skills from different fields, Co-NPD teams within companies have the responsibility to integrate these different knowledge bases(Edmondson and Nembhard, 2009). Knowledge integration appeared to be difficult for them,because actors often had different, interests and perspectives on the new to develop product (Bondand Ricci, 1992; Bucciarelli, 1996; Dougherty, 1992; Emmanuelides, 1993; Griffin and Hauser,1996; Moenaert and Souder, 1990; Moenaert et al., 2000). Furthermore, it was demanding forcompanies manage the actors towards thinking along the same line since actors faced difficultiesin interpreting and understanding each other’s knowledge (Adams et al., 1998; Bucciarelli, 2002;Dougherty, 1992; Griffin and Hauser, 1996; Hage et al., 2008; Moenaert and Souder, 1990). Thereason for this was that actors from different disciplines used different languages and differentrepresentations of the design artefact. Additionally, they often had different interests andresponsibilities. Therefore, negotiations and trade-offs were required to make the actors’ effortscoherent (Bucciarelli, 1996).

In the case study presented in this paper, Co-NPD is defined as: the process in which actors fromdifferent disciplines share their knowledge about both the development process and its content. Theydo that in order to create shared understanding on both aspects, to be able to integrate and exploretheir knowledge, and to achieve the larger common objective: the new product to be designed(Kleinsmann, 2006). Knowledge sharing is a critical intervening variable in organizationalperformance in Co-NPD (Mohrman et al., 2003), which shows the importance of an effective Co-NPD process. Research showed that companies face some major knowledge management challengesduring Co-NPD since it thrives upon the exploration of knowledge under a high degree of uncertainty(Berends et al., 2007). Since actors do not have to become experts in each other’s fields, they do nothave to share all their knowledge. Yet, they have to be able to integrate their knowledge bases in asensible manner.

Therefore, Berends et al. (2007) claimed that, during Co-NPD, knowledge management shouldfocus on knowledge integration instead of focusing on knowledge transfer. They also statedthat the effectiveness of knowledge integration required a mutual understanding of theactor’s contributions. This is in line with research on design communication, which finds thatthe quality of the Co-NPD project is dependent on the process of creating a shared understanding(Dong, 2005; Kahn, 1996; Valkenburg, 2000). In addition, our interviews with product managersrevealed that managers need more knowledge on how they could manage the creation of a sharedunderstanding among actors from different disciplines, as the following quote from a productmanager illustrates:

‘‘. . .There is no problem that cannot be solved technically. At least I have never experienced thatpersonally. Finally, they always solve it. They use project management tools to map the problemand to find the solution. However, the real problem is the communication among the teams. Didthey understand each other and are they critical enough to each other? . . . Dependent on theirdiscipline, they have a feeling for each other’s discipline, but the real details . . . It is complex tobe able to know all parts about every discipline. As a Project Manager, you really have to beaware of this. That is also the reason why I need something to monitor that . . .’’ (Project ManagerPhilips).

The study presented in this paper focuses on the process of creating a shared understanding in Co-NPD projects. The paper starts with a literature review about the role of shared understanding in Co-NPD projects. It continues with a description of the case study executed, followed by a description ofthe learning history method that was used as the research method. The paper concludes with itsresults, limitations, implications for future research and with a discussion of the results andimplications for managerial practice.

M. Kleinsmann et al. / Journal of Engineering and Technology Management 27 (2010) 20–32 21

2. The role of shared understanding in Co-NPD projects

In this paper the Co-NPD process was considered as a social process. According to Weick andRoberts (1993), an actor executes three main activities during this social process. The first activity isthe construction of the task that an actor needs to perform. This allows the actor to understand that thetask is a part of a system and that others perform different and complementary tasks in the system.Thus, an actor interrelates his action to the actions of others. This shows that the relations among theactors are not predefined, but constructed during the process and that actors depend on findings fromthe other actors. A result derived by an actor performing a development task may result in thenecessity that another actor needs to make an iterative loop. Cross (1990) found that a Co-NPD teamcannot prevent these loops, since they are the nature of developing. However, these iterative loops canalso originate from mistakes in the extraction and re-enactment sense to the system. These mistakesmay indicate that a shared understanding about the design content does not exist and that the tuningacross the actors fails (Mohammed and Dumville, 2001; Mohrman et al., 2003; Valkenburg, 2000).

Mohammed and Dumville (2001) claimed that actors have created a shared understanding if theyhave reached cognitive consensus, which refers to the similarity among the actors about how the keyissues in the development process are conceptualized. Both Mohammed and Dumville (2001) andMohrman et al. (2003) added that process related aspects are also important for the creation of ashared understanding. Mohammed and Dumville (2001) adopted the term transactive memory fromWegner (1987), which is ‘a set of individual memory systems, which combines the knowledge processed by

particular actors with a shared awareness about who knows what.’ Transactive memory makes it possibleto develop complex products with actors from different disciplines without having too muchredundancy of knowledge. With the use of these insights, we defined shared understanding as: a

similarity in the individual perceptions of actors about how the design content is conceptualized (content)or how the transactive memory system works (process).

Earlier research on shared understanding in Co-NPD teams discovered that a lack of a sharedunderstanding caused unnecessary iterative loops in Co-NPD projects (Hill et al., 2001; Valkenburgand Dorst, 1998). Ultimately, a lack of a shared understanding reduces the quality of the final productbecause, in the end, actors did not solve all problems. Therefore, effective communication is anelementary component of Co-NPD (Bucciarelli, 1996; Hill et al., 2001; Kratzer, 2000; Leenders et al.,2007). Song et al. (2003) added that the highest quality products came from teams with an increase inshared understanding. When there is no shared understanding at the start of a Co-NPD project, actorsneed to discuss the issues at hand and need to learn from each other. Weick and Roberts (1993)explained that groups are smartest in the early stages of Co-NPD because teams loose mind andinterrelating across the disciplines becomes more routine, more casual and more automatic at the endof the project, which reduces the quality of the interaction. This could also be an explanation for theremarkable finding of Cummings and Teng (2003) who found that, during Co-NPD projects, non-embedded knowledge transfers were more successful then embedded knowledge transfers.

Previous research showed the importance of the process of creating a shared understandingbetween actors in Co-NPD processes. Research has also shown that creating a shared understanding isdifficult since actors in Co-NPD projects come from different disciplines. However, previous researchdid not show what factors hampered (=barriers) or enabled (=enablers) the process of creating ashared understanding. Yet, these factors are important for managing knowledge integration processesefficiently. This study investigated the barriers and enablers for the creation of a shared understandingin a Co-NPD project in industry. Additionally, we identified relationships between the differentbarriers and enablers and their underlying patterns. We called these patterns collaborativemechanisms. Collaborative mechanisms describe the influence of the barriers and enablers for thecreation of a shared understanding during Co-NPD projects on knowledge integration.

3. Case description

We studied a Co-NPD team that was responsible for the development of tunnel installations for theDutch high-speed train from Amsterdam to Brussels. The team developed, for example, the elevators,vans and Escape Doors in the tunnels. All tunnel installations need to function together (in the case of

M. Kleinsmann et al. / Journal of Engineering and Technology Management 27 (2010) 20–3222

an accident), so collaboration was a major factor during this development project. Since there wereeleven technical subsystems, many different disciplines were involved in the team. The Co-NPD teamobserved was part of a consortium that is responsible for the superstructure of the route and the futuremaintenance.

From a surface level observation of the Co-NPD team, one cannot speak of the development team.The team was a collaborative team hierarchy, from which the structure originated from the newproduct’s architecture (Gerwin and Moffat, 1997). The team studied consisted of three different typesof sub-teams. The first type of sub-team was the homogeneous development team that developed atechnical subsystem. The Co-NPD project studied consisted of eleven of such teams. The second type ofsub-team was the system engineering team with representatives from the homogeneous developmentteams and two system engineers. This team integrates the eleven subsystems. The third type of sub-team was the multidisciplinary management team, also called the core team. Besides representativesfrom the homogeneous development teams, actors from Quality, V&V (Validation and Verification),RAMS (Reliability, Availability, Maintainability and Safety), Occupational Health and Safety andProcurement were in the core team. The core team planned and monitored all activities needed todevelop the new product. Together, the Co-NPD team consisted of about 60 actors at the time of thisstudy.

4. Research method

The learning history method was used as the research method for executing the case study (Kleinerand Roth, 1996; Roth and Kleiner, 2000). This learning history method has been developed to facilitateorganizational learning. The method is based on storytelling. Since stories enhance relating events toeach other, they enable the construction of relationships between events. Knowing these relationshipswill enhance the development of an understanding of the mutual relationships between the factorsthat influence the creation of a shared understanding.

Fig. 1 shows the research steps that were distilled from the learning history method (Kleiner andRoth, 1996). Three basic research steps, data gathering, data processing and data analysis, were used inorder to structure the research process. Each phase consisted of activities and results. In Fig. 1, theactivities are represented by squares and diamonds present the results. The remainder of this sectiondescribes how the different steps were executed in this study.

During data gathering, gaining noticeable results was the first activity. According to Kleiner andRoth (1996), ‘noticeable results are outcomes, activities, events, behaviors or policies which are out of the

ordinary, much different than would have typically occurred before the learning project.’ This studygenerated the noticeable results by observing the development team during meetings. In total, twelvemeetings of 1–4h each were observed. During the meetings, notes were made of the designcommunications of the actors involved. The noticeable results functioned as input for the preparationof the interviews and the desk research.

On the basis of our observations, the actors who were most involved during the noticeable resultsof a particular meeting were selected for interviewing. In order to interview the actors, a structuredinterview approach was used. The last activity of the data gathering phase was the actual execution ofthe interviews and the desk research. We conducted 22 interviews with 18 different actors. Someactors were interviewed more then once since they were key figures in more than one meeting. Thedesk research concerned reading project documentation, project presentations, emails and minutes ofmeetings. The desk research provided a deeper understanding of the Co-NPD project. Furthermore, ithelped verify the opinion of the actors who were interviewed.

We processed the interviews and distilled the barriers and enablers from the interviews bylistening to he tapes of the interviews during the data processing phase.

The data analysis phase comprised both the coding and clustering of the barriers and enablers. First,the barriers and enablers were coded according to three organizational levels: the actor, project andcompany level as defined by Kleinsmann and Valkenburg (2008). Second, the barriers and enablerswere clustered based on their content, where all clusters concern a different interface. Within aninterface, the relationships were between the barriers and enablers were analyzed. Based on theserelationships, we grouped the interfaces into clusters in which the same type of collaborative


Fig

.1

.T

he

lea

rnin

gh

isto

ryp

roce

ss.


mechanism occurred. Data validation was the last activity of the data analysis phase. During this step,the results of the case study were presented to the actors involved, who verified the interpretationsmade. We held two workshops to check the interpretations made with the company people. For thecompany staff, this validation check of the data was an important moment of reflection. They used it todetermine the key lessons of the Co-NPD project. Participants of the workshops were the key figures aswell as some representatives from the management board of the company. The management boardused the results in order to transfer the lessons of this project into future development projects at amore strategic level.

5. Results

The first part of this section describes the factors that influenced the process of creating a sharedunderstanding. The second part describes the different interfaces found and the collaborativemechanisms within these interfaces.

5.1. Factors that influenced the creation of a shared understanding

The interviews conducted found 155 barriers and 74 enablers. All interviews contained about thesame amount of barriers and enablers. The barriers and enablers were categorized according to thethree organizational levels. There were 50 barriers at the actor level, 93 at the project level and 12 atthe company level and 25 enablers at the actor level, 44 at the project level and 5 at the company level.Table 1 shows some examples of barriers and enablers at the three organizational levels.

To generalize the findings of this case study, the barriers and enablers were abstracted. All barriersand enablers were analyzed through process factoring (Miles and Huberman, 1994) in order toidentify the factors underlying. Barriers and enablers that belonged to the same factor were clustered.For example, the barrier The Engineers of Escape Doors did not know they were responsible for the CMI’s(=a type of document) belongs to the factor The empathy of the actors about the interest of a task. At eachof the three organizational levels, several factors were identified that either hampered or stimulatedthe creation of a shared understanding. Table 2 shows the most frequently occurring factors at eachorganizational level.

Table 2Most frequently occurring factors that influence the creation of a shared understanding.

Level Factor(s)

Actor The equality of the language used between the actors

The ability of actors to make a transformation of knowledge

Project The efficiency of information processing

The quality of project documentation

Company The allocation of tasks and responsibilities

Table 1Examples of barriers and enablers at the three organizational levels.

Level Barrier Enabler

Company The move of the Control department to another

building decreased the amount of communication

between control and the rest of the development team

There was a system-engineering group

established on the consortium level of the

Co-NPD project

Project As a result of the cancellation of the system-engineering

meeting, the Project Leaders of the subsystems did not

know from each other what they were doing

Decisions related to the content of the

subsystems were put in the minutes of the

system engineering meeting

Actor Control used another definition for the failure of an

Escape Door than Escape Doors did

A RAMS Engineer translated the jargon of

the subsystems into their own jargon


The factor at the actor level that occurred most frequently is the equality in language used between

the actors. The major issues concerning the equality in language was the different jargon that theactors used (both in words as well as drawings) and the different native languages that the actors used.The second factor at the actor level that occurred frequently is the ability of an actor to make a

transformation of knowledge. This factor concerned the knowledge exchange across disciplines. Sinceactors of different disciplines used different knowledge, a transformation of knowledge was alwaysneeded. The actors needed to transform both the content of the knowledge and the representation ofthe knowledge.

At the project level, the factor that occurred most often is the efficiency of information processing.Barriers concerning the efficiency of information processing were, for example, that theinformation arrived too late for the receiver, such that the actor could not move on withthe task, or that the receiver did not know the status of the document. Enablers concerning theefficiency of information processing included, for example, the early involvement of another sub-team and the active approach of one sub-team towards another sub-team. The second most occurringfactor at the project level was the quality of project documentation. Problems with the quality of thedocuments were caused by, for example, ongoing changes in the documents and incompletedocuments. Despite these quality problems, most of the documents provided applicable information forthe receiver. The engineers actively used the documents to structure the complexity of the Co-NPDproject.

The factor at the company level that most frequently occurred was the allocation of tasks and

responsibilities. Within the project, there existed many interdependencies at different levels inside andoutside the project team and outside the company. For the engineers, it was difficult to foresee theconsequence of getting involved in a task outside their direct scope. Furthermore, the group that hadto integrate the subsystems did not function properly. They could not define the interfaces betweentwo subgroups clearly. Therefore, the engineers of the subsystems were not actively involved inaspects that were just outside the scope of their own task.

5.2. Different types of interfaces

By clustering the barriers and enablers according to their content, ten different interfaces and asmall remainder category (which consists of only five barriers and enablers) originated. All interfacesconsisted of barriers and enablers at more than one organizational level.

The interfaces were also clustered in order to get a better understanding of the differentcollaborative mechanisms that existed in our case study. Studies about boundary spanning showedthat different interaction patterns exist in interfaces that occur within an organization andinterfaces that occur between organizations (Ancona and Caldwell, 1992; Katz and Tushman, 1981;Lysonski and Woodside, 1989; Sonnenwald, 1996). Looking at the interfaces found in our casestudy, we were able to distinguish these two types of interfaces. As Hoegl et al. (2004) found thattask innovativeness influences the quality of the teamwork, we also made a distinction betweeninterfaces related to a regular task and interfaces that concern an innovative task within the internalinterfaces. Based on the preceding, our case study consisted of the following four types of interfaces:(1) interfaces with the outside world; (2) interfaces between the development team and theorganization; (3) interfaces within the development team that deal with regular aspects within theCo-NPD project; and (4) interfaces within the development team that deal with innovative aspectswithin the Co-NPD. Table 3 shows the interfaces of the case categorized according to the four typesof interfaces.

5.3. Collaborative mechanisms within the four different types of interfaces

Table 4 shows what knowledge the actors had to integrate for each type of interface and whichfactors were most important for the creation of a shared understanding between actors in thatinterface.

In addition to Table 4, we describe the qualitative analysis of the collaborative mechanisms withineach type of interface below.


Table 4Collaborative mechanisms within the four types of interfaces.

Type of interface Knowledge to be integrated Factors that influence creating a shared

understanding

Interfaces with the outside world General knowledge about

parts that were designed

Procedural knowledge about

how to use the system

developed

Company level

Availability of specialized knowledge

Project level

Efficiency of information processing

Rigor of project planning

Actor level

The applicable knowledge of an actor

The ability to make a transition of knowledge

Interfaces between the development

team and the organization

Procedural knowledge about

task dependencies and

responsibilities

Company level

Allocation of tasks and responsibilities

Organization of the project team

Project level


Rigor of project planning

Actor level

The applicable knowledge of an actor


Interfaces within the development

team that deal with the regular

aspects within the Co-NPD project

Detailed knowledge about

each other’s design (task)

and process

Company level



Project level


Quality of project documentation

Actor level

The equality of language used

The empathy of the actors about the

interest of a task

Interfaces within the development

team that deal with innovative

aspects within the Co-NPD project

Detailed knowledge about

each other’s design (task)

and process

Company level



Project level


Quality of project documentation

Actor level


The equality of language used

Table 3Interfaces found clustered into four types of interfaces.

Type of interface Interface

Interfaces with the outside world The interface between the development team and the fire brigade

The collaboration process between the development team and the

civil contractor

The interface between the development team and their suppliers

Interfaces between the development team

and the organization

The collaboration processes between the development team and

maintenance

Interfaces within the development team

that deal with the regular aspects

within the Co-NPD project

Interface between the Project Leaders of the subsystems

The interface between the engineers of the development team

The collaboration process between Control and Escape Doors

The collaboration process between Control and Fire Fighting

Interfaces within the development team

that deal with innovative aspects

within the Co-NPD project.

The interface between the development team and the sub-team of RAMS

The interface between the development team and

sub-team of V&V


5.3.1. Interfaces with the outside world

Within the interface with the outside world, the development team had two different roles. Thefirst role was the supplier role. For example, the fire brigade was the future user of the tunnel technicalinstallations developed. Therefore, involving them in an early stage was important for thedevelopment team since the fire brigade could provide the team with user insights. However, thefire brigade was not willing to provide the development team with knowledge about their userrequirements because there was no formal contract between them. On top of that, the criteria that thefire brigade set were sometimes contradicting. Both the required highly formalized communicationstructure and the indistinctness about what types of knowledge the actors had to share hampered thecreation of a shared understanding between the development team and the fire brigade. This resultedin a lack of knowledge integration between them.

The second role that existed in this type of interface was the customer role. The fact that thesuppliers were also responsible for 25 years of maintenance, in addition to the development of apart of the tunnel technical installations, forced the development team to create a long-termrelationship with their suppliers and the civil contractor. As a result, the selection procedure wascarefully executed. The project managers of the sub-teams carefully explained to a potentialsupplier the context of the design task and the design process to follow. As a result, the supplierobtained a clear view of the content of the assignment and the interrelation with other aspects ofthe entire Co-NPD project, which enabled the creation of a shared understanding and thereforeknowledge integration.

5.3.2. Interfaces between development team and the organization

The interface between the development team and the organization comprised, in this case, theinterface with maintenance. The development team needed the input from maintenance becausethey were responsible for both the development and the maintenance of the project for 25 years.The communication structure between the development team and maintenance was highlyformalized, yet the task dependencies were unclear. For both maintenance and the developmentteam, it was unclear what knowledge they had to generate and share with each other. Thishampered the creation of a shared understanding between them. This was amplified by the factthat maintenance was not used to being involved in the conceptual stage of a Co-NPD project.Normally, they would only check if the systems meet their requirements once they were finished.They were not used to integrating their knowledge bases with the development team. So, inpractice, the involvement of maintenance was only procedural. This was problematic since theengineers needed content related knowledge in order to be able to make favorable engineeringdecisions from a maintenance point of view. The engineers of the development team were also notaccustomed to designing while keeping in mind the maintainability of the system they aredesigning. In addition to this lack of knowledge integration, maintenance also missed the capacityto do the work needed.

5.3.3. Interfaces within the development team that deal with regular aspects within the Co-NPD project

In interfaces within the development team, actors had to create a thorough understanding aboutthe content of each other’s development tasks. The engineers of the different subsystems had tointegrate their knowledge extensively since they had to make a design in which the differentsubsystems function optimally. Additionally, they had to create a shared understanding about thedevelopment process to follow since the task dependencies were high. Therefore, extensivecommunication between the different actors was needed. A formal communication structure was setup to enable the integration. The actors communicated in meetings with each other on a regular basis,but they also had informal communication. The written communication was so formalized that actorsthought of documents as deliverables in addition to the design artefact they had to deliver. Within allinterfaces of this type, the actors lacked a shared understanding about content related aspects at aconceptual level. However, since this interface deals with regular aspects within the Co-NPD project,there were always actors in the development team or within the organization who had dealt with acomparable situation before. Therefore, the effective use of these past experiences enabled knowledgeintegration within this type of interface.


5.3.4. Interfaces within the development team that deal with innovative aspects within the Co-NPD project

The actors in this interface needed detailed knowledge from the content of each other’sdevelopment tasks. However, as this type of interface concerned an innovative task, the actors facedboth technical uncertainty and lacked knowledge how to perform the task. These uncertaintiesinfluenced the collaborative mechanisms between the actors since they could not rely on pastexperiences. This hampered the actors making the necessary transformation of knowledge, whichhampered the creation of a shared understanding. The lack of clarify about what knowledge the actorsneeded from each other and where information was stored caused difficulties in planning andmonitoring the project. All aspects mentioned hampered the knowledge integration between theactors.

6. Discussion

The reason for executing this research was that earlier research showed that knowledge sharingand knowledge integration in Co-NPD is important since it has an influence on organizationalperformance (Berends et al., 2007; Jassawalla and Sashittal, 1998; Hoegl and Gemuenden, 2001; Hoeglet al., 2004; Kahn, 1996, 2001; Mohrman et al., 2003; Tessarolo, 2007). The literature also stated thatthe successfulness of knowledge integration is dependent of the ability of the actors to a sharedunderstanding during Co-NPD, which was the focus of our study (Berends et al., 2007; Dong, 2005;Kahn, 1996; Valkenburg, 2000). The results of this case study provides a deeper understanding of therole of shared understanding in Co-NPD projects in relation to the quality of the knowledge integrationprocess. The holistic approach chosen allowed mapping the complexity knowledge integration in Co-NPD projects.

In our study, we found factors that influenced the process of creating a shared understanding.These factors existed on three different organizational levels; the actor, project and company level.This means that the quality of knowledge integration is not only dependent on face-to-facecommunication, but also on project management and project organization. This case study was notthe only study in which such a relationship has been identified (Adams et al., 1998; Dougherty, 1992;Kleinsmann and Valkenburg, 2008). Dougherty (1992) recommended that firms should develop anorganizational context that enables collective action. However, recent interviews with managers ofCo-NPD have revealed that they still struggle with the organization of their development team and theembedding of the team in the organization. This makes it necessary to execute more research onknowledge integration and knowledge management systems by taking project management andproject organization into account in addition to face-to-face communication.

The results of this study also showed that there existed four different types of interfaces within theCo-NPD project studied. Within each type of interface, actors had to integrate different types ofknowledge. Additionally, different factors for the creation of a shared understanding played a role.This shows the importance of taking the type of interface into account while studying knowledgeintegration in Co-NPD.

7. Theoretical implications

Since the main limitation of the research approach is that only one case could be studied due to thelabor intensive approach, it would be captivating to investigate if the list of factors established in thisstudy would suffice for other cases or if more factors would arise. In order to create knowledge aboutthis, more case studies should be done according to the learning history method. Having a largernumber of cases to refer to would deepen our understanding of the factors. This would also createmore insight in the importance of certain factors.

Furthermore, the results of this study show that the transition of knowledge is the factor at the actorlevel that occurred most often. Gaining more knowledge about what actors from different disciplinesneed to know from each other’s disciplines in order to collaborate effectively could be another line offuture research, which has also been recommended by Subramiam (2006). An approach to study thisaspect could be team play (Dougherty and Takacs, 2004). Dougherty and Takacs (2004) state that teamplay encourages heedful interrelating between actors in product development teams since it makes


their knowledge more vivid. It would be interesting to investigate if team play can also enable theintegration of knowledge. Heedful interrelating can also be seen as a form of creativity. Therefore,studying the relation between a team’s creativity and its ability to integrate knowledge could also be aline of research that is worth investigating (Kratzer et al., 2008).

Another interesting aspect could be studying knowledge integration in different stages of the Co-NPD process and the relation with knowledge available in the Co-NPD team (Berends et al., 2007).Leonard-Barton and Sensiper (1998) have shown that knowledge generation and integration consistsof divergent and convergent phases. Gerwin and Moffat (1997) have shown that, within adevelopment team, there must be a balance between enough specialists’ knowledge and architectural(or conceptual) knowledge. What is still unknown is if this balance changes throughout the phases ofthe Co-NPD process.

By executing more case studies, it would also be interesting to examine the interfaces of theparticular case. It is likely that the interfaces found in other cases could also be categorized in one ofthe four types of interfaces distinguished in this paper. A deeper knowledge about how thecollaborative mechanisms work could result by analyzing the collaborative mechanisms within theseinterfaces. By having extensive knowledge about the collaborative mechanisms within an interface, itis possible to create a series of best practices for knowledge integration within a certain type ofinterface.

8. Managerial implications

The main recommendation that a project manager can take from this study is that collaborativedesign and the creation of a shared understanding are not just soft aspects that cannot be influencedthrough management. In order to show how project managers and Co-NPD projects can use the resultsof this study, the following fictional conversation between an electrical engineer and an ergonomistabout the design of a new mobile phone will be used:

‘‘An electrical engineer got an assignment to design a circuit board for a mobile phone. In the listof specifications, he saw the maximum amount of space he could use for the circuit board. Fromhis experience, he knew that he was not able to put all of the components he needed in thatspace. The project leader told him that the ergonomist came up with this specification as a resultof user requirements. The electrical engineer asked the ergonomist if he could change thisrequirement. The ergonomist told him that this was the maximum amount of space theElectrical Engineer could use. The ergonomist explained his rationale based on theories ofmovements of the human body. He also used tables with measurements of the human body,point boards and mathematical formulas. The electrical engineer tried to explain to theergonomist the impossibility of getting all the functionality into such a small space. They endedthe discussion with the knowledge that there was a space problem. Yet, they were not able tonegotiate with one another in a productive way in order to solve the problem.’’

A project leader facing the problem, as described in the example, could use the results of this studyto recognize that the underlying causes of the collaboration problem occurred at the actor level. Themain problem here is that the ergonomist and the electrical engineer were both incapable oftransferring their knowledge to one another. The different languages that they used intensified thisproblem. Since a solution for such a design problem asks for an innovative solution, the interfacebetween the ergonomist and the electrical engineer could be categorized as an interface within thedevelopment team that deals with an innovative aspect.

Looking at the collaborative mechanisms of this type of interface, a project leader should be awareof the fact that this design issue could lead to problems concerning project management. In order tomanage this, a project leader should help the ergonomist and the electrical engineer transfer theirknowledge to one another. The project leader should function as a boundary spanner between the twoactors. If the transference of knowledge is made and both actors have learned some of the other’slanguage, then both the ergonomist and the electrical engineer could together solve the designproblem. Furthermore, a project leader should be flexible with the planning of this aspect. The projectleader should be aware that this design task might influence the critical path of the entire Co-NPD


project. In order to control this, a project leader should monitor, in detail, the progress and possibleproblems. These aspects plead for a project leader with knowledge about the content of the designtask.

The analysis in the example shows that a project leader could use the results of this study tomanage the collaborative processes of the development team. However, this step does not yet providethe project leader with a monitoring tool. The question raised how a project leader could recognizeand distill the collaborative mechanisms within his development team. A project leader of a technicalsubsystem in our case study gave the answer to this question. The project leader opted to implementthe learning history method in their Co-NPD projects. The project leader thought it would be apowerful tool for detecting collaboration problems. The project leader suggested that an externalresearcher or consultant should create the learning histories of the particular Co-NPD project.

Although we think that this could be the optimal solution, it seems that it is not the most applicablesolution. We think that a project leader could also learn to use the learning history method during theCo-NPD process. It should become a permanent aspect of management tasks, just as the regularproject management tools for planning and monitoring are. A project manager should actively observethe team during their regular meetings by taking notes about the most important issues concerningcommunication about the design content. During the regular face-to-face meeting with the separateactors, which are now mostly about planning and monitoring issues and design problems or changes,the project leader could use the notes as input for discussing the collaborative aspects with the actors.This form of storytelling will provide the project leader with knowledge about the collaborativeaspects of the design process. A project leader should also learn to distill the barriers and enablers fromthese conversations. Depending on the kind of barriers and enablers found, the project leader can thendecide whether to intervene or not.

Acknowledgement

We would like to thank Dr. Andy Dong for his useful comments on an earlier version of this paper.

References

Adams, M.E., Day, S.D., Dougherty, D., 1998. Enhancing new product development performance: an organizational perspective.Journal of Product Innovation Management 15 (5), 403–422.

Ancona, D.G., Caldwell, D.F., 1992. Bridging the boundary: external activity and performance in organizational teams.Administrative Science Quarterly 37, 634–665.

Berends, H., Vanhaverbeke, W., Kirschbaum, R., 2007. Knowledge management challenges in new business development: casestudy observation. Journal of Engineering and Technology Management 24 (4), 314–328.

Bond, A.H., Ricci, R.J., 1992. Cooperation in aircraft design. Research in Engineering Design 4 (2), 115–130.Bucciarelli, L.L., 1996. Designing Engineers. MIT Press, Cambridge, MA.Bucciarelli, L.L., 2002. Between thought and object in engineering design. Design Studies 23 (3), 219–231.Cross, N., 1990. The nature and nurture of design ability. Design Studies 11 (3), 127–140.Cummings, J.F., Teng, B.S., 2003. Transferring R&D knowledge: the key factors affecting knowledge transfer success. Journal of

Engineering and Technology Management 20 (1–2), 39–68.Dong, A., 2005. The latent semantic approach to studying development team communication. Design Studies 26 (5), 445–461.Dougherty, D., 1992. Interpretive barriers to successful product innovation in large firms. Organizational Science 3 (2), 179–202.Dougherty, D., Takacs, C.H., 2004. Team play: heedful interrelating as the boundary for innovation. Long Range Planning 37 (6),

569–590.Edmondson, A.C., Nembhard, I.M., 2009. Product development and learning in project teams: the challenges are the benefits.

Journal of Product Innovation Management 26 (2), 123–138.Emmanuelides, P.A., 1993. Towards an integrative framework of performance in product development projects. Journal of

Engineering and Technology Management 10 (4), 363–392.Garcia, R., Calantone, R., 2002. A critical look at technological innovation typology and innovativeness terminology: a literature

review. Journal of Product Innovation Management 19 (2), 110–132.Gerwin, D., Moffat, L., 1997. Authorizing processes changing team autonomy during new product development. Journal of

Engineering and Technology Management 14 (2–3), 291–313.Granstrand, O., Bohlin, E., Oskarsson, C., Sjoberg, N., 1992. External technology acquisition in large multi-technology corpora-

tions. R&D Management 22 (2), 111–133.Griffin, A., Hauser, J.R., 1996. Integrating R&D and marketing: a review and analysis of the literature. Journal of Product

Innovation Management 13 (3), 191–215.Hage, J., Jordan, G., Mote, J., Whitestone, Y., 2008. Designing and facilitating collaboration in R&D: a case study. Journal of

Engineering and Technology Management 25 (4), 256–268.


Hill, A., Song, S., Dong, A., Agogino, A., 2001. Identifying shared understanding in design using document analysis. In:Proceedings of the 13th International Conference on Design Theory and Methodology Design Engineering TechnicalConferences, Pittsburgh, Pennsylvania.

Hoegl, M., Gemuenden, H.G., 2001. Teamwork quality and the success of innovative projects: a theoretical concept andempirical evidence. Organization Science 12 (4), 435–449.

Hoegl, M., Weinkauf, K., Gemuenden, H.G., 2004. Interteam coordination, project commitment and teamwork in multiteam R&Dprojects: a longitudinal study. Organization Science 15 (1), 38–55.

Jassawalla, A.R., Sashittal, H.C., 1998. An examination of collaboration in high-technology new product development processes.Journal of Product Innovation Management 15 (3), 237–254.

Kahn, K.B., 1996. Interdepartmental integration: a definition with implications for product development performance. Journalof Product Innovation Management 13 (2), 137–151.

Kahn, K.B., 2001. Market orientation, interdepartmental integration, and product development performance. Journal of ProductInnovation Management 18 (5), 314–323.

Katz, R, Tushman, M., 1981. An investigation into the managerial roles and career paths of gatekeepers and project supervisorsin a major R&D facility. R&D Management 11 (3), 103–110.

Kleiner, A., Roth, G., 1996. Field Manual for a Learning Historian, MIT-COL and Reflection Learning Associates, Version 4.0. .Kleinsmann, M., 2006. Understanding Collaborative Design. Ph.D. thesis. Delft University of Technology, Delft.Kleinsmann, M., Valkenburg, R., 2008. Barriers and enablers for creating shared understanding in co-design projects. Design

Studies 29 (4), 369–386.Kratzer, J., 2000. Communication and Performance: An Empirical Study in Innovation Teams. Ph.D. thesis. Groningen.Kratzer, J., Leenders, R.Th.A.J., Van Engelen, J.M.L., 2008. The social structure of leadership and creativity in engineering teams:

an empirical analysis. Journal of Engineering and Technology Management 25, 269–286.Leenders, R.Th.A.J., Van Engelen, J.M.L., Kratzer, J., 2007. Systematic design methods and creative performance of new product

teams: do they contradict or complement each other? Journal of Product Innovation Management 24 (2), 166–179.Leonard-Barton, D., Sensiper, S., 1998. The role of tacit knowledge in group innovation. California Management Review 40 (3),

112–132.Lysonski, S., Woodside, A.G., 1989. boundary role spanning behavior, conflicts and performance of industrial managers. Journal

of Product Innovation Management 6 (3), 169–184.Miles, M.B., Huberman, A.M., 1994. Qualitative Data Analysis: An Expanded Sourcebook. Sage Publications.Moenaert, R.K., Souder, W.E., 1990. An information transfer model for integrating marketing and R&D personnel in new product

development projects. Journal of Product Innovation Management 7 (2), 91–107.Moenaert, R.K., Caeldries, F., Lievens, A., Wauters, E., 2000. Communication flows in international product innovation teams.

Journal of Product Innovation Management 17 (5), 360–377.Mohammed, S., Dumville, B.C., 2001. Team mental models in a team knowledge framework: expanding theory and measure-

ment across disciplinary boundaries. Journal of Organizational Behavior 22 (2), 89–106.Mohrman, S.A., Finegold, D., Mohrman Jr., A.M., 2003. An empirical model of the organization knowledge system in new product

development firms. Journal of Engineering and Technology Management 20 (1–2), 7–38.Roth, G., Kleiner, A., 2000. Car Launch—The Human Side of Managing Change. Oxford University Press, New York.Subramiam, M., 2006. Integrating cross-border knowledge for transnational new product development. Journal of Product

Innovation Management 23 (6), 541–555.Song, S., Dong, A., Agogino, A.M., 2003. Time variation of design ‘‘story telling’’ in engineering development teams. In:

Proceedings of the International Conference on Engineering Design, ICED 03, Stockholm.Sonnenwald, D.H., 1996. Communication roles that support collaboration during the design process. Design Studies 17 (3), 277–

301.Swink, M., 2000. Technological innovativeness as a moderator of new product design integration and top management support.

Journal of Product Innovation Management 17 (3), 208–220.Tessarolo, P., 2007. Is integration enough for fast product development? An empirical investigation of the contextual effects of

product vision. Journal of Product Innovation Management 24 (1), 69–82.Valkenburg, R., 2000. The Reflective Practice in Product Development teams. Ph.D. thesis. Delft University of Technology, Delft.Valkenburg, R., Dorst, K., 1998. The reflective practice of development teams. Design Studies 19 (3), 249–271.Veryzer, R.W., 2005. The roles of marketing and industrial design in discontinuous new product development. Journal of Product

Innovation Management 22 (1), 22–41.Weick, K.E., Roberts, K.H., 1993. Collective mind in organizations: heedful interrelating on flight decks. Administrative Science

Quarterly 38, 357–381.Wegner, D.M., 1987. Transactive memory: a comtemporary analysis of the group mind. In: Mullen, B., Goethals, G.R. (Eds.),

Theories of Group Behavior. Springer-Verlag, New York, pp. 185–208.


Download - Understanding the complexity of knowledge integration in collaborative new product development teams: A case study

Top Related