A research agenda to reduce risk in new product development through knowledge management: a practitioner perspective

J. Eng. Technol. Manage. 20 (2003) 117–140

A research agenda to reduce risk in new product development through knowledge management: a practitioner perspective Lynne P. Cooper∗ Jet Propulsion Laboratory, California Institute of Technology, 4800 Oak Grove Drive, M/S 302-231 Pasadena, CA 91109, USA

Abstract Successful new product development (NPD) requires effective strategies for reducing risk. Knowledge management systems (KMS) have the potential to aid in risk reduction, e.g. by gathering and processing relevant information and encapsulated knowledge from a variety of internal and external sources. The potential benefits of KMS, however, have not been fully realized, and may actually introduce new risks. This paper presents a practioner view of the desired characteristics of tools to support NPD and suggests a research agenda for the use of knowledge-based tools from the perspective of balancing benefits and risks. © 2003 Elsevier Science B.V. All rights reserved. PACS: O32: Management of technological innovation and R&D Keywords: Risk; New product development; Innovation; Knowledge management

1. Introduction New product development (NPD) is the process by which an organization uses its resources and capabilities to create a new product or improve an existing one. Product development is seen as “among the essential processes for success, survival, and renewal of organizations, particularly for firms in either fast-paced or competitive markets” (Brown and Eisenhardt, 1995, p. 344). Project teams performing NPD face pressure to reduce cycle time and development costs, without sacrificing innovation, as characterized by a faster–better–cheaper philosophy (McDonough et al., 1999; Paté-Cornell and Dillon, 1998). ∗ Tel.: +1-818-393-3080; fax: +1-818-393-4663. E-mail address: [email protected] (L.P. Cooper).

0923-4748/03/$ – see front matter © 2003 Elsevier Science B.V. All rights reserved. doi:10.1016/S0923-4748(03)00007-9

118

L.P. Cooper / J. Eng. Technol. Manage. 20 (2003) 117–140

The work continues to grow more complex and require greater breadth and depth of knowledge (Mankin et al., 1996). Much of this greater breadth and depth of knowledge must be acquired from outside the core project team. Ancona and Caldwell (1998) have identified multiple forms of peripheral involvement based on part-cycle membership, part-time assignment, and the use of experts. Such outside-team resources are rarely collocated and in many cases are unknown at the outset of the project. Thus, traditional perspectives on the use of electronic tools by NPD teams, such as the use of collaborative technologies to tie virtual team members together, still do not address the issues of how to provide knowledge to NPD members from sources outside the team, nor how to provide appropriate context to peripheral contributors. In this paper, I am focused on how computer-aided tools help bring knowledge to a NPD team. The design process consists of a series of divergent and convergent activities at varying levels from concept formulation to detailed design (Couger, 1996). It is highly iterative and routinely involves evaluating incomplete and often contradictory information (Thomke, 1998). NPD is increasingly accomplished via cross-functional teams (Adler, 1995; McDonough, 2000) who negotiate, compromise, and make trades along multiple dimensions of utility. The process is political as well as technical, takes place in a phased manner, and requires time for synthesis, integration, and culling of ideas. The information required to make good decisions is not necessarily known in advance. Team members involved in new product development are drawn from multiple disciplines—with all of the ensuing thought-world type problems (Dougherty, 1992). Design decisions are made within the context of a flow of decisions (not a series of isolated events). NPD team members face the same types of challenges that all decision makers face: they are subject to judgmental biases (Tversky and Kahneman, 1974), believe in their ability to influence results post-decision (March and Shapira, 1987; Shapira and Berndt, 1997), suffer from limited capacity to deal with data (Simon, 1957), are often overly ambitious, and must face the consequences of their decisions (Tetlock, 1985). The work is considered to be inherently challenging and often depends on making intuitive “leaps”.

2. Knowledge-related challenges in NPD Research into NPD has identified a number of factors that influence the process: technology (e.g. Dvir et al., 1998; Karlsson and Åhlström, 1999; Shenhar, 1998; Song and Montoya-Weiss, 2001; Tatikonda and Rosenthal, 2000), product characteristics (e.g. Brown and Eisenhardt, 1995; Cardinal and Lei, 2000; Cohen and Bailey, 1997), project structure (e.g. Larson and Gobeli, 1989; Olson et al., 1995; Song et al., 1998), team member characteristics and patterns (e.g. Ancona and Caldwell, 1992; Katz, 1982; Keller, 1986; McDonough and Barczak, 1992), team processes (e.g. Dyer and Song, 1998; Gobeli et al., 1998; Katz and Tushman, 1979; Susman and Ray, 1999), organizational context (e.g. Allen, 1977; Gerwin and Moffat, 1997; Keller, 1986; McComb et al., 1999; Pinto et al., 1993), and external environment (e.g. Balachandra and Friar, 1997; Fox et al., 1998; Lynn and Akgün, 1998; Souder et al., 1998). From a practioner’s perspective, these results can be summed up as: ‘the more difficult the project in terms of scope, new technology, and complexity, the more

L.P. Cooper / J. Eng. Technol. Manage. 20 (2003) 117–140

119

Table 1 Project and product failures due to intrinsic and extrinsic problems Problems

Product failure

Project failure

Intrinsic

Does not meet performance, reliability, safety, or other requirements for the proposed environment Unfavorable reception in market; regulatory change

Violating resource constraints (e.g. cost, schedule) Competition develops product first

Extrinsic

susceptible it is to perturbations and mismatches in the team, organization, and external environment, and the greater the need for knowledge acquisition and development for the project to succeed’. Ambitious projects, working within tight time and resource constraints are difficult. They are, however, also extremely exciting, can be a lot of fun to work on, and represent significant opportunities for gain. A key challenge faced by new product development projects is how to acquire knowledge and manage sources of uncertainty in order to reduce the risk of failure of either the project or the resulting product. As shown in Table 1, the product can “fail” due to intrinsic problems (e.g. does not meet performance, reliability, or safety requirements in the environment for which it was designed) or extrinsic problems (e.g. flops in the market, changes in regulations), while the project can “fail” by violating constraints (e.g. late, over budget), not delivering the product, or being beaten by the competition. Uncertainty exists relative to both possible outcomes and their likelihood of occurring. Projects face the challenge of identifying the factors that affect them relative to uncertainties in: the market (e.g. Fox et al., 1998), the availability and performance of new technology (e.g. Song and Montoya-Weiss, 2001), the cost and availability of components and materials, the validity of assumptions, the interaction effects in tightly coupled systems (e.g. Perrow, 1981), the predictability of system responses under varying input and environmental conditions, the ability of the project team to perform, and the ability of the project to detect problems. Under ideal conditions, the project would be able to identify all unknowns and implement a risk management program to systematically address them. In reality, projects have limited resources, so must therefore decide which uncertainties to explore and reduce. Both the acquisition of outside knowledge (e.g. through searches, consultants) and the development of internal knowledge (e.g. through tests and experiments) is critical to resolving uncertainty effectively. Acquiring the knowledge necessary to address concerns, problems, uncertainties, assumptions, and the relationships between them is difficult in the dynamic world of NPD projects. Acquiring some specific piece of knowledge is not necessarily a one-time activity, where once acquired, that knowledge is continually available. Instead, it can be forgotten, mis-remembered, or otherwise “de-acquired”. NPD is a fast-paced, creative process where participants are often switching between high-level conceptual issues and a low-level focus on details. It is an unfortunate reality that in design teams, necessary activities routinely “fall through the cracks”, documentation lags development, and decisions are made then remade due to an inability to get all the players together, the introduction of new players, and an inability to recall all the details. Issues are raised and forgotten because attention was diverted elsewhere. Decisions are made based on sketchy information that is not revisited. Opportunities are lost because no one is assigned to follow up on them.

120

L.P. Cooper / J. Eng. Technol. Manage. 20 (2003) 117–140

