Task partitioning in new product development teams: A knowledge and learning perspective

Task partitioning in new product development teams:

A knowledge and learning perspective

Stephen Chen *

Australian National University, National Graduate School of Management,

Sir Roland White Building, McCoy Circuit, Canberra ACT 200, Australia

Available online 8 November 2005

Abstract

R&D alliances and outsourcing elements of the new product development process are now commonplace

practices among many firms. However, little previous work has examined how these organizational choices

influence project knowledge and learning. Based on a comparison of three new product development

projects in the software industry, this paper examines how task partitioning in the project influences learning

and knowledge development within the firm. The paper suggests that internal development projects

encourage synthetic learning and development of architectural and tacit knowledge; in contrast, outsourcing

and joint ventures encourage analytic learning and development of component and explicit knowledge.

# 2005 Elsevier B.V. All rights reserved.

JEL classification: M10

Keywords: Outsourcing; Alliances; New product development; Knowledge transfer; Analysis; Synthesis; Tacit

knowledge

1. Introduction

Firms are increasingly using organizational forms such as outsourcing and alliances for

product development in addition to the conventional approach of developing the product entirely

in-house. Some factors driving this increase that have previously been suggested include

discontinuous technological change, increasing cost of R&D, globalization and lower cost of

production in less-developed countries (Campione, 2003; Kakabadse and Kakabadse, 2000;

Lambe and Spekman, 1997). Most research to date has focused on the economic benefits and

risks of such arrangements (e.g. Williamson, 1975; Pfeffer and Salancik, 1978; Provan, 1983;

Jarillo, 1988). This paper focuses on the learning implications of such arrangements.

www.elsevier.com/locate/jengtecman

J. Eng. Technol. Manage. 22 (2005) 291–314

* Tel.: +61 2 6125 9830; fax: +61 2 6125 4895.

E-mail address: [email protected].

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

doi:10.1016/j.jengtecman.2005.09.003

As Hitt et al. (2000) note, ‘in contrast, the learning and process issues related to innovation

have received scant scholarly attention.’ This is surprising since learning lies at the heart of

much technological innovation activities (e.g. Carayannis and Alexander, 2002; Akgun et al.,

2002; Mohrman et al., 2003; Molleman and Broekhuis, 2003; Polley and van de Ven, 1996). In

particular, little research has been done specifically on how the project organization facilitates

or hinders different types of learning in the product development context, although a few

studies suggest that there may be a link. For example, Kazanjian et al. (2000) has shown a link

between project organizational structure and the technological learning and creativity that

occurs within product development projects. Meanwhile Takeishi (2002) examined

outsourcing in product development projects in the automobile industry in Japan and found

that the type of knowledge gained by the firm (architectural versus component specific) varied

according to the type of technology involved and the organizational mechanisms used to

transfer knowledge. Therefore, the research question that this paper examines is ‘how does the

project organization influence the learning process and the different types of knowledge that

are developed?’

I begin by reviewing some of the literature on different organizational approaches to new

product development and team learning. I then review different typologies of learning and

knowledge and discuss why different project organizational architectures may be expected to

lead to different learning and knowledge development. The following sections then outline the

key findings of a study that compares the learning process and knowledge developed in three

companies that adopted different organizational arrangements for new product development. I

end by discussing the implications of these findings for technology management theory and

practice in innovation projects.

2. Literature review

2.1. Organizing for new product development

Several different ways of organizing for acquisition and exploitation of technology are

documented in the literature. For example, Granstand et al. (1992) distinguish five forms

based on different types of legal contracts: internal R&D, acquisition of innovative firms,

joint ventures, technology purchasing, technology scanning (legal and illegal acquisition of

external knowledge without direct purchase). Monaert and Deschoolmeester (1990) list six

forms of organization for R&D based on a review of existing literature: internal development,

contract research, intercompany cooperation, joint venture, acquisition, purchase of

technology.

Many contingency factors have been identified that may influence the choice of project

organization. Task-related factors include task difficulty, interdependence and resource flows

(Olson et al., 1995), activity uncertainty and complexity (Levitt et al., 1999), speed of innovation

(Kessler and Chakrabarti, 1996) and time-to-market (Datar et al., 1997). Project-related factors

include project management power, vision and skill (Brown and Eisenhardt, 1995).

Organizational factors include the relationship of the project to the organization (Dougherty,

2001) and the core competence of the organization (Quinn and Hilmer, 1994).

Within the literature, most studies have been positioned within two main theoretical

perspectives: transaction cost and resource dependence. The transaction cost perspective

pioneered by Williamson (1975) focuses on the transaction costs of various organizational

arrangements. According to the transaction cost perspective, the choice between performing

S. Chen / J. Eng. Technol. Manage. 22 (2005) 291–314292

activities in-house or outsourcing depends on the balance between cost savings to be gained from

outsourcing and additional transaction costs involved (Robertson and Gatignon, 1998). Potential

benefits of outsourcing new product development include savings in production costs (e.g. Vining

and Globerman, 1999) and reduced development time (e.g. Clark and Fujimoto, 1991). On the

other hand, risks associated with such arrangements might be slower innovation, opportunism,

loss of early mover advantages or other strategic considerations (Kessler et al., 2000; Provan and

Skinner, 1989).

The second perspective is the resource-dependence perspective pioneered by Pfeffer and

Salancik (1978), which focuses on the power and influence relationships between the various

actors. According to the resource-dependence perspective, organizations typically attempt to

reduce uncertainty by increasing coordination and mutual control over each other’s resources

through interorganizational relationships (Jarillo, 1988). The rationale for forms such as alliances

and joint ventures is, therefore, to ensure stability in the supply of essential resources or to ensure

stability in demand for products or services.

A third perspective that has been gaining ground in recent years focuses on the learning

benefits of different organizational forms (Hitt et al., 2000; Schill et al., 1994). This assumes a

different primary strategic objective or motivation for organizational choices.Many researchers

have noted that alliances with customers can be a valuable source of knowledge in innovation

projects (e.g. Von Hippel, 1986; Lind and Zmud, 1991) while other researchers (e.g. Kogut,

1988; Hamel, 1991; Inkpen and Crossan, 1995; Larsson et al., 1998; Kogut, 1988) have

examined how alliances and joint ventures can provide a platform for more general

organizational learning by providing access to partners’ skills and capabilities, particularly tacit

knowledge.

2.2. The effect of project structure on learning

Despite this interest in learning in new product development projects, little research has been

done that examines specifically how different project structures influence learning and the

knowledge developed. Prima facie it would seem reasonable to expect that different structures

would result in different learning outcomes. The information processing perspective on

organizations (Tushman and Nadler, 1978) assumes that the project organizational structure

influences the information and communication flows that occur within a project. In turn it seems

reasonable to expect that differences in patterns of information processing within projects would

affect learning and knowledge developed.

Structural features that have been identified as key in facilitating information processing in

innovation projects include lateral organizational linkages (e.g. Sicotte and Langley, 2000; Gupta

and Govindarajan, 2000), boundary spanning personnel (Conway, 1995; Tushman, 1977; Ianisiti,

1995; Nobel and Birkinshaw, 1998), social networks within the organization (Hansen, 2002;

Tsai, 2001; Reagans and Zuckerman, 2001), the communication media used (Gales et al., 1992)

and the patterns of exchange and communications which team members engage in (Cooper,

1986; Purser et al., 1992; Eisenhardt and Tabrizi, 1995; Griffin and Hauser, 1992; Hoegl and

Gemuenden, 2001). Extra-organizational structural features include information and commu-

nication systems that facilitate collaboration with users (Gales and Mansour-Cole, 1995) or

suppliers (Handfield et al., 1999; Takeishi, 2001).

