Task partitioning in new product development teams: A knowledge and learning perspective
-
Upload
stephen-chen -
Category
Documents
-
view
213 -
download
0
Transcript of 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).
S. Chen / J. Eng. Technol. Manage. 22 (2005) 291–314294
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
S. Chen / J. Eng. Technol. Manage. 22 (2005) 291–314 295
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
S. Chen / J. Eng. Technol. Manage. 22 (2005) 291–314296
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.
S. Chen / J. Eng. Technol. Manage. 22 (2005) 291–314 297
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
S. Chen / J. Eng. Technol. Manage. 22 (2005) 291–314298
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.’’
S. Chen / J. Eng. Technol. Manage. 22 (2005) 291–314 299
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
S. Chen / J. Eng. Technol. Manage. 22 (2005) 291–314300
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
S. Chen / J. Eng. Technol. Manage. 22 (2005) 291–314 301
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
S. Chen / J. Eng. Technol. Manage. 22 (2005) 291–314302
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
S. Chen / J. Eng. Technol. Manage. 22 (2005) 291–314 303
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
S. Chen / J. Eng. Technol. Manage. 22 (2005) 291–314304
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. Technol. Manage. 22 (2005) 291–314 305
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).
S. Chen / J. Eng. Technol. Manage. 22 (2005) 291–314 307
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
S. Chen / J. Eng. Technol. Manage. 22 (2005) 291–314308
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
S. Chen / J. Eng. Technol. Manage. 22 (2005) 291–314 309
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?
S. Chen / J. Eng. Technol. Manage. 22 (2005) 291–314310
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.
S. Chen / J. Eng. Technol. Manage. 22 (2005) 291–314 311
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.
S. Chen / J. Eng. Technol. Manage. 22 (2005) 291–314312
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.
Academy of Management Review 21 (4), 1143–1191.
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.
Academy of Management Review 23 (4), 680–697.
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.
S. Chen / J. Eng. Technol. Manage. 22 (2005) 291–314 313
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.
S. Chen / J. Eng. Technol. Manage. 22 (2005) 291–314314