These conditions are not indicative of an incompetent workforce. Rather, they are indicative of a human workforce engaged in a challenging task, subject to all the limitations that people face. For example, there are limits to the number of tasks a person can juggle at any given time and how many details a person can keep track of or analyze without support. There are psychological factors that affect perception and interpretation of importance, such as only “hearing” items that relate to your technical discipline, or that you are familiar with (Tversky and Kahneman, 1974). There are also difficulties communicating between disciplines, with colleagues from other environments (as occurs in inter-organizational teams) and via intermediary technologies (e.g. teleconference, email). A new product development project is a stressful environment. Although research has indicated that stress can have positive consequences for team members (Cordero et al., 1998) it can also exacerbate common team problems. For example, the cross-functional nature of NPD leads to problems associated with collaborating across multiple “thought worlds” (Dougherty, 1992) such as higher degrees of task conflict (Jehn, 1995). Unless successfully addressed, productive task-related conflicts can devolve into seriously disruptive emotional conflicts (Pelled and Adler, 1994), decreasing the overall performance of the project (Gobeli et al., 1998). Miscommunication, a lack of understanding of the consequences of decisions on related domains, and differences in priorities contribute to collaboration difficulties. Changes in team membership, incorporating part-cycle, part-time, and specialist workers can be disruptive due to socialization and re-establishing work norms (Ancona and Caldwell, 1998), and due to revisiting past decisions and reasoning. The distractions of the day-to-day work often prevent NPD teams from identifying and taking advantage of opportunities. The focus on problems of immediate relevance makes it difficult to recognize information with potential future application. Team members often feel that they barely have enough time to do what they have to do, and never have enough time to do all that they want or should do. The sheer volume of work leaves little discretionary time to engage in the scanning type behaviors that enable discovery and feed into the innovation process (Majchrzak et al., in press). Majchrzak et al. (in press) summarized results indicating that the likelihood of knowledge being reused will be affected by: 1. the knowledge of the recipient, such as his/her existing knowledge and ability to absorb new knowledge (Cohen and Levinthal, 1990); 2. the strategy used by the recipient in the search process: a broader search process is more effective especially with innovation (Allen, 1977; Armbrecht et al., 2001); 3. the source’s willingness to share knowledge (Nahapiet and Ghoshal, 1988; Szulanski, 2000); 4. the nature of the relationship between the source and recipient, with closer relationships more likely to facilitate transfer (Argote, 1999; Dyer and Noveoka, 2000); 5. the ability to adapt previous knowledge and capabilities, e.g. “reinvention” (Rice and Rogers, 1980); 6. the presence of a third party that can establish the credibility of the knowledge (Moreland and Myaskovsky, 2000); 7. the existence and availability of shared artifacts (Clark, 1996; Star and Griesemer, 1989). Researchers need to appreciate that the knowledge acquisition and development process must gradually and iteratively lead to risk reduction, despite the inherent unpredictability,

L.P. Cooper / J. Eng. Technol. Manage. 20 (2003) 117–140

121

if the NPD process is to succeed. It is not simply networking people, as in collaborative tools. Moreover, NPD participants are overwhelmed so that proactive search and retrieval is unlikely. Therefore, systems must address those factors that increase the probability that relevant knowledge will be reused.

3. Frustrations with existing tools and perspectives A multitude of commercial tools exist to help NPD participants acquire, develop, and manage their knowledge, as summarized in Table 2 based on functionality. The three categories of design tools, collaborative tools, and knowledge management systems are not mutually exclusive, as many products incorporate a selection of features. 3.1. Overview of tools Collaborative tools encompass a variety of functions to support group work. They include: product data and document management systems that provide the capability to store, retrieve, share, and maintain configuration and version control over text- or file-based artifacts of the design process; authoring tools, which assist in the creation of text-based products, such as requirements documents, plans, and specifications, and often provide additional lifecycle management, traceability, or reporting features; and groupware systems that facilitate communication and coordination between team members. The use of design tools, such as computer-aided design (CAD) and computer-aided software engineering (CASE) environments, are ubiquitous throughout the NPD process. These tools enable the user to create, model, visualize, simulate, and analyze their designs. Finally, knowledge management tools exist to create, manage and use resources that have encapsulated knowledge applicable to the given design domain. Decision support systems (DSS), often considered a component of groupware, are computer applications that analyze data and present it so that users can make business decisions more easily. They are based on models of the business environment and are intended to “help the decision maker develop an understanding of the ill-structured, complex environment represented by the model” (Steiger, 1998, p. 199). While design tools effectively capture the end result of the design process, design rationale tools capture the explanation of why the “new product” was designed the way it was, including trade-offs, assumptions, and reasoning (Regli et al., 2000). In knowledge resources, the content is the key feature, and functions exist as utilities to present that content to the user. Each category of tool supports the acquisition and development of knowledge (e.g. through experimentation, interaction with team members or external experts, access to encoded knowledge). As such, they have the potential to reduce uncertainty and NPD risk. Examples of contributions these tools can make toward identifying, managing, or reducing project or product risk (intrinsic or extrinsic) are given in Table 3. While there are no shortages of tools to support NPD, their acceptance and use has been mixed. While some applications such as email have been enthusiastically adopted (Markus, 1994) others such as design rationale systems have yet to reach a wide audience (Regli et al., 2000). The typical problems of information systems (King and Majchrzak, 2002)

122

L.P. Cooper / J. Eng. Technol. Manage. 20 (2003) 117–140

such as cross-platform incompatibility, non-standard output formats, steep learning curves, and high initial investment and maintenance costs apply. In addition, there are frustrations that arise specifically in applying these tools to new product development, as discussed in the following.

Table 2 Categories of tools to support the NPD process Category

Function

Classes/examples

Frustrations

Design tools

Assist in the creation, visualization, analysis, and simulation of designs

CAD, object-based modeling (e.g. Foresight, Rational Rose® )

Significant learning curves; cross-product format compatibility; high cost

Manage the products of the design process: facilitate storage and retrieval of drawings, documents, computer files, etc.; version and change control

Document management systems (e.g. Xerox DocuShare® ); product data management systems

Authoring

Assist in the creation of text-based products

Requirements definition (e.g. Telelogic’s dynamic object oriented requirements system: DOORS® ), specifications, company-specific templates

Groupware

Facilitate communication and coordination between team members

Virtual presence (e.g. electronic meeting rooms), collaboration environments (e.g. Lotus® Notes, Groove® ), communication utilities (e.g. email, chat)

Entering essentially redundant meta-data; inability to search across repositories; lack of routine support for bulk transfer of products; difficulty in managing “what if” materials; lack of substantive contextual information Rigid structure of document format; only subset of functionality of programs that would be used for individual authoring (e.g. Microsoft® Word); difficulty working off line; difficulty managing “what if” materials; difficulty in outputting notes and hyper-linked materials for hardcopy review; slows down the process Rigid structure and overall lack of process flexibility; dependence on skill of facilitator or system operator for overall performance; lack of substantial improvements over individual tool capabilities; need for all users to own copy of the software; cross-platform support (e.g. for UNIX. Linux, or MAC users)

Collaboration tools Work product management

L.P. Cooper / J. Eng. Technol. Manage. 20 (2003) 117–140

123

Table 2 (Continued ) Category

Function

Knowledge management systems Decision support Data analysis for systems structured decision making

Classes/examples

Frustrations

Unique systems developed to support specific decision problem for specific set of users

Rigid structure and modeling of decision process; lack of substantive contextual information; non-intuitiveness of decision algorithms; limited ability to interact and engage with the system; dependence on quantifying factors Rigid structure and overall lack of process flexibility; dependence on skill of facilitator or system operator for overall performance; limited language for representation and modeling; slows down the process Emphasis on administering content rather than improving it; emphasis on storage and retrieval rather than use; dependence on user diligence in inputting meta-data; lack of contextual cues to judge reliability, credibility, etc. of content; passive-aggressive delivery methods; sanitized content; expensive, non-valuable (from customer perspective) features; lack of cross-repository access