Most previous research has focused on the performance benefits of different structures, the

underlying premise being that communication among project team members and with outsiders

stimulates the performance of development teams (Brown and Eisenhardt, 1995; Von Hippel,

S. Chen / J. Eng. Technol. Manage. 22 (2005) 291–314 293

1990). Less research has been done that examines the specific outcomes in terms of learning and

knowledge development. However, there are some indications that information processing also

has a secondary effect on the learning that occurs within the project. Galbraith (1977) described

how formal management information systems have a greater capacity to provide useful data to

managers than written rules and procedures. Daft and Lengel (1986) showed that face-to-face

interaction has the capacity to provide much richer information than media such as written text.

For example, face-to-face interaction provides immediate feedback and multiple cues via body

language and tone of voice; on the other hand, a written document provided fewer cues and

restricts feedback. Previous research, therefore, suggests that project structures influence the

type of information processing that occurs within projects and consequently project

performance.

Less research has been done that examines how it influences the type of learning. However,

there are some indications that it may do. Specifically in the context of product development,

Kazanjian et al. (2000) found that project organizational architectures influence the creative

behaviors of team members. For instance, the greater the cross-functional interdependence

within a multi-functional team, the more individuals will engage in the creative process. On the

other hand, the greater the across-team interdependencies within a project and the greater the

system-level interdependency, the less individuals working on multifunctional teams will engage

in the creative process.

2.3. Typologies of learning

Knowledge and learning can be classified in many different ways but some of the key

dimensions that have previously been examined are:

� individual versus collective knowledge;

� explicit versus tacit knowledge;

� architectural versus component knowledge;

� analytic versus synthetic learning (Table 1).

Distinguishing the type of knowledge in a project is important because different types of

knowledge have been shown to vary in their characteristics such as ease of transfer.

Individual knowledge is knowledge that can be wholly understood and retained by an

individual. Collective knowledge is knowledge that is shared by a collective such as a team, an

organization, an industry or a society (Spender, 1996). It is also assumed in the organizational

learning literature that individual learning is necessary but insufficient to produce organizational

learning. It is also more than the sum of learning by individual members of the organization. For

organizational learning to occur, knowledge must be accessible to others beyond individual

learners and it must be subject to application, change and adaptation by others in the

organization.

A second key distinction often made in the knowledge management literature is that between

explicit knowledge and tacit knowledge. Explicit knowledge is that which can be readily stated

and codified; tacit knowledge by contrast which is difficult to state and can only be gained by

experience or ‘learning by doing’ (Reed and DeFillippi, 1990). Tacitness assumes that

individuals know more than they can tell. As Polanyi (1966) stated, ‘‘the aim of a skillful

performance is achieved by the observance of a set of rules which are not known as such to the

person following them’’ (p. 49). Tacit knowledge is often context specific and has a ‘personal

quality’ (Nonaka and Takeuchi, 1995).


The linguistics literature also presents another perspective on why knowledge may be tacit. As

Sperber and Wilson (2002) point out, another reason why knowledge may be tacit is that it does

not need to be verbalized. An example is the apparently simple sentence such as ‘The priest

married my sister’. In a Roman Catholic context (where priests are not allowed to marry) this is

relatively unambiguous and can normally only be interpreted as ‘The priest carried out a

ceremony through which my sister ended up married to some other person’. However, in a Greek

Orthodox context (in which priests are allowed to have wives) this sentence might need

elaboration as it could also mean ‘The priest got married to my sister’. Similarly given their

mutual understanding of certain terms and concepts, two subject matter experts in conversation

do not need to fully explain the meanings each time (Hymes, 1972). However, in conversing with

a layman, they may find it necessary to explain the meanings of some terms that are not

commonly understood.

More recently other researchers have drawn even finer distinctions between different types of

tacit knowledge. For example, Castillo (2002) distinguishes four types of tacit knowledge:

nonepistle knowledge or knowledge that is unconscious, socio-cultural knowledge or knowledge

that is part of the socio-cultural system, semantic knowledge or knowledge that does not need to

be expressed, and sagacious knowledge that is possessed by an expert.

A distinction that is particularly significant in the product innovation context is the distinction

between component-specific knowledge and ‘‘architectural’’ knowledge (Henderson and Clark,

1990). Component knowledge is knowledge that concerns a particular aspect of an organization’s

product, process or operation. Architectural knowledge, on the other hand, relates to the various

ways in which the components are integrated and linked together into a complete system. Thus,

component knowledge can exist independently whereas architectural knowledge is embedded in

a larger system and cannot be decomposed into independent parts (Garud and Nayyar, 1994).

Many complex technologies can be described as a form of architectural innovation (Singh, 1997).

Component knowledge can be held either by the individual or by a collective and can be either

tacit or explicit. However, because architectural knowledge is held throughout the whole

organization, it is collective in nature. Moreover, it is difficult for any one person to understand

(or hold) all the architectural knowledge, thus making such knowledge tacit by nature (Matusik

and Hill, 1998).

A distinction that is often made between different methods of knowledge acquisition is that

between analysis and synthesis. Although the distinction dates back to classical Greek

philosophy, it has also been used by more modern thinkers, for example, Leibniz (1645–1715)

and Newton (1642–1712), in distinguishing different processes for generating knowledge. In

general analysis is defined as the process by which a problem or body of knowledge is broken

down into parts. Synthesis is defined as the opposite process in which separate elements or pieces

of knowledge are combined to form a coherent whole (Ritchey, 1991). Synthesis is of particular


Table 1

Dimensions of knowledge

Extent of knowledge

sharing

Nature/source of

knowledge

Process of

knowledge acquisition

Purpose/subject

of knowledge

Related level of

product/process

Individual Codified Analytic What? Component

Team Semantic Synthetic How? Architectural

Organization Expert Why?

Industry Unconscious Who?

Society Society/culture

significance in systemic products where several different technologies need to be combined

(Kodama, 1992; Millar et al., 1997).

There is substantial evidence that suggests that these different dimensions of knowledge

and learning have different organizational or managerial implications. For instance, the

tacitness of knowledge has been shown to affect the ease of knowledge transfer within and

between organizations. It is generally assumed that tacit knowledge is more difficult to imitate

or transfer compared with explicit (Kogut and Zander, 1992). One reason may be that both the

knowledge provider and recipient must share the same ‘‘codebook’’ or common knowledge

base in order to make sense of the knowledge transferred (Cowan et al., 2000). Other reasons

are that the knowledge may be ‘‘socially embedded’’ in organizational routines (Inkpen and

Dinur, 1998) or as implicitly held assumptions in a particular group (Kuwada, 1998).

Architectural knowledge is presumed to be more difficult to recognize and transfer than

component knowledge (Henderson and Clark, 1990). Because the knowledge is often specific

to particular organizational arrangements, architectural knowledge is often neglected in

innovation. Problems only surface when attempts are made to replicate the process in a

different organization.

A question that naturally arises but one that has been less investigated is does the reverse

happen? Does organizational structure influence the type of knowledge developed? There is

some evidence that the type of knowledge developed in new product development is related to

how the project is organized (Lynn and Akgun, 2000). Specifically with respect to outsourcing

arrangements in R&D teams, Takeishi (2002) examined product development projects in the

automobile industry in Japan and found that the type of knowledge gained by the firm

(architectural versus component specific) varied according to the type of technology involved

and the organizational mechanisms used to transfer knowledge. Component knowledge was

developed in outsourcing arrangements but development of architectural knowledge required

internal projects. However, his research did not examine in detail different types of organization

or other types of knowledge. The research question, therefore, that this paper examines is: ‘how

does the project organization influence the learning process and the different types of knowledge

that are developed?’

3. Methodology