Design rationale tools

Structure and capture rationale and supporting information during design process

e.g. Compendium, QuestMap

Knowledge resources

Acquisition, development, distribution and access to knowledge resources and specialized content

Search engines, portals, experts directories, lessons learned systems, knowledge bases, intelligent agents

3.2. Frustrations with existing tools The introduction of any tool into an environment has the potential to serve as a catalyst for change. Whether the net value of the resulting change will be positive or negative is highly dependent on how well matched the tool is to the needs of the intended users. As any developer can tell you, there are a lot of ways for a product to fail, and those products

124

L.P. Cooper / J. Eng. Technol. Manage. 20 (2003) 117–140

Table 3 Example risk reduction contributions Category

Design tools

Collaboration tools Authoring

Work product management Groupware

Product

Project

Intrinsic

Extrinsic

Intrinsic

Embedded guidelines, enhanced design and analysis capabilities, virtual experimentation

Communicate vision of product to external people (e.g. potential customers, management)

Speed up design iterations, Lower cost of design iterations

Traceability of requirements, standardization of content/format Information sharing among team members Access to team expertise

Knowledge management systems Decision support systems

Extrinsic

Visibility into process

Access to external expertise

Synchronization via configuration management Virtually bring together team members, Avoid or manage conflict via facilitation

Incorporate market intelligence

Cost/schedule evaluation Assist new members to come up to speed, make assumptions explicit, visibility into how changes will ripple through, reduce “falling through the cracks” Access to analogous cost, schedule data, “just-in-time” knowledge delivery, support for reuse

Design rationale capture

Structure and record decision process, reduce “falling through the cracks”, feed-forward info of potential future use

Support regulatory processes (e.g. Environmental Impact)

Knowledge resources

Access to encoded expertise and analogous experiences, keep track of details

Access to encoded market intelligence

Access to external expertise

Incorporate competitor intelligence

Encoded competitive intelligence

intended to help the NPD process are no exceptions. The following section provides a practioner’s view of multiple ways for information systems and tools to “fail” the NPD user. These fall roughly into three categories. 1. Disrupting the natural flow of activity: where the use of the tool interrupts the cognitive and task processes of the individual team members. 2. Altering roles: where the use of the tool substantially changes the roles of team members. 3. Lack of context: where the tool hides or eliminates important contextual information.

L.P. Cooper / J. Eng. Technol. Manage. 20 (2003) 117–140

125

3.2.1. Disruption of natural flow Design can be viewed as a creative, emergent process, complete with its own rhythms and pacing that are part of the natural flow of activities. Disrupting this flow can occur in many ways, all of which are frustrating to the user. For example, design rationale tools attempt to structure the design process according to their internal representation. When using these tools, the natural flow of the discussion is redirected as the team is guided to address specific concerns (e.g. enumerating all options before evaluating them). Design is not a linear, monotonic process. Often multiple options and contradictory decisions need to be carried forward or a promising path ends up being a dead end. Many tools, however, do not support inconsistencies in their representations. For example, the physical model represented in a CAD system generally needs to be one that is possible in 3-D space. Similarly, capacity models used in decision support often balk at having oversubscribed resources or implausible configurations. In these situations, tools will often disrupt the design process by forcing the premature resolution of conflicts or contradictory representations. Other disruptions occur when users need to switch context (e.g. from working in a CAD package on a UNIX workstation to reading a document in Microsoft Word on a PC), enter large volumes of historical data, backtrack to a previous decision point, or slow down to match the input speed of the tool. 3.2.2. Role alterations Implicit in any tool design is the assumed division of labor between the tool and the user. Entering meta-data, a common requirement for most document management systems, is a time-consuming effort that can be viewed as relegating the user to the role of an input device, strictly for the benefit of the system. This is particularly annoying since much of the meta-data information already exists embedded in the documents themselves (e.g. title pages; Microsoft Word “properties”), so meta-data entry constitutes a duplication of effort by the user, despite characterizations as “minimal” by the designers. Subjugating the user to the tool can also occur due to policy implementation. For example, one of the knowledge systems developed by the author consisted of a series of self-help questions in technical disciplines related to spacecraft development (Cooper, 2003). While users agreed that the knowledge available through the tool was valuable, they expressed serious concerns that management would turn it into a checklist of items that had to be formally addressed, thereby turning a tool intended as an “advisor” into a regulatory system. Tools can modify the overall work roles for a team by requiring a new function. For example, decision rationale capture systems often assume that a person skilled in the use of the system is available to either facilitate the session, or act as an observer capable of capturing information in the background. These assumed roles are problematic because to understand and quickly categorize design rationale usually requires skills in both the operation of the tool and in the design domain. Recognizing important assumptions, task-related conflicts, key issues, or even when a new option is introduced assumes a sophisticated understanding of the design domain, especially difficult in teams with greater cross-functionality. Unfortunately, the people capable of rapidly assessing these characteristics would generally prefer to participate in the discussion rather than capture the discussion. Therefore, the roles implicit in the use of design rationale tools are inherently difficult to fill. To paraphrase an old saying, those who can want to do.

126

L.P. Cooper / J. Eng. Technol. Manage. 20 (2003) 117–140

Role-related problems also occur when a tool only performs part of a task that the user views as a chunk. For example, when a specialized modeling and simulation package only does part of an analysis, the user must then continue the effort manually. Similar problems arise when tools require significant effort to configure and input data. “It would have been easier to do the whole thing by hand” is a common complaint heard from users. Systems with these characteristics assign the user the roles of multi-system integrator and translation device. Significant gains in functionality are needed to justify the integration and front-loaded data entry effort required to make them work in the user’s context. 3.2.3. Context Part of the difficulty arises from the lack of contextual information available when the person is removed from part of an activity and but needs the insights to be gained from the whole for future decisions. A common experience with decision support systems, for example, is to determine the values for a number of input parameters, then obtain results by running a series of automated algorithms. The “answer” provided by the system often has to be taken on faith since the inner workings of the tools are not visible to the users. Therefore, when conditions change in a way that would alter the input parameters, the users do not have an intuitive feel for how the “answer” would change. In addition, when tasks are consolidated, important boundary objects (Star and Griesemer, 1989) based on intermediate products could be eliminated. A different set of problems occur when one wants to apply the results obtained on one effort to another, for example, when designers on one NPD team would like to use a component created by another team for a different application. While design systems may effectively capture the end design, as characterized by a solid model, parts list, and as-built drawings, they do not necessarily capture the information on how this part was used, the assumed operating environment, or the influencing factors in the design. Consider, for example, NASA’s Mars Observer spacecraft which was designed based on a series of successful Earth-orbiting spacecraft. Since these spacecraft had performed reliably during previous missions they were considered a good choice for the new spacecraft. Unfortunately, Mars Observer experienced a catastrophic failure during the cruise from Earth to Mars. The failure review board determined that “too much reliance [was] placed on the heritage of spacecraft hardware, software and procedures for near-Earth missions, which were fundamentally different from the interplanetary Mars Observer mission” (Savage and Gately, 1994). Context is important in understanding what information is relevant at a given time. NPD teams make tens of thousands of decisions relative to their designs. Having the right information is only valuable if it is at the right time. Too late and you miss the chance to incorporate the information, too soon and you will forget it—and attending to it runs the risk of diverting attention away from a more immediate need. It is difficult to determine relevance. NPD team members can usually relate a story of a painfully annoying meeting where some “clueless” person kept interjecting irrelevant information and asking “off the wall” questions. Relevancy in NPD can depend on a multitude of factors including: phase of development, project milestones, cost and schedule constraints, target market, expected operating environment, technology, overall architecture, intended end users, and skill level of the developer. Given that it is difficult for people to consistently determine relevance, it’s no surprise that computer systems also have difficulty.

L.P. Cooper / J. Eng. Technol. Manage. 20 (2003) 117–140

127

Internet search engine ranking algorithms, autonomous agents, and subscription services all attempt to provide the most relevant information to the end user. However, these utilities vary in their effectiveness, often returning significantly more irrelevant than relevant information. The well-documented problems associated with information overload (e.g. Alavi and Leidner, 2001; O’Reilly, 1980) become worse as the number of sources and potential hits increase. Retrieval systems are caught between using tightly focused search mechanisms that may miss important information and broader search strategies that return a lot of junk. Either way, the end user may miss key information because it is either not present or camouflaged by large volumes of irrelevant information. The user then must spend additional effort expanding the search or sifting through the returns. 3.3. Summary There are multiple ways in which existing tools can do more harm than good: by diverting attention, adding work, negatively impacting team dynamics, disrupting cognitive processes, reducing contextual cues, eliminating valuable intermediate products, adding to information overload, and creating difficult-to-fill roles. Approaches to information system development, such as socio-technical systems (Cherns, 1976), and participative design (Emery, 1993) provide methods to improve the effectiveness of tools and systems in the work environment. In addition to following those generally applicable principles, the following sections provide some guidance as to how to avoid these “frustration traps” by defining desired characteristics for knowledge management systems and collaborative tools (KMS/CT) to support NPD.

4. Characteristics of supportive KMS/CT The frustrations experienced by users of existing tools imply a set of desired characteristics for tools intended to support KM and collaboration for NPD. While these characteristics may apply beyond NPD, the following list was devised based on practical experience designing multiple NPD tools and systems, and in many cases, being forced to live with the results. Meeting these characteristics does not guarantee success, however, the likelihood of success decreases with their absence. These desired characteristics are organized based on the primary frustration traps they address. 4.1. Characteristics that reduce disruption of the work process Integrating KMS into the work processes requires both an understanding of human factors issues relative to tools and systems use and a sensitivity as to what constitutes a “disruption” in the NPD context. The following three characteristics address these concerns. 4.1.1. Design systems to integrate how KM and collaboration in NPD work are done As with any system, KMS to support NPD need to address human factors that will influence usefulness and usability. The system needs to be unobtrusive. When users are

128

L.P. Cooper / J. Eng. Technol. Manage. 20 (2003) 117–140

concentrating more on the features of the tool than on the work at hand, as can be found with design rationale systems, the tool is a distraction. The best tools integrate seamlessly into the work processes. Systems should minimize the required self-discipline of the users. If the utility of a system depends significantly on the conscientious, consistent, and timely attention of the users, it is almost always doomed. Users have their own immediate concerns, and given ever-increasing demands on their time, will routinely eliminate lower priority tasks (e.g. entering meta-data, uploading documents, making journal entries, updating a group calendar). Unless the imposed self-discipline yields huge benefits (or conversely, the lack yields huge penalties), then there is a high probability it will not get done. It is beneficial to engage the user. Systems that are pleasant to use and convey valuable information in a way that facilitates positive interaction (e.g. does not preach or treat the user as “non-thinking”) are more likely to be successful (Hassenzahl et al., 2001). For example, a system developed by the author encoded technical knowledge as questions to stimulate user thought processes and approximate the interaction obtained during a peer review (Cooper, 2003). Systems should use user-natural representations. An internal representation that is easy and intuitive for the end user to understand provides necessary context for users to support interpretation, extension, and adaptation. If the users understand how and why a result was achieved, they are more likely to trust it and rely on it, and it is therefore more valuable to them. For example, knowledge delivery systems that include an explanation of why an item was sent to the user help the user to both make better use of the information and understand the model the delivery system uses to determine individual relevance. Similarly, knowledge storage and retrieval systems that provide relational or network-based categorization, rather than strict hierarchical, are a better analog for how people relate concepts. Finally, the systems need to support a range of user skill levels. Users may range from novices to experts, with each category benefiting from different forms of interaction. Novice users benefit from teaching systems that provide guidance, detect mistakes or omissions, and make it easy to execute complex functions. These same features, under the guise of “user friendliness” would drive an expert user insane. The needs of experts are different, and a beneficial interaction is in the form of a partnership, with features that can be turned on/off, the ability to override safeguards, and opportunities for tailoring and short-cuts. The group that often gets ignored in usability analyses are the mid-level users who are neither novices nor experts. An ideal tool will help novice users become proficient quickly, help intermittent users remain proficient, and help routine users increase their expertise. 4.1.2. Enable users to work at multiple levels of abstraction The knowledge required to support NPD processes changes over the course of the effort. For example, Majchrzak et al. (in press) found that users engaged in three levels of search and analysis behavior: (1) scanning the environment to become aware of possible ideas; (2) conducting brief evaluations of ideas to determine if the idea is worth pursuing); and (3) conducting in-depth analysis of ideas. They conclude that knowledge management systems need to support access at each of these levels to facilitate innovation. In addition, NPD is a highly iterative process, so users may be rapidly switching between different levels of abstraction as part of their natural work process. It is imperative for KMS tools and systems to support this dynamic need for multiple layers of information.

L.P. Cooper / J. Eng. Technol. Manage. 20 (2003) 117–140

129

4.1.3. Have a great sense of timing It is important to provide relevant information when it is of most value, which implies that systems need to understand the user’s context well enough to: (a) determine what type of information would be relevant; (b) determine when it would be most relevant; and (c) be able to effectively match existing information to the target user. Knowledge delivery systems that learn about users are needed to provide customized delivery of highly relevant products. These delivery systems would determine what to deliver, in what form, when, and via what means. They would also provide information as to “why” they believe this information is relevant, giving the end users insight into the models used to determine relevance. Further, by making these models visible and adjustable by the user, knowledge delivery systems will facilitate user involvement in system learning. 4.2. Characteristic of beneficially altered user roles While change, in general, is often met with reluctance, changes that are of obvious benefit to the users should be met with less resistance. It is therefore important to understand what constitutes a “good” change from the point of view of NPD practioners. 4.2.1. Address the mundane, tedious aspects instead of the creative, fun aspects One explanation for the widespread success of CAD systems is that they eliminated the need for users to painstakingly (re)draw their designs. The creative aspect of design is still in the hands of the user. The mundane, tedious, time-consuming job of drawing multiple perspectives of that design is delegated to the tools. KMSs often generate tedious work (e.g. meta-data entry, file format translation) instead of eliminating it. In the case of meta-data entry, for example, it would be beneficial for the KMS to automatically upload and extract the meta-data from documents, since the necessary information is embedded in the document itself (e.g. author, generation date, title), or in its location on the person’s local computer (e.g. categorical information based on where in their file system the users store their files). There are a number of non-fun activities such as keeping track of details and commitments, keeping people informed, staying informed, paying attention to due dates, assembling packages (e.g. all the files and input data associated with running a particular simulation or all the emails associated with a given design problem), and meeting records retention requirements that KMSs could support. 4.3. Characteristics to support contextualization The importance of context in NPD manifests itself in many ways: to identify what is relevant and when, as cues to help locate information or focus attention, and as the common ground which enables communication across thought worlds. The following three characteristics address these contextual issues. 4.3.1. Address context needs It is important to provide enough cues so that people can apply and extend the content or results to different circumstances. Knowledge assets are rarely applied without some degree of adaptation to the new environment, especially when innovation is the goal. Basic

130

L.P. Cooper / J. Eng. Technol. Manage. 20 (2003) 117–140