As the nature of the questions was exploratory and required examination of intra-firm and

intra-project processes, I decided to adopt an inductive, comparative case study approach (Yin,

1994; Eisenhardt, 1989). This allowed new factors to be examined as they emerged while

allowing patterns to be compared and contrasted across cases.

3.1. The companies and projects

In order to compare the effects of project organization on learning I negotiated access to three

new product development projects where learning was a key company objective. In order to

control for task and project attributes, I selected projects that were developing similar products

(software) and projects that were related to but at the same time a departure from the company’s

normal product range and projects that were of a similar size and duration (4–6 people, 6 months–

1 year in length).

Details of the companies and projects selected are shown in Table 2. (Names have been

disguised at the request of the companies.) ‘Global’ is a major international supplier of computer


hardware and software. The project examined involved a joint venture with a major information

provider ‘Info’ to develop a networked communications system. ‘Elite’ is a major book and

journal publisher. The project examined involved the development of a new software title based

on one of its existing publications, in which software development was outsourced to ‘Star’, a

software company. ‘Wild’ is a small entertainment and educational software development firm.

The project examined was the development of a new educational software title.

3.2. Data collection

All projects had already started when I first made contact so I was unable to observe the initial

set up process. However, none had completed so I was able to follow the progress of each project

team over time as the project progressed and also some time after completion. There were three

sources of data: (1) interviews with team members, (2) secondary sources such as written reports

and (3) personal observations (Table 3).

3.2.1. Interviews

The primary source of data came from interviews conducted with key individuals in the

project team. My initial contact in each company was with the manager of the project who then

introduced me to other teammembers. I interviewed all keymembers of the project teamwith the

exception of the ‘Wild’ project, where two of the original teammembers had already moved on to

other projects.


Table 2

The companies and projects

Company Main

activity

Product being

developed

Organization

size

Team size Project

length

Global Computer systems Network communications

software

ca. 350,000 6 (excluding team

in partner company)

1 year

Elite Publishing Educational software ca. 40,000 6 (excluding

contractors)

2 years

Wild Entertainment

software

Educational software 20 5 6 months

Table 3

Data sources

Company Informants Secondary sources consulted Site visits

Global Department head Press articles 3

Project leader Company annual report

Interface programmers (2) Project plans

Network programmers (2) Program specifications

Elite Department head Press articles 3

Project leader Company annual report

Book editors (2) Project proposal

Technical specialist Project progress reports

Marketing executive

Wild Project leader Press articles 3

Programmer Product specification

The interviews were semi-structured to focus the discussions on key topic areas while

allowing the interviewees freedom to tell their story in their own words. In the interviews with

project managers, they were asked general questions about the project such as:

� Project aims.

� Project task allocation.

� Project management.

� Significant events throughout the project.

� Project outcomes.

Thequestions in the interviewswithother teammembers focusedmoreon individual experiences

suchas theirowneducationalandworkexperience, theproblems theyhadpersonallyencounteredon

the project and personal learning outcomes. (See Appendix A for the interview guide.)

However, following the methods of inductive research, the prepared questions were

supplemented with other ones that seemed fruitful to pursue in the light of information given.

Interviewees were also encouraged to provide any other information that they thought was

relevant. Interviews typically lasted for 90 min per person each time for a total of approximately

45 h of interviews in the three companies. Interviews were recorded on tape before being

transcribed for analysis. Some follow-up questions were also made by telephone in a couple of

cases to clarify answers to some questions.

3.2.2. Secondary sources

The interview data was supplemented with data from secondary sources such as project

reports, company annual reports, company brochures and press articles on the company, product,

market and competitors.

3.2.3. Observation

Lastly, some information was gathered informally from personal observations made during

visits to the companies. For example, the layout of the office and snippets of conversations

between team members provided useful background clues about the company and working

practices in each team.

3.3. Data analysis

As most data collected was qualitative and varied from case to case it was not possible or

considered useful to quantify learning and knowledge developed or to conduct any statistical

analysis. However, it was possible to identify different types of learning and knowledge in the

projects. The analytic approach adopted was a mix of induction and deduction (Eisenhardt,

1989). Some key factors identified from previous literature, such as team organization and team

roles were compared across the cases. At the same time other factors and themes that emerged

from one case, such as the information flow, were highlighted and corroborated across all the

cases. The process was iterative with several cycles of analysis being conducted as each

potentially relevant factor emerged from the analysis.

To verify emerging patterns, the interviews were examined independently by another

researcher and cross-checked with the interviewees. Firstly, an ‘‘analytic chronology’’

(Pettigrew, 1990) was prepared for each case, laying out the story across different levels of

analysis. These helped to clarify sequences of events, suggest causal linkages and suggest early


analytical themes. Drafts were distributed to each interviewee to check for accuracy and

completeness. This provided some control against misunderstanding and misinterpretation in the

reports. It also provided a control for the general reliability and consistency of individual

accounts. The second step was to rewrite the cases with a more explicit attempt to bring out

conceptual themes within each case. The final step was to present general themes using evidence

across all cases.

4. Findings

4.1. Comparison of task partitioning/project organization

Asoutlinedabove, the threeprojectsweredeliberatelychosen tobeas similar aspossible in terms

of attributes such as the technology involved, project size and project time-frame. As discussed

below, although the projects each had multiple objectives, they also all included exploitation of

existing skills and learning about the technology among their stated primary objectives. However,

they differed considerably in their organization, culture and work practices (Fig. 1).

4.1.1. Joint venture example: Global

The project at ‘‘Global’’ aimed to combine television, PC and satellite distribution

technologies. As one of the leading companies in the sector, Global had several projects in related

areas. The concept grew out of an existing satellite transmission service and initially the aim was

to generate additional revenue from the satellite service. News and information was identified as

an ideal feed for this sort of service. The involvement of Global’s partner, Info, came about by

chance. Info already had a relationship with Global providing corporate information services and

heard of another project that another unit in Global was developing with a competitor. When this

other project ran into problems and was cancelled, Info approached Global to develop the idea.

Both companies saw the project as only the start of one of a range of applications of digital

satellite technology. The aims of the project were both to learn more about the technology and

also to educate customers in the potential of the technology. ‘‘We think it will help people

understand what this technology is capable of achieving.’’


Fig. 1. Task partitioning in the projects.

As the main objective of the project was to make use of the two companies’ complementary

skills and assets and as each party wanted to establish a lead in their respective industries, a joint

venture was considered to be the best organizational arrangement that satisfied both parties. Each

party agreed to bear their own costs for the project since much of the work would be done

anyway. Once the project was approved Global’s software division was approached to write the

code.

One of the distinguishing characteristics of the approach to product development adopted in

‘‘Global’’ was the adherence to the principle of modularization (Garud and Kuramaswamy,

1996), extending not only to product design but also to the organization of activities and

personnel. According to the project manager, the system was deliberately designed according

to modular design principles in such a way that each module could operate independently,

allowing modules to be interchanged and reused in other systems. Thus, the network software

module could operate independently of the interface module, which in turn could operate

independently of the underlying processing and transmission modules. Within each program,

the code was further subdivided into discrete modules making it easy to add or change

functions.

Another factor in the choice of modular product design was the geographic spread of specialist

teams. The programmers with special network expertise within Global were located in a different

country from the programmers with expertise in the user interface. Modularizing the product

design reduced the coordination costs between teams working on each module and allowed each

programmer to focus on his area of expertise. Thus, a team consisting of two programmers

worked on the user interface software in one location while another team of two specialist

network software programmers in another location worked on developing the software to

transmit the data over the network. Providing the information in the product was left to the joint

venture partner. The team leader and his assistant coordinated the activities of the two subteams

and also coordinated activities with a counterpart in Info.