approaches to support adaptation include providing files in native, manipulable formats, attaching input parameter or configuration data to the output of models/simulations, including meta-data, and providing a point of contact. While information on “what it is” is important for replication, additional information on “why it is” is required to understand how to adapt something for a new environment or application. Contextual information supports learning, reuse, and accurate interpretation of a given set of circumstances. KMSs can play an important role in both the original capture of contextual information and in making this information available in a useful form. For example, KMSs could integrate context capture with the creative work. Automated meta-data generation (discussed above) is one option. Another is to initiate a query to the worker after the completion of a body of work to gather information such as what were the main changes, why were they done, what was difficult, and who would be interested in these changes. Voice entry could make this easier for the user. 4.3.2. Provide multi-path connectivity and multi-criteria control for information access There are multiple inter-relationships between different knowledge objects in an NPD environment, and many different perspectives that individuals have, based on the role(s) they play on the project. A valuable function that could be performed by KMSs is to develop a rich, highly connected representation of the body of knowledge associated with an NPD project. By automatically cross-referencing along multiple dimensions, KMSs could provide an environment in which users can easily browse their way to the information they need. Improved ability to share information, however, carries with it a responsibility to ensure that information is shared appropriately. It is desirable to have KMSs that can accurately determine access privileges for an individual based on the variety of group memberships and categories to which that individual belongs. From the perspective of those responsible for protecting information, it is desirable to specify categories of people rather than have to address each person individually. The hassles associated with setting up individual profiles can result in over-restriction of information. 4.3.3. Facilitate communication across “thought worlds” Barriers to effective communication abound in new product development. In addition to well-documented difficulties between research, marketing, and manufacturing communities (e.g. Dougherty, 1992), there are numerous interfaces internal and external to the project team that can function as potential boundaries. Some NPD tools, such as the 3-D models produced through CAD packages greatly improve the ability of the team members to visualize the end product, thereby bridging multiple thought worlds. The products of knowledge capture systems for design rationale (e.g. decision maps) could also serve as boundary objects (Star and Griesemer, 1989) to facilitate communications. Outputs that not only support the work at hand, but also help communicate results to others, provide value in multiple ways. Whether it’s the production of the object (e.g. a decision map) or translation of the object (e.g. file format, actual form of presentation such as text-to-graphics or summarizations versus details), knowledge management systems can play a critical role in spanning boundaries. Table 4 compares the collaborative and KM tools to the desired characteristics listed above. It is clear that no tool is able to do it all, yet. Even worse, many of the tools that

Table 4 Comparison of KMS/CT tools with desired NPD tool characteristics Category

Multiple levels of abstraction

Address mundane and tedious aspects

Provide context

Sense of timing

Connectivity and access control

Thought worlds

(−) Often require special environment different from routine use; (−) obtrusive; (−) requires self-discipline

(−) Usually specialized to individual task

(−) Not usually captured; (+) traceability could provide some context

(+) Some rippling of changes; (−) limited to changes internal to the tool environment

(−) Individuals need copy of application; (−) rudimentary userID/password for access control

(×) Depends on nature of what’s being authored and who participates

Work product management

(−) Highly dependent on self-discipline; (+) can manage variety of user documents in native forms

(+) Relational systems allow grouping of documents; (−) does not produce summaries, comparisons

(−) Generally more work than word processor; (+) can provide auto indexing, cross-referencing, and ripple changes (−) Creates tedious work

(−) Only what is captured in meta-data

(−) Subscription services return lots of junk; (−) limited to keyword-type searches

(−) Primarily passive system requiring user to select items to view

Groupware

(−) Requires self-discipline and can be obtrusive; (+) email highly effective for variety of communication needs

(+) Can address individuals, groups; (+) support work at different levels; (+) often provides summaries, threads; (−) highly dependent on facilitation

(−) Technology related coordination requirements e.g. videoconference; (+) can reduce reliance on synchronous communication; (+) record of meetings

(−) Lack of visibility into local conditions; (+) usually provides record of group activities . . . ; (−) . . . but in raw, difficult to use form

(−) User adapts to technology; (+) ease of sending, retrieving messages, e.g. email

(−) Rudimentary userID/password for access control; (+) when open, facilitate sharing; (−) little cross-repository connectivity; (+) can include links to other resources (−) Rudimentary userID/password for access control; (−) Need for high-end technology (e.g. video conferencing)

(−) Specialized to individual problems; (−) difficult to extend results to change in problem

(−) Generating data inputs is tedious; (+) automated analysis and presentation

(−) Does not capture context info, e.g. when deciding on input values

(+) Some support for embedding rationale at different levels; (+) paradigm works at multiple levels; (−) highly dependent on facilitation (−) Usually specialized resource with content at specific level; (+) some resources have summarization, context

(−) Requires highly skilled facilitator; (+) tracks details

(+) Purpose is to capture context; (−) highly dependent on facilitator; (−) some context, e.g. conflicts, difficult to capture (×) Depends on resource; (−) usually limited to meta-data

(−) Single point design that is difficult to adapt to new types of conditions; (+) within predefined context, works well; (−) user initiated (−) Does not deliver data (passive viewing of data, only)

Knowledge management systems Decision support (−) Algorithms not systems user-natural; (−) susceptible to “garbage-in” problems

Design rationale tools

Knowledge resources

(−) Highly obtrusive in structuring work process; (−) limited vocabularies do not capture full richness of user representations (×) Depends on individual resource

(×) Depends on individual resource; (−) can create large volume of material to sift through

(−) Push and pull systems either do not deliver enough or deliver too much; (+) some success with intelligent agents and new search techniques; (−) user context rudimentary

(+) Facilitates overall communication; (−) media richness can be an issue

(−) Often treated as black box with strict access control

(×) Depends on nature of decision process

(−) Representation via proprietary formats; (−) access to tool is limited; (+) some have web visibility

(+) Product serves as boundary object

(−) Usually no cross-resource connectivity; (−) each resource has own access control via userID/password

(×) Depends on nature of resource

L.P. Cooper / J. Eng. Technol. Manage. 20 (2003) 117–140

Integrate how KM in NPD is done

Collaborative tools Authoring

(−): negative effect; (×): neutral effect; (+): positive effect.

131

132

L.P. Cooper / J. Eng. Technol. Manage. 20 (2003) 117–140

are intended to help may actually have a negative impact and serve to increase risk by delaying work processes, injecting useless or misleading information, creating opportunities for misunderstandings, distracting team members, or imposing overhead. While there is potential benefit to be gained from meeting the desired characteristics, developers would do well to at least (borrowing from the medical community) do no harm. Knowledge management systems and collaborative tools have the potential to address many of the problems of new product development. Unlike other tools which represent extensions of capacity or functionality beyond the intended user, KMS/CTs work to introduce pertinent knowledge to and facilitate decision making processes. They serve to inform the user and instigate learning via knowledge transfer and reuse (the process by which an entity is able to locate and use shared knowledge, Alavi and Leidner, 2001). As such, KMS are uniquely positioned to support risk reduction strategies in NPD, provided they avoid the “frustration traps” identified above.

5. Proposed research agenda The framework for the proposed research agenda is provided by the model in Fig. 1. The underlying assumption in the application of KMS/CT to NPD is that these systems will have a positive effect on the NPD processes, which will in turn lead to improved NPD performance. However, the frustrations identified in this paper result in decreased effectiveness of KMS/CT, which negates the positive relationship between KMS/CT and NPD, and has a negative effect on performance. Finally, it is proposed that systems that have the desired characteristics will over come the “frustration traps” and have a more positive effect on NPD processes and performance. There is very little evidence to support any of the links in this model, although practioners are continuously working under the assumptions embedded in it. So, while the challenges facing practioners are to build “better” tools, research is needed to identify what “better” means, how to accomplish it, and how to evaluate it. The following series of research questions are posed in an attempt to focus research efforts on areas that would be of direct benefit to practioners creating knowledge management systems and collaborative tools to support risk reduction in new product development.

Fig. 1. Model of KMS/CT–NPD interaction.

L.P. Cooper / J. Eng. Technol. Manage. 20 (2003) 117–140

133