This organization allowed the applications software and network groups to work

independently and in parallel. As far as the applications programmers were concerned, the

network was just another transport medium and as far as the network team was concerned it was

just another series of data. As one of the programmers explained, ‘‘That’s part and parcel of

Global’s way of managing things. I know nothing about software, I’m not an application

developer, I’m transport and infrastructure. The two of us work in harmony through separate

groups. He has his expertise; I have my expertise. There is no way that if we had both sets of

expertise under one manager, we would get any more productivity from us because my skills

would be diluted.’’

4.1.2. Outsourcing example: Elite

As a major international publisher Elite had hundreds of book titles in development and a

dozen or so electronic titles so one of the aims was to exploit existing skills and resources.

However, the project examined was at the time the largest that Elite had undertaken in electronic

publications, so there was also an element of exploration in learning about the process of

producing large electronic titles.

In Elite, the task partitioning was quite different from that in Global. Within Elite, electronic

titles were the responsibility of a specialist electronic publications department. The information

content in the software package was sourced from another department within Elite responsible

for book publications, the software was outsourced to a specialist software house and various

subject experts, authors and potential users were employed on a freelance basis to review, write


text and test the product. Overall coordination of the project was the responsibility of a manager

in the electronic publications department.

When asked why the company chose to outsource as opposed to in-house development, two

reasons cited were access to specialist skills and control of the process. The company did not

consider software development to be their core competence and they believed that by using

outside developers they were able to stay at the leading edge. As the project manager explained,

‘‘It’s not a technical activity as we see it . . .We believe that it is important to exploit the skills of

the book people to make the electronic product something special. By using developers who are

also working for other people, you get state of the art of programming whereas if we have people

in house they might stagnate.’’

Another factor was control over the process. As one book editor described it: ‘‘The way we

produce a book is terribly controlled. We commission an author rather than an author sends to us.

They might send to us initially but we would really develop hand in hand with them over a 2-year

period roughly and there would be another year period when we are developing the look of the

book, the design, the illustrations . . . The whole cycle is a 3–4 year process . . . If we cannot

control it, we do not do it.’’ The same approach was carried over to electronic titles.

Interestingly, contrary to what might be expected from a transaction cost perspective, the view

within the electronic publications department was that it had more control over an outsourced

project than an internal one. ‘‘With people outside who are contractually bound to deliver and to

do things on schedule and to a defined quality you have a much fiercer handle to turn when things

go wrong. If it’s your own colleagues who are delivering it’s a bit more difficult.’’ (Subsequent

interviews with other members of the organization suggested that the area of electronic

publications was a ‘hot potato’ to use one member’s description and that there were various

struggles for control within the organization, perhaps suggesting why outsourcing was

considered to be less risky and costly than an internal venture.)

Following the publishing model for books, the project was planned in great detail throughout

and a timetable was agreed with the software developers, specifying dates when certain items had

to be delivered. The first 3 months were spent simply specifying the structure and content of the

software with the help of two experts. Other consultants were brought in to check the accuracy of

the content. This was felt to be important because ‘‘What we get out of them is a product which

will enhance our datasets and material and not one which just shows off their search engine. We

believe that the data is King. Why people buy our books is because of the content and we want

any dataset to be exploited to the best advantage.’’ Tasks carried out by other team members

included preparing the text, photographs and video clips for the software. The existing text,

although it did not need to be amended, also had to be indexed and tagged. The product contained

over 2000 photographs and video clips and one of the major tasks was finding and cataloguing the

various items. Another major task was the design of the search engine and considerable effort was

expended to ensure that the software would be easy to use. Examples of issues that had to be

considered included, for example, whether or not the software should recognize and

automatically correct users’ spelling mistakes.

In accordance with the general policy in Elite, members of the Elite team were in regular

contact with the software developers at all stages of the project. Regular progress meetings were

scheduled every 2 weeks in addition to daily contact by telephone. Once again this tight control

was seen as essential to ensure the high quality of product expected by Elite. This included an

extended testing phase. As in other Elite projects, prior to release in the market, the product was

extensively tested by both subject experts and by everyday users. The first test was carried out

once the prototype was complete. Further trials were conducted as the product developed and


once it was completed. Feedback from these trials was passed back both to members of the Elite

team. On the basis of these reports, changes to the specification were then reported to the software

developers.

4.1.3. Internal development example: Wild

In the case of ‘‘Wild’’ the aim was initially to produce a title that would sell well and would be

profitable. However, as the project manager stated, with any new title there is learning so that was

also an implicit aim. The founder was an ex-rock musician as well as a software programmer and

the philosophy of the company was to look for opportunities to creatively combine software, art

and music.

The company rarely outsourced work, apart frommundanework such as referencing. In-house

projects were considered to be the best way to make use of the unique mix of creative talent on

which the company prided itself. The project team examined was typical and comprised a

producer, a project manager, a graphic designer and a software engineer. Although all had

experience in their own fields, this project was the first in which they had developed a product

together with people from other disciplines. Project tasks and responsibilities were allocated in

accordance with their specialist expertise. Thus, the producer was responsible for relations with

company management and the client, the project manager monitored progress and ensured

necessary resources were available, the software engineer worked on the software while the

graphic designer worked on the look and feel of the software and packaging. In keeping with the

culture in the rest of the company, although formal meetings did occur, the approach taken was to

rely heavily on informal mechanisms for coordination. All team members worked day to day in

close proximity and so issues were discussed as and when they arose. As the project manager

explained: ‘‘It’s a really young company and we do not have very many rules so we are a bit more

ad hoc, very design-led, very art-led.’’

4.2. Communication

As a first step to understanding how the differing project team organizations affected

communication, knowledge exploitation and the learning process, the pattern of knowledge and

information flows within the projects was compared. Fig. 2 shows the pattern of knowledge flows

between individuals or units in the three projects with dominant channels in bold.

In the Global project, the process adopted was described as being that in a typical

programming textbook:

� a specification was prepared by the project manager;

� the specification was handed to the programmers;

� on completion of the programming, the programs were handed over to the project manager for

testing;

� on completion of the testing, the faults were passed to the programmer for correction.

There was very little direct communication between teams. For example, in the view of the

application programmers: ‘‘The satellite service was just a way of getting files from A to B. As

long as we get a command we can type in to get from A to B, we don’t really care what’s in

between there, if it’s a satellite, infrared link, ISDN, you name it. As long as we can put in a file

and get the same file out the other end, we pretty much left the satellite development team to

themselves. It was just a service we were using rather than tightly coupled into the system.’’ This


reflected the company’s policy to develop ‘‘centers of excellence’’ in particular areas. Similarly,

although there was contact with users at all stages, this consultation was limited to how it affected

transmission. As the programmers commented: ‘‘We do not audit it (sic—the information

transmitted by the user). All we do it move it from one place to many.’’

The projects also differed in the means of communication between team members (Table 4).

In Global the two main means of communication were email and verbal reports to the project

manager at designated points in the project (usually when a module was complete or when the

project manager was visiting the team). Partly this was due to the fact that the two subteams

working on the software were in different locations. Not surprisingly the knowledge appeared to

be largely explicit. Team members were required to keep detailed written records of all

programming decisions and changes and typical communications to the project manager reported

explicitly what modules had been completed, what changes had been made to code, outcomes of

tests, bugs noticed and changes made. According to the team leader, the well-documented test

plans were seen as one way of recording learning: ‘‘Now when we rewrite things, say we change

one of the pages, we can just pull out the test case document and depending on howmany changes

have been done and who has coded it, you can decide how much testing you need to do. So every


Fig. 2. Intra-project knowledge flows.

Table 4

Content of intra-project communications (as reported by project manager)

Project Form of communication Frequency of communication Content of communication