Question 1. How can emergent knowledge be captured without harming it? New product development is an emergent knowledge process (EKP, Markus et al., 2002) in which team behaviors, shared understanding, and eventually, a product emerge. This occurs, for example, as options are created and evaluated, requirements and constraints become better understood, interactions and relationships surface, new ideas are integrated, non-productive ideas are culled, the “hard” versus “easy” parts become apparent, evaluation criteria get refined, strengths and weakness of the team and the design are learned, and the collective experiences of the team build or reduce confidence. There is a rhythm to design and development activities that both drives and is driven by the team, as influenced by external factors. The introduction of new tools and systems into NPD processes is generally done with the intention of improving the process (e.g. faster, less expensive) and/or improving the product. It is possible, however, that in the process of moving the work forward more quickly, a tool does not allow for the development of necessary understanding. Or, that by miscuing convergent and divergent processes, a tool encourages premature commitment, over-optimization, or undesirable compromises. Or, by focusing prematurely on constraints, it eliminates valuable options too soon. The research challenge is to discover how to support the emergent knowledge process (e.g. decision rationale, intermediate products, feedback to team on performance and behavior, injecting useful information) without harming it. Markus et al. (2002, p. 206) propose six design principles to support EKPs: (1) design for customer engagement by seeking out na¨ıve users; (2) design for knowledge translation through radical iteration with functional prototypes; (3) design for off-line action; (4) integrate expert knowledge with local knowledge sharing; (5) design for implicit guidance through a dialectical development process; and (6) componentize everything, including the knowledge base. Understanding the nature of the process, the natural transitions between divergent and convergent behaviors, and what constitutes a desirable versus harmful interruption or redirection, contingent on the nature of the team and the phase of the process, will lead to a better understanding of how to build supportive tools and systems. Question 2. What constitutes relevant knowledge and how can it be evaluated? For knowledge management systems the list of desired characteristics discussed in the previous section lead to a focus on the area of relevance. Relevance issues surface at multiple points in NPD: categorization when the “knowledge” is created, understanding of the work processes to interpret the potential user’s context, evaluation of individual pieces of knowledge given the user’s context, and establishing relationships between items based on different dimensions of similarity. The clearest, most accessible insights into background and context exist at the time an item is created, so the front-end challenge is to capture this context as effectively as possible, given incomplete understanding of all the ways this content may be valuable to future users. Relevance is easy to recognize when it occurs: it is the right knowledge presented at just the right time and in the right way to positively impact a decision-making process. Relevant information illuminates possible mistakes, enables intuitive leaps, provides confirmatory

134

L.P. Cooper / J. Eng. Technol. Manage. 20 (2003) 117–140

(or contradictory) evidence, and focuses attention on important issues. Predicting what information will prove to be relevant is much more difficult. The research challenges are to: (a) identify the contextual factors that affect relevance; (b) characterize how these can be used to determine relevance; and (c) develop methods for applying these factors across a variety of NPD situations. Since the injection of knowledge from outside the project can be vital to support innovation under constrained conditions (Majchrzak et al., in press), understanding how to infer contextual information about the content in general knowledge sources is critical. Research in the area of knowledge discovery (Gordon and Lindsay, 1996) could inform this question. Question 3. How do different knowledge delivery factors impact NPD effectiveness and under what conditions? A variety of methods exist to deliver the content of knowledge management systems to users, which can be categorized based on who initiates the exchange (push versus pull systems), the degree to which delivery is embedded in the work process, the level of attention demanded from the user, and degree to which the recipient can interact with the knowledge. Two paradigms for initiation are push, where the system initiates the interaction and “pushes” the information to the recipient, and pull, where the recipient makes the request. A subscription service can be seen as a hybrid approach where the user requests the information a priori, and the system pushes the information when it determines it has a match to the request. When delivery is embedded in the work process, the knowledge is automatically used; otherwise the user must explicitly integrate this knowledge with their own. For example, consider different approaches to spell-checking. A system that automatically determines when a spelling error occurs, identifies the correct spelling, and replaces the erroneous word with the correct one is an example of an embedded delivery system. One which requires the user to catch errors via proof-reading, then physically use a dictionary to find the correct spelling uses the same types of knowledge sources (dictionaries, basic rules of grammar), but delivery of the knowledge is not embedded in the work process. The level of attention demanded from the user refers to the cognitive focus the user must give to the information being delivered. For example, a spell-checker that simply highlights the incorrectly spelled words but allows the user to continue is less demanding than a system (e.g. command line interfaces) that beeps or flashes when an error is made and will not allow the user to move forward without entering a correct character string. Finally, delivery options must consider the degree to which the recipient can interact with the content. Once again using the spell-checker example, can the user suggest alternate spellings, make new entries in the dictionary, instruct the system to ignore a rule, or create new rules? The examples in the preceding discussion imply computer-based delivery, but other technologies (e.g. pagers) or human-delivery are also viable options, and may in some cases be preferred. Regardless of the delivery mechanism, issues of what gets delivered (e.g. the actual content, meta-data about the content), how that information is structured (e.g. as a rule, fact, question; Cooper, 2003), and when the information is delivered must be addressed. Under what circumstances are the use of multiple delivery methods and attempts desirable?

L.P. Cooper / J. Eng. Technol. Manage. 20 (2003) 117–140

135

The research challenge is to better understand how the structure, content, timing, and delivery method characteristics of relevant knowledge interact with the NPD process to impact effectiveness. Are different types of knowledge better suited for one style of delivery than another? What is the impact of using multiple delivery paths? When does it help to see the same basic information in multiple formats, multiple times, versus becoming a nuisance? Further, what constitutes successful delivery from information systems, NPD, and cognitive perspectives? Question 4. How can knowledge management systems be integrated into collaborative tools? Collaborative technologies offer the potential for greatly improved productivity, quality, and efficiency of group work (Nunamaker et al., 1997). Adding a knowledge management system component, however, essentially adds a new and very different member to the team. Because this team member may suffer from handicaps such as an inability to learn, a lack of social awareness, or an overly narrow or overly broad set of domain knowledge, it can be extremely difficult to integrate this new player. For example, Mark (2002) has identified the need for groups doing electronic work to adopt conventions—agreements among group members on methods for local control of the system for performing work. While her work focuses on regulating the use of shared objects (e.g. storage and retrieval of documents), analogous issues arise when considering shared knowledge, including conventions for how and when to share uniquely held knowledge. Postrel (2002) differentiates specialist capability and trans-specialist understanding, which he concludes are substitutable for each other. A knowledge management system could be used to represent the detailed specialist knowledge lacking in the trans-specialist team, or the big picture understanding lacking in the specialist view. Postrel suggests that it is important to develop a strategy to connect “islands of shared knowledge”. The research challenge is to better understand the ways in which KMSs could be integrated into collaborative tools, given that the KMSs represent a new and substantially different player on the team, that nonetheless needs to fulfill a given role within the social structure of the team. Question 5. What types of risks and opportunities do the use of knowledge management systems introduce in NPD, beyond those of any new tool or system? While the use of any new tool or system represents additional risk to a project (e.g. due to learning curves, performance issues, interpretability of results), the aim of a knowledge management system is to inject relevant knowledge into the work process. Therefore, the risk is not confined to the use of the tool; it instead encompasses all the ways in which the knowledge can be applied throughout the project. Knowledge management systems represent a uniquely robust way to introduce noise into an already chaotic process. The injection of irrelevant or false information can divert attention from important tasks, force users into an information overload situation, consume valuable resources (e.g. project member time) and reduce sensitivity to key issues. There are also risks associated with misunderstanding, and therefore, misusing knowledge out of

136

L.P. Cooper / J. Eng. Technol. Manage. 20 (2003) 117–140