Global Mainly email, verbal

reports to project manager

At critical points,

project deadlines

Module specifications,

information for module interfaces

Elite Mainly written reports Weekly Product design specifications

Wild Mainly verbal, very little

written project documentation

Continual, ad hoc Product design and

production choices

modification you do, you take the test plan and that is the base to redo all the tests again so it is

building up in its size.’’

4.2.1. Elite

The content of information exchange within Elite was completely different. Although there

was significant internal communication between members of the Elite team, external

communication was characterized by being mainly one-way from subject experts and test

users to the Elite team and from the Elite team to the contractor. The information passed between

units in the Elite project had more significantly more detail in the final product specification such

as its design and content. For example, documents exchanged between units during the course of

the project included specifications of

� functions the software should provide;

� whether or not to provide an intelligent search facility;

� typography, appearance of the paragraphs and characters on the screen;

� speed of processing, storage capacity;

� supplementary content to be provided in the software.

A detailed specification was seen as key, this often taking as long as 3–6 months, at the end of

which the software developers were expected to ‘‘come back with a definition study and a

project proposal of how they are going to achieve what we have asked for. That includes how

many man-days and weeks individual tasks take, what they will cost and who is doing what,

when.’’

Internal communication was also more formal, mostly in the form of written memos and

reports at important target dates in the agreed project plan. As might be expected, knowledge

transferred was also explicit. However, whereas in Global the emphasis was on the technical

aspects, in Elite the emphasis was on what tasks in the plan had been completed, problems

encountered and actions taken. The company was also making a particular effort to codify all the

knowledge gained in a procedures manual and to transfer learning through seminars to other units

within the company.

4.2.2. Wild

In theWild project, information exchange was much more frequent and ad hoc. The pattern of

communication was also much less structured. Communications occurred from every team

member to every other team member with no particular channel or individual dominating. One

team member described it as ‘‘a bubbling hive of creativity’’. Another described it as ‘‘confusing

from the outside’’. This frequent and ad hoc communication was all the more forthcoming given

that all teammembers were working in a relatively confined area. As one teammember described

it: ‘‘We were all working in close proximity so we all really knew what everyone was doing and

we could always go and have a chat about things. If two people were having a talk about

something, the third person would prick their ears up. We had numerous impromptu meetings

during the week, which meant we all knew roughly what was going on. We could all throw our

oar in.’’

The content of communications was also much more varied and extensive than in the other

two projects. Topics of communications included progress checking as in Global and product

design as in Elite but discussions were of greater depth and included a greater degree of

questioning and responsiveness. For example, team members described how each screen in the


product was reviewed and critiqued by the group as a whole. (This was also in line with my

observations of the interactions between team members during times I was present. Team

members appeared to be quite willing to criticize each other and there were protracted

discussions at each stage.) Asked about the differences on this project from others he had worked

on, the programmer noted: ‘‘The main thing is the teamwork. In virtually all other projects that

I’ve worked on I’ve been on my own. I’ve had to design, write and alter the programs literally on

my own. This was the first time I’d worked in a proper teamwith designers, artists and a producer.

And that’s what made it different. The fact that there were other people involved—I had to take

other people’s ideas into consideration.’’

In contrast to the other two projects, in the Wild project, virtually all communication was face

to face and there was very little formal project documentation. When asked about this, the project

manager reported that it was not considered necessary as the team was small and they were all

working within feet of each other. Each team member could see what the others were working on

and could readily ask questions or offer suggestions to each other. An example given by the

designer was that if she wanted to make a change in the design she could do so quite easily by

turning to the programmer who was sitting only a few feet away. Similarly the programmer

reported that if he was unsure about what the designer had in mind he could quite easily turn to

her and ask her or show her what he had done.

4.3. Knowledge exploitation and learning process

The different patterns of communication and information exchange appeared to influence the

learning process and knowledge that resulted. Table 5 summarizes the learning process and

knowledge that developed on each project.

4.3.1. Global

In Global the learning process was largely analytical. As the team leader explained at great

length the requirements and programs were analyzed in detail according to the company’s

procedure manual: ‘‘Every fault is recorded on our test tracking system and the result is then

assigned to whoever’s doing the programming. Then they have to take each one of those things

and fix it. If they cannot fix it they have to say why they cannot fix it.’’

The knowledge gained was mainly component knowledge. What was significant within the

team at Global was that there were no reports of what they had learned from the joint venture

partner or from the other team within Global. All learning reported by team members was

what they personally had discovered in performing their particular task in the project. For

example, the programmer reported how much he had learned about MPEG technology while

the team leader reported how much he had learned about the users needs. The knowledge

developed was also all related to specialist, component specific knowledge. As the head of

the department explained, this was because ‘‘the technology is racing car technology not

family saloon technology. It is still very much in the specialist category, not in the consumer

category. You need specialist skills and you need specialist skills every time.’’ This finding is

not surprising since the intention from the start had been to modularize both the project tasks

and product design. The modular product and project design encouraged individuals to

exchange specialist information with other individuals in their particular subteam but not

across specialties, so it is not surprising that learning was analytic rather than synthetic and

that there was high level of development of component knowledge but not much development

of architectural knowledge.


S.Chen

/J.Eng.Tech

nol.Manage.

22(2005)291–314

306

Table 5

Learning and knowledge developed based on interviews with project members

Project Learning process Product level Tacitness/explicitness of knowledge

Global Analytical: ‘‘Every fault is recorded

on our test tracking system and the

result is then assigned to whoever’s

doing the programming. Then they

have to take each one of those

things and fix it. If they can’t fix

it they have to say why they can’t

fix it.’’ (Project manager)

Component knowledge: ‘‘He has his expertise,

I have my expertise.’’ (Project manager)

Explicit: ‘‘Now when we rewrite things, say

we change one of the pages, we can just pull

out the test case document.’’ (Project manager)

Elite Synthetic: ‘‘First and foremost, its

publishing skills . . . a limited degree

of technical understanding . . . just

knowing what the technology can do

practically.’’ (Project manager)

Architectural knowledge: ‘‘We believe

that it’s important to exploit the

skills of the book people to make the

electronic product something special.’’

Explicit: ‘‘We are starting to document

procedures in order that other projects can

benefit from the experience.’’ (Project manager)

‘‘All the various enhancements

you can bring to it (the text)’’

(Project manager)

Wild Synthetic: ‘‘The main thing is the

teamwork.’’ (Programmer)

Both component and architectural

knowledge: ‘‘Obviously the more you

write programs for Windows the more

you learn about Windows programming.’’

(Programmer)

Tacit knowledge: ‘‘I can’t really summarize it.

It was just how you go about

doing it’’ (Project leader)

‘‘A bubbling hive of creativity’’

(Project leader)

‘‘How things fit together’’

‘‘How you pass information

around’’ (Project leader)

‘‘I think I’ve picked up a lot

technically while I was doing

it.’’ (Designer)

4.3.2. Elite

In contrast, the learning process reported in Elite could best be described as synthetic—bringing

together knowledge from different areas. As the head of the department explained: ‘‘First and

foremost, its publishing skills. On top of that it is just knowledge and experience . . . a limited degree

of technical understanding . . . having some of the language that developers use, understanding

some of the technical issues about storage, knowing what the technology can do practically.’’ The

knowledge developed was also architectural in nature, related to management of the overall

production process. This too is not surprising since that was the main task of the project managers

within Elite. More specifically they reported that they had gained a better understanding of the

timescales and costs involved in developing the product. For example, it was not initially

recognized how much work would be involved in adding video and animation to the text and the

price quotedby the software developerswas higher than the initial estimate.Asoneprojectmanager

explained, ‘‘As time goes by, these figures often with experience turn out to be pie in the sky.’’ This

was particularly the case given the relative newness of the product and the market.

4.3.3. Wild

Finally, the integrated project design in Wild encouraged frequent (usually daily) exchanges

of information between individuals performing various tasks so it is again not surprising that a

high degree of synthetic learning was reported, drawing on knowledge from other teammembers.

All members of theWild project reported a high degree of ‘‘cross-fertilization’’ or learning about

other parts of the production process. For example, the graphic designer, while confirming that

she was an artist by training, reported that she had also learned a lot about the technology. ‘‘I

suppose it’s like any other work—you just pick it up. There were certain things that you just

wonder ‘How do I do that?’—you literally just fly by the seat of your pants. If you want to do

something you just stay there until you’ve done it. I think I’ve picked up a lot technically while I

was doing it.’’

Both component and architectural knowledge were developed. For example, the software

specialist reported: ‘‘Technically there’s a lot that I learnt about C++ programming. Obviously

the more you write programs for Windows, the more you learn about Windows programming.’’

On the other hand, the project leader reported learning that was more related to architectural

knowledge: ‘‘Just how things fit together . . . how you pass information around.’’

Not surprisingly a large element of this learning reported appeared to be tacit. When asked to

explain specifically what they had learned, team members had great difficulty in doing so despite

being quite confident that they had learned ‘‘something’’. For example, when asked to summarize

what she had learned, the project manager replied ‘‘I can’t really summarize it. It was just how

you go about doing it . . . The day to day experiences of how things work.’’

5. Discussion conclusions, and research limitations

5.1. Discussion

The findings that information and knowledge flows varied in different project designs is

consistent with research in the information processing perspective that shows how the

information flow depends on communication within the project (Cooper, 1986; Eisenhardt and

Tabrizi, 1995; Griffin and Hauser, 1992; Hoegl and Gemuenden, 2001), boundary spanning

personnel (Conway, 1995; Tushman, 1977; Ianisiti, 1995; Nobel and Birkinshaw, 1998) and

external structures that facilitate collaboration with users (Gales and Mansour-Cole, 1995).


However, this paper suggests that project organization not only determines how the project team

processes information about the environment but also how it learns and the type of knowledge

that is developed.

A prerequisite of synthetic learning is that areas of knowledge from different specialties are

combined. This requires, first, access to expertise in different areas and, second, a means to

combine inputs from these different specialisms. Therefore, the project designmust achieve these

two things—first, enable team members to access sources of specialist knowledge and facilitate

exchange between subject experts within the project. In contrast, analytic learning requires

detailed knowledge of a particular discipline and so information exchange with other specialisms

is generally not required. Therefore, there is less need for information exchange between experts

in the project design.

The cases illustrate two reasons why synthetic learning may occur. First, as in the case of Elite,

synthetic learning may occur because the type of product requires expert input from different

disciplines; in this case, subject matter experts for the text, designers and programmers for the

software interface and project managers for the production process. Second, in the case of Wild,

synthetic learning may be a company objective. In this case, the impact extends beyond project

design to organizational design and organizational culture. The level at which learning occurs or

is desired is, therefore, also a factor that needs to be considered.

Similarly development of component knowledge requires different inputs and knowledge

processing as opposed to development of architectural knowledge. Architectural knowledge

requires exchange of knowledge about how the different components fit together, a process that

entails communication and coordination between individuals knowledgeable about the various

product components and how they relate to each other. Therefore, development of such

knowledge should be facilitated by a project structure that encourages knowledge exchange

about the different components are related in the production process. In contrast, development of

component-level knowledge requires detailed knowledge about the component but not about

other components and how they relate. Therefore, there is less need for the project design to cater

for knowledge exchange about different components. Architectural knowledge is more closely

related to synthetic learning since it requires more knowledge of the entire production process

and so is more likely to require synthesis of knowledge from different areas. This was evident in

the cases examined, where Elite and Wild both showed high levels of synthetic learning and

architectural knowledge compared with Global which focused more on analytic learning and

component knowledge.

The finding that the pattern of communication and the tacitness of knowledge are related is

consistent with findings in the psychology and linguistics literature. As discussed earlier,

knowledge can be tacit for two reasons—either it cannot be easily verbalized or it need not be.

Where communications about a particular topic are frequent or commonly understood, there will

be less need to verbalize certain things since individuals can refer to previous communications or

common knowledge, known in the linguistics literature as ‘implicatures’ (Sperber and Wilson,

2002). For instance, where conversants have previously discussed something, they may simply

refer to the discussion as ‘‘what we talked about yesterday’’, without the need to repeat the details

again. Similarly where over time individuals come to share assumptions about certain things

there may be less need to verbalize since the meaning is already understood and unambiguous

(Hymes, 1972). Thus, one reason why the knowledge developed in Wild was tacit may be that,

given the close proximity and daily social contact in the workplace, through unconscious

observation the team members developed a mutual understanding of work-related activities that

did not require explanation. In contrast, given the less frequent and less intensive contacts


between members in the Elite and Global teams, there was less opportunity to develop such tacit

understandings.

For purposes of highlighting the importance of project design, the discussion has

highlighted the principal differences in knowledge and learning in each project. However, this

should not be taken to mean that a particular project design only results in a particular type of

learning or knowledge. Different mixes of synthetic and analytic learning, architectural

knowledge and component knowledge and tacit and explicit knowledge may occur within each

project. The point made here is that although a variety of learning and knowledge types may be

found in a project, particular project designs seem to favor particular types of learning and

knowledge.

A practical implication of this research is that project design can influence the type of

knowledge exchange and learning within product development teams. Depending on whether

the objective is to develop tacit or explicit knowledge, to develop architectural or component

knowledge or to encourage synthetic or analytic learning, managers should choose different

project designs. Conversely choosing an inappropriate design can result in an undesired

learning outcome such as only component level learning when architectural knowledge was

desired.

5.2. Limitations and further research

The aim of this study was exploratory and so the findings clearly have limitations. Since only

three projects were studied and the data collected was mainly qualitative, it is not possible to

conduct formal, statistical tests to determine the generalizability of the patterns found. Future

research should aim to overcome these limitations by testing with a larger sample of projects that

allows the strength of relationships between factors and generalizability of findings to be tested.

The study also relied on free-form interviews to surface individuals’ recall and perception of

learning that occurred. This method was chosen because at the outset it was unclear exactly what

the learning effects would be in the different projects. However, as in all personal accounts of

events, such accounts could be subject to errors such as forgetfulness, selective recall and post-

rationalization. Future research could attempt to more objectively measure the communication

and learning that occurs in projects, possibly testing before and after the project. Some areas that

could be furthered explored using more rigorous methods, for example, are the frequency and

type of communications about various aspects of the project and the extent of different types of

learning.

Secondly, although attempts were made to select projects that were as alike as possible in

terms of product type, project length and team size, the effect of other project- or organization-

specific factors cannot be entirely ruled out such as the international spread of the project team,

the age of the company, organizational culture and internal politics. From the interviews within

the companies examined, these factors were reported to have been explicitly considered in the

project design rather than factors that directly affected learning independently of project design.

However, further research could examine possible effects of these other factors on learning, for

example, by examining projects within the same organization in order to control for

organization-specific factors.

Finally, although it was not specifically examined in this research, this research suggests that

the project structure is aligned or misaligned with the knowledge or learning desired should have

performance implications. Other researchers from an information processing perspective (e.g.

Daft and Lengel, 1986; Galbraith, 1977) have made the argument that project structure influences


information processing and consequently organizational performance. The cases examined here

suggest that adopting a knowledge and learning perspective could also be useful and that the

structure–performance relationship is mediated by the specific type of knowledge and learning