context. KMSs could reinforce availability and recall biases (e.g. Tversky and Kahneman, 1974), thereby inspiring unwarranted confidence in a decision. The use of knowledge systems requires users to become more sophisticated in their understanding of how knowledge is generated and the potential problems associated with secondhand use. Issues of knowledge reliability, level of abstraction, limitations of scope, generalizability, obsolescence and warranty must be explicitly addressed, and the risks of not attending to these issues better understood. The increased availability of knowledge raises interesting questions about the liability of not using knowledge that was available. As companies build up knowledge systems incorporating lessons learned, parts advisories, performance characterizations, recall notices, etc., they are also making an implied commitment to adequately apply that knowledge to their product development processes. Given the huge volume of information potentially applicable to an NPD project, it is probable that a key piece of information that could prevent a product failure will not be searched for, recognized if found, or actually used by a project. If a product failure does indeed occur, what is the impact on the company? What is a reasonable standard of good faith in using knowledge resources, given that it is much easier to determine relevance after the fact? What are the risks to projects and companies not meeting this standard? The existence of knowledge systems and their use in NPD projects pose unique risks for individuals, projects, and organizations. The research challenge is to understand and characterize these risks, and develop methods to mitigate and manage these special risks. Furthermore, it is critical to develop reasonable standards of good faith use, and understand how to build systems that help users to attain those reasonable standards. Question 6. How can the impact of knowledge management systems on NPD be effectively evaluated? If knowledge management systems are intended to improve the efficiency and effectiveness of NPD efforts, how can the changes attributable to the introduction and use of these systems be identified and measured? Brown and Eisenhardt (1995) identify multiple approaches to measure of NPD success organized by financial success (e.g. profits, revenues, market share), perceptual success (team and manager ratings), and operational success (speed and efficiency). Given the variety of factors affecting NPD outcomes, making the connection between a single change and overall performance is difficult. Practical approaches to assessing the organizational value of KMSs include user feedback and surveys, usage statistics, evaluating price-points for how much a group is willing to pay to use a system, user advocacy for continued organizational support for maintenance and further development, and the “classic” approach of shutting down the system to see who screams. While these approaches provide anecdotal evidence to support immediate organizational decision making, they do not add to our understanding of how these systems change the process, why these changes occur, what influences the change process, and how it effects performance measures. The research challenge is to develop testable theories for how KMSs impact new product development, operationalize relevant system and performance variables, and systematically test the relationships.

L.P. Cooper / J. Eng. Technol. Manage. 20 (2003) 117–140

137

6. Concluding remarks New product development is a people- and knowledge-intensive effort whose success is critical to the survival of companies. The tools and systems intended to improve this process have had mixed results in terms of user acceptance and NPD process and product performance. This paper first presented a description of the types of frustrations encountered in the use of tools to support NPD. It then described the characteristics of ideal tools based on practioner experience, focusing on knowledge management systems and collaborative tools. Finally, it presented a series of research challenges whose results would address practioner issues and specific NPD risks. It is clear that there are a wide range of issues that cross-academic discipline boundaries. Efforts to answer the research challenges will therefore face many of the same problems of new product development: differing thought worlds and vocabularies, an inability to predict what information is needed a priori, a vast solution space to explore, limited time and funding, and a high probability of failure. The potential benefits, however, are extraordinary, and the journey could be a lot of fun.

Acknowledgements The work leading to the ideas presented in this paper was performed in part at Stanford University, sponsored by NSF Grant #DMI-9996081, and at the Jet Propulsion Laboratory, California Institute of Technology, under contract with the National Aeronautics and Space Administration. The author is grateful to the editors for their helpful comments on this article.

References Adler, P.S., 1995. Interdepartmental interdependence and coordination—the case of the design/manufacturing interface. Organization Science 6 (2), 147–167. Alavi, M., Leidner, D.E., 2001. Review: knowledge management and knowledge management systems: conceptual foundations and research issues. MIS Quarterly 25 (1), 105–136. Allen, T.J., 1977. Managing the Flow of Technology. MIT Press, Cambridge, MA. Ancona, D.G., Caldwell, D.F., 1992. Demography and design: predictors of new product team performance. Organization Science 3 (3), 321–341. Ancona, D.G., Caldwell, D.F., 1998. Rethinking team composition from the outside in. In: Gruenfeld, D.H. (Ed.), Research on Managing Groups and Teams, vol. 1. JAI Press, Stamford, CT, pp. 21–37. Argote, L., 1999. Organizational Learning: Creating, Retaining, and Transferring Knowledge. Kluwer Academic Publishers, Norwell, MA. Armbrecht, F.M.R., Chapas, R.B., Chappelow, C.C., Farris, G.F., Friga, P.N., Hartz, C.A., McIlvaine, M.E., Postle, S.R., Whitwell, G.E., 2001. Knowledge management in research and development. Research-Technology Management 44 (4), 28–48. Balachandra, R., Friar, J.H., 1997. Factors for success in R&D projects and new product innovation: a contextual framework. IEEE Transactions on Engineering Management 44 (3), 276–287. Brown, S.L., Eisenhardt, K.M., 1995. Product development: past research, present findings, and future directions. Academy of Management Review 20 (2), 343–378.

138

L.P. Cooper / J. Eng. Technol. Manage. 20 (2003) 117–140

Cardinal, L.B., Lei, D., 2000. Structuring research and development teams in the technological conversion process. In: Beyerlein, M.M., Johnson, D.A., Beyerlein, S.T. (Eds.), Team Performance Management, vol. 6. JAI Press, Stamford, CT, pp. 31–62. Cherns, A.B., 1976. Principles of sociotechnical design. Human Relations 29, 783–792. Clark, H., 1996. Using Language. Cambridge University Press, Cambridge. Cohen, S.G., Bailey, D.E., 1997. What makes teams work: group effectiveness research from the shop floor to the executive suite. Journal of Management 23 (3), 239–290. Cohen, W.M., Levinthal, D.A., 1990. Absorptive capacity: a new perspective on learning and innovation. Administrative Science Quarterly 35, 128–152. Cooper, L.P., 2003. The power of a question: a case study of two organizational knowledge capture systems. In: Proceedings of HICSS-36, Big Island, HI, Institute of Electrical and Electronics Engineers, New York. Cordero, R., Farris, G.F., DiTomaso, N., 1998. Technical professionals in cross-functional teams: their quality of work life. Journal of Product Innovation Management 15 (6), 550–563. Couger, J.D., 1996. Creativity and Innovation in Information Systems Organizations. Boyd & Fraser, New York. Dougherty, D., 1992. Interpretative barriers to successful product innovation in large firms. Organization Science 3 (2), 179–202. Dvir, D., Lipovetsky, S., Shenhar, A., Tishler, A., 1998. In search of project classification: a non-universal approach to project success factors. Research Policy 27, 915–935. Dyer, J.H., Noveoka, K., 2000. Creating and managing a high-performing knowledge-sharing network. Strategic Management Journal 21, 345–367. Dyer, B., Song, X..M., 1998. Innovation strategy and sanctioned conflict: a new edge in innovation? Journal of Product Innovation Management 15 (6), 505–519. Emery, F.E., 1993. Characteristics of sociotechnical systems. In: Trist, E.L., Murray, H. (Eds.), The Social Engagement of Social Science: A Tavistock Anthology, vol. II. The Sociotechnical Perspective. University of Pennsylvania Press, Philadelphia, PA. Fox, J., Gann, R., Shur, A., Von Glahn, L., Zaas, B., 1998. Process uncertainty: a new dimension for new product development. Engineering Management Journal 10 (3), 19–27. Gerwin, D., Moffat, L., 1997. Withdrawal of team autonomy during concurrent engineering. Management Science 43 (9), 1275–1287. Gobeli, D.H., Koenig, H.F., Bechinger, I., 1998. Managing conflict in software development teams: a multilevel analysis. Journal of Product Innovation Management 15 (5), 423–435. Gordon, M.D., Lindsay, R.K., 1996. Toward discovery support systems: a replication, re-examination, and extension of Swanson’s work on literature-based discovery of a connection between Raynaud’s and fish oil. Journal of the American Society for Information Science 47 (2), 116–128. Hassenzahl, M., Beu, A., Burmester, M., 2001. Engineering Joy. IEEE Software (January/February), pp. 70–76. Jehn, K.A., 1995. A multimethod examination of the benefits and detriments of intragroup conflict. Administrative Science Quarterly 40 (2), 256–282. Karlsson, C., Åhlström, P., 1999. Technological level and product development cycle time. Journal of Product Innovation Management 16 (4), 352–362. Katz, R., 1982. The effects of group longevity on project communication and performance. Administrative Science Quarterly 27, 81–104. Katz, R., Tushman, M., 1979. Communication patterns, project performance, and task characteristics: an empirical evaluation and integration in an R&D setting. Organizational Behavior and Human Performance 23, 139–162. Keller, R.T., 1986. Predictors of the performance of project groups in R&D organizations. Academy of Management Journal 29 (4), 715–726. King, N., Majchrzak, A., 2002. Technology alignment and adaptation for virtual teams involved in unstructured knowledge work. In: Gibson, C.G., Cohen, S.G. (Eds.), Creating Conditions for Effective Virtual Teams. Jossey-Bass, San Francisco. Larson, E.W., Gobeli, D.H., 1989. Significance of project management structure on development success. IEEE Transactions on Engineering Management 36 (2), 119–125. Lynn, G.S., Akgün, A.E., 1998. Innovation strategies under uncertainty: a contingency approach for new product development. Engineering Management Journal 10 (3), 11–17. Majchrzak, A., Cooper, L.P., Neece, O., in press. Knowledge reuse in the radical innovation process at the Jet Propulsion Laboratory. In: Leibowitz, J., Holm, J. (Eds.), Knowledge Management Technologies and Applications in NASA. Government Printing Office, Washington, DC.