involved. Further research could explore this in more detail.

Appendix A. Interview guide

A.1. Project background

1. When and how did the project start?

2. Where did the idea originate?

3. What were original aims? Did these change?

4. What was new about it?

5. Had the company done anything similar before?

6. Does the company have documented standards/procedures for product development or project

management?

A.2. Management

1. Who was in charge? Who sponsored the project?

2. How were resources allocated?

3. Did the project have to compete for resources with other projects?

4. How closely was the team managed?

5. What kind of checks or monitoring of the project took place?

6. How did team members communicate with each other?

7. Were there formal/informal meetings? Memos?

8. Who initiated these?

9. Were these regular? Set in advance?

10. How were decisions made?

A.3. Planning

1. How clearly defined were the objectives? What were they?

2. To what extent were you clear on target customers, customer needs and usage, product

offering, pricing, development costs, production costs, distribution, competition?

3. What were the main constraints on the project? (prompt, e.g. staffing, timing, costs)?

4. Was there a clearly defined project plan?

5. Were there set targets? Who set them? How?

6. What were the different stages in the plan?

7. How clearly defined were the activities at each stage?

8. How closely did the project follow the plan?

9. What deviations from the plan did you have to make?

10. What unexpected things occurred or did you discover?

11. What was the actual sequence of events?

12. What were critical points in the project?

13. What were the key decisions/choices you made?

14. How did you judge performance?


A.4. Activities and roles at each stage

1. Who was involved at each stage in the project and what did they do?

2. What are their functions in the organization? Are their roles in the organization clearly

defined?

3. Were their roles in the project clearly defined?

4. What are your/their backgrounds/what experience did they bring?

5. How new were they to the company?

6. Had the team members worked together before?

7. Were staff assigned solely this project or did they work on other projects at the same time?

8. Were there clearly separated phases or did many activities overlap?

9. What was the duration of each phase?

10. Which activities are normal/similar to other projects?

11. Are standard procedures documented?

12. Which activities were peculiar to this project?

A.5. Problems and issues encountered

1. What were the main problems or issues encountered during the course of the project?

2. How were these different from other projects?

3. What problems or issues did you anticipate at the outset? Prompt: new technology, lack of

market knowledge, project deadlines?

4. Did these occur?

5. How did you resolve them?

6. What unexpected problems or issues came up during the project?

7. How did you solve these?

8. What were the main sources of knowledge and information used in the project?

9. Did you have to rely on people outside the project? The organization?

10. What was your impression of how the project was viewed elsewhere in the company?

A.6. Post-project evaluation

1. How well did the project meet objectives?

2. What objectives were not met?

3. Is there anything different you do now on new projects as a result of this project?

4. What do you think you have learned personally from the project?

5. What do you think the organization/team as a whole has learned?

6. What new skills or knowledge did you develop on this project?

7. How else has this project helped give your company an advantage over competitors?

References

Akgun, A.E., Lynn, G.S., Reilly, R., 2002. Multi-dimensionality of learning in new product development teams. European

Journal of Innovation Management 5 (2), 57–72.

Brown, S.L., Eisenhardt, K.M., 1995. Product Development: Past Research, Present Findings, and Future Directions.

Academy of Management Review 20 (2), 343–378.

Campione, T.J., 2003. Making research collaborations succeed. Research Technology Management 46 (4), 12–15.


Carayannis, E.G., Alexander, J., 2002. Is technological learning a core competence, when, how and why? A longitudinal,

multi-industry study of firm technological learning and market performance. Technovation 22, 625–643.

Castillo, J., 2002. A note on the concept of tacit knowledge. Journal of Management Inquiry 11 (1), 46–57.

Clark, K.B., Fujimoto, T., 1991. Product Development Performance: Strategy, Organization and Management in the

World Auto Industry. Harvard Business School Press, Boston, MA.

Conway, S., 1995. Informal boundary spanning communication in the innovation process: an empirical study. Technology

Analysis and Strategic Management 7 (3), 327–343.

Cooper, R.G., 1986. Winning at New Products. Addison-Wesley, Reading, MA.

Cowan, R., David, P.A., Foray, D., 2000. The explicit economics of knowledge codification and tacitness. Industrial and

Corporate Change 9 (2), 211–254.

Daft, R.J., Lengel, R.H., 1986. Organizational information requirements, media richness and structural design. Manage-

ment Science 32 (5), 554–571.

Datar, S., Jordan, C., Kekre, S., Rajiv, S., Srinivasn, K., 1997. New product development structures and time-to-market.

Management Science 43 (4), 452–464.

Dougherty, D., 2001. Reimagining the differentiation and integration of work for sustained product innovation.

Organization Science 12, 6–12.

Eisenhardt, K.M., 1989. Building theories from case study research. Academy of Management Review 14, 532–550.

Eisenhardt, K., Tabrizi, B., 1995. Accelerating adaptive processes: product innovation in the global computer industry.

Administrative Science Quarterly 40 (1), 84–110.

Galbraith, J.R., 1977. Organizational Design. Addison-Wesley, Reading, MA.

Gales, L.M., Porter, P.S., Mansour-Cole, D., 1992. Innovation project technology, information processing and perfor-

mance: a test of the Daft and Lengel conceptualization. Journal of Engineering and Technology Management 9, 303–

338.

Gales, L., Mansour-Cole, D., 1995. User involvement in innovation projects: toward an information processing model.

Journal of Engineering and Technology Management 12, 77–109.

Garud, R., Kuramaswamy, A., 1996. Technological designs for retention and reuse. International Journal of Technology

Management 11 (7/8), 883–891.

Garud, R., Nayyar, P.R., 1994. Transformative capacity: continual structuring by intertemporal technology transfer.

Strategic Management Journal 15, 365–385.

Granstand, O., Bohlin, E., Oskarsson, C., Sjoberg, N., 1992. External technology acquisition in large multi-technology

corporations. R&D Management 22 (2), 111–133.

Griffin, A., Hauser, J.R., 1992. Patterns of communication among marketing, engineering and manufacturing: a

comparison of two new product development teams. Management Science 38 (3), 360–373.

Gupta, A.K., Govindarajan, V., 2000. Knowledge flows within multinational corporations. Strategic Management Journal

21 (4), 473–496.

Hamel, G., 1991. Competition for competence and inter-partner learning within international strategic alliances. Strategic

Management Journal 12 Special Issue: Global Strategy 83–103.

Handfield, R.B., Ragatz, G.L., Petersen, K.J., Monczka, R.M., 1999. Involving suppliers in new product development.

California Management Review 42 (1), 59–82.

Hansen, M., 2002. Knowledge networks: explaining effective knowledge sharing in multiunit companies. Organization

Science 13 (3), 232–248.

Henderson, R., Clark, K.B., 1990. Architectural innovation: the reconfiguration of existing product technologies and the

failure of established firms. Administrative Science Quarterly 35, 9–30.

Hitt, M.A., Ireland, R.D., Lee, H.-U., 2000. Technological learning, knowledge management, firm growth and

performance: an introductory essay. Journal of Engineering and Technology Management 17 (3/4), 231–246.

Hoegl, M., Gemuenden, H.G., 2001. Teamwork quality and the success of innovative projects: a theoretical concept and

empirical evidence. Organization Science 12 (4), 435–449.

Hymes, D., 1972. On communicative competence. In: Pride, J.B., Holmes, J. (Eds.), Sociolinguistics. Penguin Books,

Harmondsworth.

Ianisiti, M., 1995. Shooting the rapids: managing product development in turbulent environments. California Manage-

ment Review 38 (1), 37–59.

Inkpen, A.C., Crossan, M.M., 1995. Believing is seeing: joint ventures and organization learning. Journal of Management