L.P. Cooper / J. Eng. Technol. Manage. 20 (2003) 117–140

139

Mankin, D., Cohen, S.G., Bikson, T.K., 1996. Teams and Technology: Fulfilling the Promise of the New Organization. Harvard Business School Press, Boston, MA. March, J.G., Shapira, Z., 1987. Managerial perspectives on risk and risk taking. Management Science 33 (11), 1404–1418. Mark, G., 2002. Conventions and commitments in distributed CSCW groups. CSCW: The Journal of Collaborative Computing, Special Issue on Awareness 11 (3–4), 349–387 . Markus, M.L., 1994. Electronic mail as the medium of managerial choice. Organization Science 5, 502–527. Markus, M.L., Majchrzak, A., Gasser, L., 2002. A design theory for systems that support emergent knowledge processes. MIS Quarterly 26 (3), 179–212. McComb, S.A., Green, S.G., Compton, W.D., 1999. Project goals, team performance, and shared understanding. Engineering Management Journal 11 (3), 7–12. McDonough, E.F., 2000. Investigation of factors contributing to the success of cross-functional teams. Journal of Product Innovation Management 17 (3), 221–235. McDonough, E.F., Barczak, G., 1992. The effects of cognitive problem-solving orientation and technological familiarity on faster new product development. Journal of Product Innovation Management 9, 44–52. McDonough, E.F., Kahn, K.B., Griffin, A., 1999. Managing communication in global product development teams. IEEE Transactions on Engineering Management 46 (4), 375–386. Moreland, R.L., Myaskovsky, L., 2000. Exploring the performance benefits of group training: transactive memory of improved communication? Organizational Behavior and Human Decision Processes 82, 117–133. Nahapiet, J., Ghoshal, S., 1988. Social capital, intellectual capital, and the organizational advantage. Academy of Management Review 23 (2), 242–266. Nunamaker, J.F., Briggs, R.O., Mittleman, D.D., Vogel, D.R., Balthazard, P.A., 1996–1997. Lessons from a dozen years of group support systems research: a discussion of lab and field findings. Journal of Management Information Systems, 13 (3), 163–207. O’Reilly, C.A., 1980. Individuals and information overload in organizations: is more necessarily better? Academy of Management Journal 23 (4), 684–696. 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. Paté-Cornell, M.E., Dillon, R., 1998. Challenges in the management of faster–better–cheaper space missions. In: Proceedings of IEEE Aerospace Conference, Snowmass, CO. Pelled, L.H., Adler, P.S., 1994. Antecedents of intergroup conflict in multifunctional product development teams: a conceptual-model. IEEE Transactions on Engineering Management 41 (1), 21–28. Perrow, C., 1981. Normal Accident at Three Mile Island. Society, (July/August), pp. 17–26. Pinto, M.B., Pinto, J.K., Prescott, J.E., 1993. Antecedents and consequences of project team cross-functional cooperation. Management Science 39 (10), 1281–1297. Postrel, S., 2002. Islands of shared knowledge: specialization and mutual understanding in problem-solving teams. Organization Science 13 (3), 303–320. Regli, W.C., Hu, X., Atwood, M., Sun, W., 2000. A survey of design rationale systems: approaches, representation, capture and retrieval. Engineering with Computers 16, 209–235. Rice, R.E., Rogers, E., 1980. Reinvention in the innovation process. Knowledge, Creation, Diffusion, Utilization 1 (4), 499–514. Savage, D.L., Gately, J., 1994. Mars Observer Investigation Report Released [Web Page]. Located at: http:// spacelink.nasa.gov/NASA.Projects/Space.Science/Solar.System/Mars.Observer/Mars.Observer.Status. Reports/94-01-05. Accessed 28 October 2002. Shapira, Z.B., Berndt, D.J., 1997. Managing grand scale construction projects: a risk-taking perspective. In: Research in Organizational Behavior, vol. 19. JAI Press, Stamford, CT, pp. 303–360. Shenhar, A.J., 1998. From theory to practice: toward a typology of project-management styles. IEEE Transactions on Engineering Management 45 (1), 33–48. Simon, H., 1957. Models of Man: Social and Rational. Wiley, New York. Song, X.M., Montoya-Weiss, M., 2001. The effect of perceived technical uncertainty on Japanese new product development. Academy of Management Journal 44 (1), 61–80. Song, X.M., Thieme, R.J., Xie, J.H., 1998. The impact of cross-functional joint involvement across product development stages: an exploratory study. Journal of Product Innovation Management 15 (4), 289–303.

140

L.P. Cooper / J. Eng. Technol. Manage. 20 (2003) 117–140

Souder, W.E., Sherman, J.D., Davies-Cooper, R., 1998. Environmental uncertainty, organizational integration, and new product development effectiveness: a test of contingency theory. Journal of Product Innovation Management 15 (6), 520–533. Star, S.L., Griesemer, J.R., 1989. Institutional ecology, ‘translations’, and boundary objects: amateurs and professionals in Berkeley’s museum of vertebrate zoology 1907-39. Social Studies of Science 19, 387–420. Steiger, D.M., 1998. Enhancing user understanding in a decision support system: a theoretical basis and framework. Journal of Management Information Systems 15 (2), 199–220. Susman, G.I., Ray, J.M., 1999. Test of a model of organizational contributors to product development team effectiveness. Journal of Engineering and Technology Management 16 (3-4), 223–245. Szulanski, G., 2000. The process of knowledge transfer: a diachronic analysis of stickiness. Organizational Behavior and Human Decision Processes 82 (1), 9–27. Tatikonda, M.V., Rosenthal, S.R., 2000. Technology novelty, project complexity, and product development project execution success: a deeper look at task uncertainty in product innovation. IEEE Transactions on Engineering Management 47 (1), 74–87. Tetlock, P.E., 1985. Accountability: the neglected social context of judgment and choice. Research in Organizational Behavior 7, 297–332. Thomke, S.H., 1998. Managing experimentation in the design of new products. Management Science 44 (6), 743–762. Tversky, A., Kahneman, D., 1974. Judgment under uncertainty: heuristics and biases. Science 185, 1124–1131.