Studies 32 (5), 595–618.

Inkpen, A.C., Dinur, A., 1998. Knowledge management processes and international joint ventures. Organization Science

9 (4), 454–468.

Jarillo, J.C., 1988. On strategic networks. Strategic Management Journal 9, 31–41.


Kakabadse, N., Kakabadse, A., 2000. Critical review, outsourcing: a paradigm shift. Journal ofManagement Development

19 (8), 670–729.

Kazanjian, R.K., Drazin, R., Glynn, M.A., 2000. Creativity and technological learning: the roles of organization

architecture and crisis in large-scale projects. Journal of Engineering and Technology Management 17, 273–

298.

Kessler, E.H., Bierly, P.E., Gopalakrishnan, S., 2000. Internal vs. external learning in new product development: effects on

speed, costs and competitive advantage. R&D Management 30 (3), 213–223.

Kessler, E.H., Chakrabarti, A.K., 1996. Innovation speed: a conceptual model of context, antecedents, and outcomes.


Kodama, F., 1992. Technology fusion and the new R&D. Harvard Business Review 7 (4), 70–78.

Kogut, B., 1988. Joint ventures: theoretical and empirical perspectives. Strategic Management Journal 9, 319–332.

Kogut, B., Zander, U., 1992. Knowledge of the firm, combinative capabilities and the replication of technology.

Organization Science 3, 383–397.

Kuwada, K., 1998. Strategic learning: the continuous side of discontinuous change. Organization Science 9 (6), 719–

736.

Lambe, C.J., Spekman, R.E., 1997. Alliances, external technology acquisition, and discontinuous technological change.

Journal of Product Innovation Management 14, 102–116.

Larsson, R., Bengtsson, L., Henriksson, K., Sparks, J., 1998. The interorganizational learning dilemma: collective

knowledge development in strategic alliances. Organization Science 9 (3), 285–305.

Levitt, R.E., Thomsen, J., Christiansen, T.R., Kunz, J.C., Jin, Y., Nass, C., 1999. Simulating project work processes and

organizations: toward a micro-contingency theory of organizational design. Management Science 45 (11), 1479–

1495.

Lind, M.R., Zmud, R.W., 1991. The influence of a convergence in understanding between technology providers and users

on information technology innovativeness. Organization Science 2 (2), 195–217.

Lynn, G.S., Akgun, A.E., 2000. A new product development learning model: antecedents and consequences of declarative

and procedural knowledge. International Journal of Technology Management 20 (5–8), 490–510.

Matusik, S.F., Hill, C.W.L., 1998. The utilization of contingent work, knowledge creation and competitive advantage.


Millar, J., Demaid, A., Quintas, P., 1997. Trans-organizational innovation: a framework for research. TechnologyAnalysis

and Strategic Management 9 (4), 399–418.

Mohrman, S.A., Finegold, D., Mohrman, A.M., 2003. An empirical model of the organization knowledge system in new

product development firms. Journal of Engineering and Technology Management 20, 7–38.

Molleman, E., Broekhuis, M., 2003. Sociotechnical systems: towards an organizational learning approach. Journal of

Engineering and Technology Management 20, 271–294.

Monaert, R.K., Deschoolmeester, D., 1990. Organizational strategy and resource allocation for technological turnaround.

R&D Management 20 (4), 291–303.

Nobel, R., Birkinshaw, J.M., 1998. Patterns of control and communication in international research and development

units. Strategic Management Journal 19 (5), 479–496.

Nonaka, I., Takeuchi, H., 1995. The Knowledge-Creating Company: How Japanese Companies Create the Dynamics of

Innovation. Oxford University Press, Oxford.

Olson, E.M., Walker, O.C., Ruekert, R.W., 1995. Organizing for effective new product development: the moderating role

of product innovativeness. Journal of Marketing 59 (1), 48–62.

Pettigrew, A., 1990. Longitudinal field research on change: theory and practice. Organization Science 1 (3), 267–292.

Pfeffer, J., Salancik, G.R., 1978. The External Control of Organizations. Harper and Row, New York.

Polanyi, M., 1966. The Tacit Dimension. Anchor Day, New York.

Polley, D., van de Ven, A.H., 1996. Learning by discovery during innovation. International Journal of Technology

Management 11 (7/8), 871–882.

Provan, K.G., 1983. The federation as an interorganizational linkage network. Academy of Management Review 8 (1),

79–89.

Provan, K.G., Skinner, S.J., 1989. Interorganizational dependence and control as predictors of opportunism in dealer-

supplier relations. Academy of Management Journal 32 (1), 202–212.

Purser, R.E., Pasmore, W.A., Tenkasi, R.V., 1992. The influence of deliberations on learning in new product development

teams. Journal of Engineering and Technology Management 9, 1–28.

Quinn, J.B., Hilmer, F.G., 1994. Strategic outsourcing. Sloan Management Review 35, 43–55.

Reagans, R., Zuckerman, E.W., 2001. Networks, diversity and productivity: the social capital of corporate R&D teams.

Organization Science 12 (4), 502–517.


Reed, R., DeFillippi, R.J., 1990. Causal ambiguity barriers to imitation and sustainable competitive advantage. Academy

of Management Review 15 (1), 88–102.

Ritchey, T., 1991. Analysis and synthesis: on scientific method—based on a study by Bernhard Riemann. Systems

Research 8 (4), 21–41.

Robertson, T., Gatignon, H., 1998. Technology development mode: a transaction cost conceptualization. Strategic

Management Journal 19, 515–531.

Schill, R.L., Bertodo, R.G., McArthur, D.N., 1994. Achieving success in technology alliances: the Rover-Honda strategic

collaboration. R&D Management 24 (3), 261–277.

Sicotte, H., Langley, A., 2000. Integration mechanisms and R&D project performance. Journal of Engineering and

Technology Management 17, 1–37.

Singh, K., 1997. The impact of technological complexity and interfirm cooperation on business survival. Academy of

Management Journal 40 (2), 339–367.

Spender, J.-C., 1996. Making knowledge the basis of a dynamic theory of the firm. Strategic Management Journal 17

(Special Issue), 45–62.

Sperber, D., Wilson, D., 2002. Pragmatics, modularity and mind-reading. Mind and Language 17 (1/2), 3–23.

Takeishi, A., 2001. Bridging inter- and intra-firm boundaries: management of supplier involvement in automobile product

development. Strategic Management Journal 22, 403–433.

Takeishi, A., 2002. Knowledge partitioning in the interfirm division of labor: the case of automotive product development.

Organization Science 13 (3), 321–338.

Tsai, W., 2001. Social structure of ‘‘coopetition’’ within a multiunit organization: coordination, competition and

intraorganizational knowledge sharing. Organization Science 13 (2), 179–190.

Tushman, M., 1977. Communication across organizational boundaries: special boundary roles in the innovation process.

Administrative Science Quarterly 22, 587–605.

Tushman, M., Nadler, D.A., 1978. Information processing as an integrating concept in organizational design. Academy of

Management Review 3 (3), 613–624.

Vining, A., Globerman, S., 1999. A conceptual framework for understanding the outsourcing decision. European

Management Journal 17 (6), 645–654.

Von Hippel, E., 1986. Lead users a source of novel product concepts. Management Science 32 (7), 791–805.

Von Hippel, E., 1990. Task partitioning: an innovation process variable. Research Policy 19 (5), 407–418.

Williamson, O.E., 1975. Markets and Hierarchies. Free Press, New York.

Yin, R.K., 1994. Case Study Research: Design and Methods. Sage Publications, Thousand Oaks, CA.


Task partitioning in new product development teams: A knowledge and learning perspective

Documents

Transcript of Task partitioning in new product development teams: A knowledge and learning perspective