Supporting Collaborative Process Knowledge Management in New Product Development Teams

Ž .Decision Support Systems 27 1999 213–235www.elsevier.comrlocaterdsw

Supporting Collaborative Process Knowledge Management inNew Product Development Teams

Balasubramaniam Ramesh 1, Amrit Tiwana )

J. Mack Robinson College of Business, Department of Computer Information Systems, Georgia State UniÕersity, Atlanta,GA 30303, USA

Abstract

Knowledge centric activities of developing new products and services are becoming the primary source of sustainablecompetitive advantage in an era characterized by short product life cycles, dynamic markets and complex processes. We

Ž .view new product development NPD as a knowledge-intensive activity. Based on a case study in the consumer electronicsŽ .industry, we identify problems associated with knowledge management KM in the context of NPD by cross-functional

collaborative teams. We map these problems to broad Information Technology enabled solutions and subsequently translatethese into specific system characteristics and requirements. A prototype system that meets these requirements developed tocapture and manage tacit and explicit process knowledge is further discussed. The functionalities of the system includefunctions for representing context with informal components, easy access to process knowledge, assumption surfacing,review of past knowledge, and management of dependencies. We demonstrate the validity our proposed solutions usingscenarios drawn from our case study. q 1999 Elsevier Science B.V. All rights reserved.

Keywords: Knowledge management; Collaborative product development; Organizational memory; Organizational learning; New productdevelopment; Knowledge management systems; Decision support systems; Process knowledge; Design rationale

1. Introduction

As we move further into the information age,knowledge is becoming a critical component of com-

w x w xpetitive success of firms 22 . Nonaka 50 observedthat, as markets shift, technologies proliferate, com-petitors multiply and products become rapidly obso-lete, successful companies are characterized by theirability to consistently create new knowledge, quickly

) Corresponding author. Tel.: q1-404-262-3823; fax: q1-404-651-3842; e-mail: [email protected]

1 E-mail: [email protected].

disseminate it, and embody it in new products andw xservices. In the post-industrial era, Quinn et al. 54

maintain that the success of a corporation lies moredeeply embedded in its intellectual systems, asknowledge based activities of developing new prod-ucts and processes are becoming the primary internalfunctions of firms attempting to create the greatest

w xpotential for a competitive advantage 20 . Iansiti andw xMacCormack 35 contend that the consumer needs

that a product should satisfy and technologies usedin the development of such a product can changeradically, even as the product is under development.This has necessitated a flexible product-developmentprocess where designers can continue to change and

0167-9236r99r$ - see front matter q 1999 Elsevier Science B.V. All rights reserved.Ž .PII: S0167-9236 99 00045-7

( )B. Ramesh, A. TiwanarDecision Support Systems 27 1999 213–235214

shape products even after their implementation hasw xbeen initiated 35 . The impact of the aforementioned

forces is witnessed most prominently in high-tech-Žnology environments, where according to a survey

w x.by National Research Council 14 , the cost ofdevelopment can account for up to 85% of the totalcost of the product. We posit that providing effectivedecision support by making knowledge about pastand current development efforts readily available andaccessible can make a significant contribution to-wards ameliorating this process. Iansiti and MacCor-

w xmack 35 suggest that as firms shift from a productcentric form to a knowledge centric form, supportthat enables continuous flow of information aboutstakeholder needs and evolving technologies can re-duce both the costs and time required for develop-ment.

w xBohn 8 observes that in dynamic environmentsand industries, knowledge about the process of prod-uct development is incomplete in the beginning anddevelops gradually over time, through various modesof learning. The process of design is characterized bycomplex deliberations about a series of interdepen-dent decisions that lead to design solutions. Based ona study of concurrent product development activities,

w xRamesh and Sengupta 56 observe that knowledgeabout these deliberations is typically lost as it is

w xnever recorded. Davenport and Prusak 20 suggestthat better knowledge of past, similar product devel-opment processes can lead to assessable efficienciesin product development and its consequent produc-tion. Such knowledge utilization is innately a collab-

w xorative process 1 . Here, collaboration refers to in-formal cooperative relationships that build a sharedvision and understanding. Neither within nor cross-firm utilization and transfer of knowledge can suc-ceed without effectively supporting collaborationw x18–20 .

This paper addresses the problems faced in theretention and maintenance of process knowledge that

Ž .is created in new product development NPD . Wedefine process knowledge as tacit and explicitknowledge about activities, steps, and procedures.Our research is based on the premise that currentproduct-development methodologies do not ade-quately address the capture and use of this knowl-edge. Since much of the formal and informal knowl-edge along with the context associated with it is lost

after the process is completed, development teamsare unable to leverage knowledge actualized by ear-lier teams. We address the creation and use of arepository of information and knowledge derivedfrom sources such as recorded decisions, text docu-ments, images, audio, and video specifically relatingto collaboration within teams.

The following section defines knowledge andidentifies various types of knowledge involved in thenew product-development process. We then examinethe role of information systems to support knowl-

Ž .edge management KM . We discuss NPD as aknowledge-intensive activity. Then we discuss char-acteristics of NPD by collaborative, cross-functionalteams, and identify the problems related to KM facedby these teams. In Section 6, we map the problemsin Section 5 to general solutions. Further, we trans-late these general solutions into specific KM systemrequirements. This is followed by a description ofthe functionalities of a prototype system designed tomeet these requirements. The functionalities of thesystem are described using scenarios derived from acase study on the development of a personal digital

Ž .assistant PDA . Here, we demonstrate the validityour proposed solutions using scenarios drawn fromour case study. We discuss related work in Section 8,and conclude with a discussion of our contributionsand directions for future research.

2. Toward a Definition and Understanding ofKnowledge

w xDavenport and Prusak 20 define knowledge as afluid mix of framed experience, values, contextualinformation, and expert insight that provides aframework for evaluating and incorporating new ex-periences and information. They suggest that it origi-nates and is applied only in the mind of knowersŽ .holders of tacit knowledge in organizations. It isembodied in documents, repositories, organizationalroutines, processes, practices and norms. Leonard-

w xBarton and Sensiper 42 point to the subtle differ-ence between knowledge and information suggestingthat knowledge in the business context comprises ofrelevant, actionable information that is partially based

( )B. Ramesh, A. TiwanarDecision Support Systems 27 1999 213–235 215

on experience. We differentiate process knowledgefrom process information in the sense that the formeris actionable.

2.1. Components of Knowledge

w xNonaka and Takeuchi 52 suggest that the corner-stone of the Theory of Organizational KnowledgeCreation is the substantiate distinction between tacitand explicit knowledge. Several researchersw x18,20,50 , define tacit knowledge as personal, con-text specific knowledge that is difficult to formalize,record, articulate, or encode. Leonard-Barton and

w xSensiper 42 , extending Polyani’s concept of tacitknowledge from an individual to a group level,showed that the tacit knowledge is mainly developedthrough a process of trial and error encountered inpractice. Explicit knowledge on the other hand, canbe codified and transmitted in a systematic andformal representation or language. Nonaka and

w xTakeuchi 52 reduce knowledge creation to conver-sion of tacit knowledge to explicit knowledge, oftenachieved through externalization. Externalization,defined as the process through which experientialsubjective tacit knowledge is converted into objec-tive explicit knowledge, is often driven by metaphorsand analogy.

w xRuggles 59 suggests that KM creates value byactively leveraging know-how, experience and judg-ment resident within and outside an organization. Weposit that KM encompasses the activities surround-ing the integration of this knowledge from differentsources, in different forms, and maintaining it. Thekey to knowledge creation thus lies in the mobiliza-tion and conversion of this tacit knowledge into aform of explicit knowledge.

w xDavenport and Prusak 20 indicate that someknowledge is complex and initially tacit, but it can,

however, be externalized and embedded in a firm’sw xproducts and processes. Nonaka and Konno 51

point out that the cognitive dimension of knowledgethat shapes perception consists of beliefs, ideals,values, schemata and mental models that are deeplyingrained in participants and that these are oftentaken for granted by them. They further suggest thatsome, if not all, of this knowledge should be ex-tracted to retain context and fullness of the explicitcomponent.

3. The Role of Information Systems in ManagingKnowledge

The development of systems to assist in managingknowledge has been a topic of considerable interestw x51 . Nonaka and Konno suggest information sys-

Žtems can assist knowledge activists proponents and.champions of KM systems in serving as catalysts of

knowledge creation and as connectors of presentinitiatives with those in the future. Teigland et al.w x69 observe that facilities to capture, reuse, maintainand transfer knowledge are essential elements ofsuch a system. They suggest that such a channel forsupporting the demand for knowledge within an

w xorganization will be very valuable 69 . Davenport etw xal. 18 suggest three major categories of knowledge

repositories, as shown in Table 1. This paper isprimarily concerned with creating internal knowl-edge repositories. Whereas project management toolsallow for capture of formally structured knowledge,we focus on the processes underlying capture anduse of informal, internal knowledge including exter-nalization of tacit knowledge. To transfer tacitknowledge from individuals to a repository, Daven-

w xport et al. 18 suggest support for some form ofcommunity-based electronic discussion. A key fea-

Table 1Ž w x.Types of knowledge repositories based on Ref. 20

Type of repository Type of knowledge supported Examples

External knowledge Formal and informal Competitive intelligenceStructured, internal knowledge Formal Techniques, methods and reportsInformal, internal knowledge Informal Discussion databases, lessons learned


ture that would differentiate a KM support tool froma project management tool or organizational memorystore is its ability to capture and retrieve uncodified

w xor tacit knowledge. Hansen et al. 33 refer to thisstrategy as codification as opposed to personaliza-tion. Tacit knowledge, like explicit knowledge, can

w xalso become outdated 42 , hence invalid. Therefore,it is critical for a KM system to ensure the applica-

w xbility of tacit knowledge to the current situation 42 .

4. New Product Development as a Knowledge-in-tensive Activity

w xEder 24 suggests that much of the knowledge inNPD, such as knowledge about the strategic designapproach, and knowledge about tactics and methodsfor designing is primarily tacit. Several researchershave described NPD as a knowledge-intensive activ-

w xity 20,35,52,64 . NPD often involves cross-func-tional linkages, where different participants join ateam with differing viewpoints. Such teams are oftencharacterized by participants who achieve a highlevel of at-stakeness and synergy resulting from their

w xinteraction with other team members 36 . Morrisonw xand Kennedy 47 suggest that this interaction brings

in the need to organize, integrate, filter, condensew xand annotate 46 collaborative data and other rele-

vant information that these team members contribute.w xCourt 15 identifies three categories of knowledge

that product designers use in the process of develop-ing a new product.

Ž .1 General knowledge: Knowledge that peoplegain through everyday experiences and apply with-out regard to any specific domain that they might beworking in.

Ž .2 Domain specific knowledge: Knowledgegained through study and experience within a spe-cific domain. This is generally improved as the

Ž .person s involved in projects gain more experience.Ž .3 Procedural knowledge: Procedural knowl-

edge, the primary focus of this paper, is gained fromexperience of undertaking a task within the domain.

w xCourt 15 suggests that this is a combination of theabove two types of knowledge. In the NPD context,this includes knowledge about the processes throughwhich tasks are accomplished.

4.1. Codification Õs. personalization centric knowl-edge management

w xHansen et al. 33 have classified KM strategiesinto two distinct categories: codification and person-alization. The codification strategy is defined asbeing more reliant on computers and networks. Theysuggest that the value of codification lies in itsability to create economics of reuse. The goal of

w xsuch an approach, they suggest 33 , is that of con-necting people with reusable codified knowledge.Personalization, on the other hand, relies more onsocial networks that allow knowledge workers toshare tacit knowledge. They suggest that personaliza-tion creates value by connecting people with relevantknowledge. The role of technology in such KMimplementations is limited to that of enhancing so-cial communications networks.

ŽPrevious research in product development suchw x.as Refs. 35,64 suggests that product development

often builds upon an existing base product and rarelyw xbegins from scratch. Iansiti and MacCormack 35

discuss the case of Netscape Corporation’s browsersthat build on previous versions. Similarly, Song and

w xMontoya-Weiss 64 provide examples of incremen-tal products in several other industries. Further, per-sonalization and codification strategies are not mutu-ally exclusive, but can exist in combination eventhough the primary focus should be on one of thesew x33 . We, in concordance with Hansen et al.’s sug-

w xgestion 33 , therefore, posit that technology supportfor NPD must incorporate both these strategies;

Žhowever, the primary focus as also suggested inw x.Ref. 33 should be one of these two.

Procedural knowledge is experiential and includesexplicit aspects such as fundamental design concepts,criteria, specifications, theoretical tools, practical

w xconsiderations, and design instrumentalities 15 , aswell as tacit aspects which Davenport and Prusakw x20 suggest ‘‘reside in the minds of people’’ in anunarticulated format. Past design knowledge that canhelp product designers include both prescriptiveknowledge such as knowledge about the generalstrategic approach to design, knowledge about tech-

w xniques, and methods for designing 24 , or descrip-tive knowledge such as knowledge about design

w xprocesses and knowledge about working means 24 .Since a substantial portion of this knowledge is tacit,


we focus on the development of KM tools to supportthe creation of internal, informal knowledge reposi-tories containing such knowledge.

5. Knowledge Management in Collaborative newproduct Development

Collaboration is the centerpiece of product devel-opment processes. It is essential to distinguish be-tween collaboration and interaction for the purposeof distinguishing knowledge involved in the twoprocesses. While interaction refers to formal, transac-tional communication links, collaboration refers toinformal, cooperative relationships that build a sharedvision and understanding needed for conceptualizing

w xcross-functional linkages in NPD contexts 36 . Col-laboration is therefore imperative in knowledge gen-

w xeration and transfer 59 .In a well-managed development process, a ca-

cophony of perspectives foster creative abrasion,w xwhich Leonard-Barton and Sensiper 42 define as an

intellectual conflict, between diverse viewpoints thatproduces energy channeled into new ideas and prod-ucts. We observe that to enable a high degree ofcross-functional collaboration supporting the devel-opment of a shared vision and understanding is

w xcrucial. Jassawalla and Sashittal 36 state that incomparison a firm with low levels of collaboration inproduct-development teams, a firm with high levelsof such collaboration has an equitable distribution ofpower among participants. This results in intrinsi-cally motivated participants and synergistic out-

w xcomes. According to Ruggles 59 , managing knowl-edge in collaborative teams allows cross-fertilizationamong sources of internal expertise and creates net-works of knowledge workers within and outside theorganization.

5.1. Need for Managing Knowledge in Product De-Õelopment

w xDavenport and Prussak 20 suggest that innova-tion and speed to market that are essential for busi-ness success will become increasingly critical in the

w xfuture. According to Quinn et al. 54 , the intangiblesthat add most value to these activities are knowledgecentric. Most product development is moving to-wards team-based structures, since teams are be-

lieved to increase individual commitment and perfor-w xmance, and as Galegher et al. 29 observe, are more

effective in bringing a new product to the market ina short time-frame. As products and technologiesbecome increasingly complex, NPD requires effec-tive collaboration and synergistically integrated skillsof several individuals.

5.2. Research Methodology

We have used the case study method for datacollection and subsequent validation. Orlikowski and

w xBaroudi 53 have suggested that this method is bestsuited to understanding the interactions between in-formation technology related innovations and organi-

w xzational contexts. Yin 75 describes this techniqueas ‘‘an empirical inquiry that investigates a contem-porary phenomenon within its real life context, espe-cially when the boundaries between phenomenonand context are not clearly evident and it relies onmultiple sources of evidence’’. Yin suggests that asingle case study is appropriate where it represents acritical case or meets all criteria for testing a theory,or where it is a revelatory case. A single case allowsus to investigate the phenomenon in depth to providerich description and understanding as suggested byprevious case study methodological literaturew x w x17,53,75 . Darke et al. 17 caution that statisticalgeneralization is not the goal of case studies; deepinsight into dynamics of processes and situations,

w xhowever, is 17,53 . For these reasons, we believethat our use of a case study is appropriate as itprovides deep insights into knowledge related prob-lems, albeit limited in generalizablity to a specifictype of organization.

The problems associated with NPD are more pro-nounced in high-technology industries such as theelectronics industry. Firms in such industries faceconsiderably high rates of product obsolesce becauseof rapid advances in technology coupled with inten-

w xsive competitive pressures 73 . Further, Von Glinoww xand Mohrman 73 note that they also invest propor-

tionately larger sums into research and developmentwhile relying on rapid, efficient new product intro-

w xductions to remain competitive. Teece 68 highlightssectoral differences between process intensive high

Ž .technology industries such as electronics and tradi-Žtional process intensive industries such as chemi-


.cals . As shown in Table 2, high-technology prod-ucts often involve a high degree of design complex-ity, contextual dependency, limited intellectual rightsprotection and short product life cycles. Further, thedevelopment of high-technology products also in-volves complex collaborative processes where KM iscritical. For these reasons, our study has focused onNPD in the electronics industry.

5.3. DeÕeloping a Personal Digital Assistant: A CaseStudy

In this paper, we discuss a typical NPD process inthe consumer electronics industry, viz., the PDA, toillustrate the need for KM. Our observations arebased on a case study of one of the largest manufac-turers in the industry and on existing literaturew x12,38 . Our study of this NPD effort involved aseries of discussions with members of NPD teamsinvolved in the development of a PDA. The datafrom this case study is used in understanding thecharacteristics of the NPD process, the problems

Žfaced by NPD teams specifically, related to manage-.ment of process knowledge , and the requirements of

a KM system that can alleviate these problems, andfinally the development and validation of a prototypeimplementation of a system to support KM throughthe identification of typical scenarios of NPD activi-ties that can be supported by such a system. The useof such an approach to gain deep insight into thedynamics present in single settings is particularlyuseful when research and theory are at their early

w xformative stages 17 , as is the case with KM.

5.4. Characteristics of New Product DeÕelopment

A review of recent research suggests that collabo-rative NPD processes have several key character-istics that result in a variety of KM problems. In this

section we discuss the characteristics with examplesdrawn from our PDA development case study.

Ø Short product and process life cycles: Bettisw xand Hitt 6 observed that product life cycles in

certain markets have significantly shortened therebycompressing the available time window for recoup-ing the expenses associated with product develop-ment.

Time-to-market is considered a critical factor inthe development of a PDA. Iansiti and Macormackw x35 have demonstrated this for Internet products.The industry has experienced the introduction ofnearly twenty competing products, three real time

Ž .operating systems RTOs , convergence of function-ality of hand-held devices, palm devices, smallphones, and car communication systems within ashort time span of about 2 years. Frequent changes inthe RTOs, communication protocols supported, com-munication and computing hardware and software

w xare common in this market 12 .Ø Cross-functional collaboration: In order to re-

spond to competitive challenges, organizational unitshave become more closely coupled than in the past,often working in parallel to complete assignments

w xspanning traditional units 29 and functional areas.w xLeonard-Barton and Sensiper 42 suggest that cre-

ation of today’s complex systems and products re-quires merging of knowledge from diverse disci-plinary and personal skills-based perspectives wherecreative cooperation is crucial for innovation.

In the development of a consumer electronicsproduct, it is necessary to draw necessary expertisefrom a variety of functional areas including techni-cal, manufacturing and marketing. Specifically, thedevelopment of a PDA requires technical expertisefrom both hardware and software design and devel-opment. In the hardware category alone, experts inthe following areas are expected to work very closely:

Table 2Ž w x.Sectoral differences in knowledge for process intensive vs. high technology process intensive product development based on Ref. 68

Challenge Chemical industry Electronics industry

Recognition Manageable Extremely complex; often impossibleDisclosure Patents common More difficultInterface issues Not critical Compatibility with other components is generally criticalDependency of value on context Strong Very strongPatent protectionrreplicability High Sometimes very limitedDevelopment cycle Often long Generally extremely short


Ž .design of radio frequency RF devices, digital signalŽ .processing DSP , and printed circuit-board design.

Software development in communication protocols,DSP, and user interfaces need to be closely coordi-nated. The development process is characterized byintricate interdependencies among all these areas, aswell as with others such as manufacturing, market-ing, and packaging. Further, knowledge from otherindependent groups that have experience with par-tially similar subcomponent technologies, such asvoice paging is also needed.

Ø Cross-institutional collaboration: Besidesspanning multiple functional areas within an organi-zation, development of complex products also re-quires bringing together participants from across

w xmultiple collaborating organizations 1 . Expertiseand skills might be distributed both within and out-

w xside the developing organization 35 . Davenport andw xPrusak 20 suggest that this brings in the need to

facilitate knowledge growth, knowledge sharing anddissemination For example, in developing a PDA, itis common to employ outside expertise in special-ized areas such as DSP. Other examples of cross-in-stitutional knowledge required include knowledgeabout the protocols used by the organizations thatprovide the communications services for the product,

Žknowledge about the operating system itself such as.Windows CE , knowledge about the dimensions and

features of competing products, etc. Close collabora-tion among these cross-institutional teams, we be-lieve, is essential for product success.

Ø Transient existence of teams and high turnoÕer:In large projects, membership in development teamschanges over time and across phases. A major threatto the collective knowledge in organizations is per-sonnel turnover, since much of this knowledge is

w x w xsituated in the minds of individuals 66 . Carley 10observes that when there is no repository for knowl-edge other than personnel, turnover leads to reduc-tion in the organizational knowledge. Similarly,March observes growth of organizational code underconditions of low turnover and high socializationw x44 .

Rapid market growth and the specialized skillsnecessary are critical factors contributing to the se-vere shortage of qualified personnel and high turnoveramong PDA development teams. Further, membersof ad-hoc teams return to their organizational units

as their efforts are completed, causing loss of syn-ergy developed over the course of the project.

5.5. Problems In the New Product DeÕelopmentprocess

The above characteristics of NPD lead to a varietyof problems that suggest the need for better KM. Asbefore, examples from PDA development are used toillustrate these problems.

Ø Lack of shared understanding: Uncertainties inNPD processes lead to dependencies among andbetween different functional areas and require coop-eration to accomplish individual and joint objectivesw x w x64 . Szulanski 67 conjectures that the conse-quences of this problem are the lack of absorptivecapacity of the recipient, and the inability to contex-tually understand ‘‘best practices’’ in development.

This problem is very pronounced in the develop-ment of a PDA. The new PDA design calls for theunification of features typically found in a personalcomputing device and in a communication device —products traditionally designed and manufactured in-dependently. In addition to the traditional functionalbarriers that exist between marketing, design, pur-chasing, and manufacturing that can be observed inmost industrial organizations, the diversity of theexpertise needed to for NPD creates serious barriersfor shared understanding. As mentioned earlier, eventhe design team consists of experts from a widevariety of hardware and software disciplines. Thisproblem is exasperated as the degrees of freedom foreach of the teams is severely restricted due to con-straints on total cost of the product, its size, itsweight, appearance, and time-to-market. The teammembers drawn from different disciplines lack un-derstanding of the critical design factors for otherareas. For example, the designers of the computingplatform need to be aware of the signal interferenceproblems that various components can cause for theRF components.

Ø OÕerreliance on transmitting explicit ratherw xthan tacit design information 20,21,25,52 . Nonaka

w xand Takeuchi 52 have pointed out the importanceand value of recognizing and capturing tacit informa-tion — such as know-how, judgment and intuition,which make up a critical component of informationthat needs to flow between members collaboratingwithin a team. This highlights the need for a method


Žto effectively transfer such knowledge actionable.information in addition to explicit knowledge.

During the design and development of a PDA,participants from the manufacturing departmentmight not realize that on-board surface mount com-

Ž .ponent SMC chips cannot tolerate over a certainsoldering temperature during the process of manufac-turing. Though the hardware design group is wellaware of this through their chipset specification liter-ature, this knowledge was not shared with manufac-turing.

Ø Repeated mistakes: Organizations have beenfrustrated by reinventing solutions and repeating mis-takes due to their inability to identify or transferlessons learned from failures from one location toanother or one function to another. Transfer ofknowledge from failed projects to new ones couldsubstantially reduce the expenditure of resources and

w xeffort. Teece 68 suggests that innovations in prod-uct development involve a considerable degree ofuncertainty and that knowledge about failed ap-proaches is frequently forgotten, resulting in theirrepetition.

The designers of PDAs face a lot of uncertaintiesdue to the lack of de-facto ‘standards’ in the operat-ing systems and communication networks that theycan chose from. To spread the risks, parallel devel-opment for different platforms needs to be under-taken. For example, several PDA manufacturers makeproducts for both the Windows CE and Palm OSplatforms. Many of the problems encountered by thesoftware designers are common across these devel-opments. However, as the two groups come fromdifferent backgrounds and use different software de-velopment tools and platforms, the common mistakesmade by these teams are not readily shared. Simi-larly, the development of the communication compo-nents for the PDA shares similarities with the com-ponents in voice paging products. Past knowledgefrom the development of pagers such as designproblems and market reactions can be highly benefi-cial to the PDA development effort. However, as thedevelopment is done by different teams across inter-departmental boundaries, such knowledge is notreadily accessible.

Ø ReinÕention of solutions during product eÕolu-tion: Another problem in product development teamsis that they expend resources into solving problems

that might have already been solved either within oroutside their collaborative group. Based on empiricalobservations in software development, Ramesh and

w xSengupta 56 conclude that work groups often re-peatedly discuss the same issues that had been re-solved earlier, as there may exist no reliable recordof these discussions.

w xTeece 68 indicates that the annual aggregate‘reinvention’ costs in the United States range be-

w xtween US$2 billion and US$100 billion. Court 15offers support for the suggestion that product design-ers often tend to use the incomplete information theyalready possess, rather than seek expertise that doesexist within the enterprise or is external to it.

In the organization where our case study wasdone, the design team involved in the developmentof a successful product has often been moved to thenext high-profile project when the previous projectwas near completion. The expertise gained duringdevelopment of a product is not readily available todesign teams working the subsequent versions of thesame product during its evolution. For example, adesign team made critical design decisions about thelocation of several RF components based on thecommunication protocols that needed to be sup-ported. However, as the product evolved, a new teamassigned to the project made changes to the commu-nication protocols without realizing their adverseeffect on RF components.

Ø Skills deÕeloped due to collaboration may bew xlost thereafter: Quinn et al. 54 suggest that profes-

sional know-how is developed most rapidly throughrepeated exposure to the complexity of real prob-lems. In a project-oriented team-based organizationalstructure, skills developed during the collaborationprocess might be lost after the team is broken up andredistributed among other teams or groups working

w xon newer development projects 56 . When a team isdisbanded, the process knowledge acquired by theteam is lost and is not available for tasks such as

w xproduct modification or maintenance 32 .Ad-hoc teams formed for NPD are often dis-

banded at the end of the development. Team mem-bers often get assigned to other projects whereintheir functional expertise is more valued than theknowledge gained during the process of their collab-oration with other functional and technical areas. Forexample, the domain knowledge gained by a RF


engineer during the development of PDA may be‘wasted’ if he is transferred to a project on voicepagers to utilize his functional skills.

Ø Inability to transfer existing knowledge intow xother parts of the organization 59 : Many organiza-

tions face difficulties in transferring knowledge fromone organizational unit to another. Galegher et al.w x29 highlight the problem in the diffusion phasewherein team members begin transferring technicaldata as well as a sense of ownership to other groupsthat must manufacture and market the new product.Maintaining motivation for knowledge transfer atthis stage is challenging as all major product devel-opment decisions have already been made and whatremains is the completion of product details. Contin-uing with the example of the PDA, innovative designsolutions arrived at by the voice paging development

Žfor power management conserving battery life when.not in transmitting mode is not shared with the PDA

team. Similarly, the team working on the Palm OSversion of the product is very experienced in devel-oping hardware solutions for efficient power man-agement, but does not share the core technology withthe Windows CE team.

Ø Inconsistency in multiple Õersions of informa-Ž w x.tion: Recent research such as Refs. 3,4,9,15 sug-

gests that an enabling condition for knowledge cre-ation is redundancy. Redundancy offers an overlap inknowledge between different groups that promotescross-functional collaboration. The need for redun-dancy, however, must be met simultaneously withthe need for maintaining consistency across differentversions of information that may be possessed bydifferent team members.

As problems are encountered in the design ofcommunication components during testing with pro-tocol encoders, the hardware designers make ‘minor’modifications to their designs. However, the hard-ware–software interface specifications agreed to be-tween the hardware and software designers are notupdated. The two teams, working with different ver-sions of the specifications, run into serious incompat-ibilities during integration testing. The problem ofintegrating multiple sources of knowledge in a co-herent manner that can be brought to bear upon

w xdesign is illustrated by Robillard 58 in the case ofsoftware products, such as the PDA operating sys-tem.

Ø EÕolÕing assumptions: Design decisions madein the process of developing a new product, might be

w xbased on some critical assumptions 8 , both techni-cal and nontechnical. Due to the dynamic nature ofproduct development activities these assumptions of-

w xten change 55 , necessitating reevaluation of thedecisions that depend on them.

The design team makes critical decisions aboutthe processing power and battery-consumption re-quirements of the PDA. These are based on assump-tions about the power-management functionalitiesprovided by the operating system. A recent upgradeto the operating system significantly changes thepower management services. However, the change inthis critical assumption is not communicated to thevarious design teams, resulting in duplication ofefforts to conserve power during both hardware andsoftware design.

w xØ Loss of tacit knowledge 59 : Tacit knowledgeis difficult to articulate in a way that is meaningful

w x w xand complete, hence it is often lost 68 . Teece 68suggests that the larger the extent to which a unit ofknowledge has been codified, the lower are its trans-fer costs. Uncodified or tacit knowledge is not only

w xslow to transfer, but also leads to ambiguity 68 .The designers of the RF components assume that

the designers of the computing processors are awareof the interference that the processor may cause withthe communication components. This knowledgethough obvious to the RF designers, is not com-monly well understood by other team members. Inthe absence of explicit requirements for the RF team,the processor designers ignore the issue.

6. Requirements for a Knowledge ManagementSystem

The focus of our research is the development of aKM system to support collaborative NPD. As a firststep, we identify the requirements for such a systemby examining the various KM problems faced byNPD teams. We then identify general solutions tothese problems suggested in the literature. Finally,we identify specific requirements for a KM systembased on these general solution strategies. We pre-sent the above analysis in Table 3. Here, specificsystem requirements have been identified by func-

()

B.R

amesh,A

.Tiw

anar

Decision

SupportSystems

271999

213–

235222

Table 3Mapping problems to system requirements to support process KMProblem faced by NDP teams General solution System requirements

� 4Over reliance on transmitting explicit Convert a part of tacit design knowledge into explicit, Multimedia integration MM that forces users torather than tacit design knowledge articulated and stated knowledge by asking participants think through the process by articulating dependencies on cross functionallyw x w x18,33,42,51 to record assumptions and beliefs along significant aspects of the design 4,5,30 . Integration with underlying

w x � 4 w xwith decisional steps 25,26,50 assumptions IA 56 . This would allow for the creation of a strategicagreement between the various participants.Multimedia support to capture knowledge that can not be explicitly

� 4codified or written down IK . This would facilitate more superlativew xknowledge transfer and exchange 49,56 . Support for recording assumptions

� 4 � 4 w xRA and recording beliefs RB 55 .w xBarriers due to lack of absorptive Retain context along with information stored The context of each decision 18,20 in the process can be captured with

w x � 4capacity of the recipient 65,70 each concept DC . Multimedia support makes such context recordableeven when it can not be codified. Some researchers have identifiedthis type of knowledge as implicit knowledgethat can be captured but notformalized or codified

Changing team membership Divorce knowledge from the holder, convert Each team member’s augmentation to the designw x w x � 418,20,31 repeated mistakes 68 ; to explicit knowledge discussion process is captured in deliberation records DR .

w xreinvention of solutions 68 Change in team membership does not result in knowledge ‘walkouts’as a significant portion of the team member’s contribution to the

Ž w xteam’s synergy see, for example, Refs. 28,30,37 and integratedunderstanding is captured in the system.

� 4 � 4Capture past design experiences in a manner useful for Design information from past projects DP and current projects DN islater reference during design processes accessible to the present team. Such information is available both for past and

ongoing projects throughout the enterprise by means of a distributed� 4workspace enabled by a communications network NE .

Design information from both the past projects as well as the currentw xproject is retrievable online, in real time, across a distributed workspace 62

Ž .such as a client server implementation . This helps preventrepetition of old mistakes.

()

B.R

amesh,A

.Tiw

anar

Decision

SupportSystems

271999

213–

235223

Create well-indexed knowledge of similar Design knowledge — both formal and a part of the informal� 4 � 4problems faced in earlier groups and teams. — from past projects DP DN is readily available and captured within the

system. Ad-hoc retrieval of informal information is supported using meta tags.� 4 ŽShared medium Shared medium between cross-cultural team Shared medium SM ; consistently interpretable across

.members provides a common discussion field. functional and national boundaries forms of representation using icons� 4 ŽGI ; retention of credit to the original contributor for contribution

. � 4credit and reward matching are supported by the system ATw x � 4Loss of collaborative skills 54,60,61 Support capture and reuse of knowledge Collaborative design dialog CD throughout the design process is captured as a

created during the collaborative process itself. process. Such a process can be replayed or reenacted to reveal the� 4sequential and parallel activities and contexts of past design decisions RE .

w x � 4 w xVersioning of information 59,60 Store multiple and identifiable versions of Versioning of process knowledge is supported by the system VC 51,52,76 .content at a single central remotelyaccessible repository.

Process knowledge might be lost after Retain dialog between the members of the Preserve antecedent dialog between the members of thew x � 4the project is completed 32 design team as a part of captured design team as a part of captured knowledge DR .

w xknowledge 26w x � 4 � 4 � 4High development costs 14 Reuse knowledge, processes and design Decisions from both the current and past projects are available DP DN NE .

artifacts from past projects. This can potentially reduce the time spent in reinventingw xsolutions and the costs incurred in the process 20,23 .

w xUnstated assumptions 55,56 Accommodate assumptions made in the Each decision made in the design process can based on multiple assumptions� 4 w xdesign process and dynamically link them which are linked LA to it 25 . The effect of a change in any assumption

to decisions made throughout the process. automatically ripples through the rest of the design decisions andEffects of changing assumptions must be by processes to show the effect of changing assumptions or levels of

� 4supported by a system supporting belief on the rest of the design process TA .knowledge capture and codification, etc.


Ž � 4.tionality codes within braces . Mapping of theserequirements with the functionalities of a prototypesystem will be presented in Section 7.

7. Prototype System to Support Process Knowl-edge Management

We have developed a prototype system to supportKM tasks in collaborative NPD. Functionalities ofthis system are grounded in the ‘requirements’ iden-tified in Table 4. Based on data collected from ourcase study, we propose and validate using a proto-type, system characteristics that can help overcomeKM problems faced by NPD teams. The discussionin this section is organized around the critical func-tionalities provided by the system. Table 3 mapsthese functionalities to the requirements identified inTable 4.

We describe our prototype system using scenariosof usage of the system in the design of a PDA. Thescenarios were identified and refined by our casestudy. They were validated by participants in ourstudy as representative of the situations encounteredby them in their tasks. As the focus here is onillustrating the functionalities of the system, onlysmall snapshots from the complex product develop-ment activities for a PDA are presented in the fol-lowing discussion.

7.1. Implementation

The prototype system is based on ConceptBase,an implementation of the high-level conceptual mod-

w xeling language Telos 48 . Telos is based on a firstorder assertion language and provides facilities forspecifying meta-concepts, semantic integrity con-straints temporal knowledge and deductive rules.Using meta-concepts, meta models that representvarious classes of knowledge can be specified andinstantiated. The prototype is based on a client serverarchitecture and supports group work. Users of thesystem spread across a network can communicatewith each other through a centralized knowledgeserver. This server maintains the integrity of theprocess knowledge components. The system pro-vides a graphical user interface for communicationwith the server to retrieve and modify the contents ofthe knowledge base. Further, the browser provideslinks to external tools such as a WWW gateway.

7.2. Definition of Concept Maps

As a first step in supporting the capture and use ofprocess knowledge for NPD involves the identifica-tion of the critical components of knowledge. Ourprototype system provides the ability to define metamodels in terms of objects representing knowledgecomponents of interest. Further, associations amongthese components can also be represented. Finally,characteristics or attributes of concepts can also be

Ž .easily specified. Once a meta model or a schema isdefined, users of the system can instantiate thesemodels.

Based on discussions with members of the NPDin our case study, the meta model shown in Fig. 1was selected as a candidate scheme. In this model,

Table 4System functionality and resulting requirements that are specified by such functionality

Ž .System functionality Requirement s based on Table 3

� 4 � 4 � 4Definition of concept maps GI , VC , DB� 4 � 4 � 4 � 4 � 4 � 4Support for knowledge capture DR , NE , SM , NE , AT , CD� 4 � 4Representation of context DC , NK� 4Ø Links to sources MM� 4Ø Informal and formal components MM� 4Knowledge access NK� 4 � 4Assumption surfacing IA , LA� 4 � 4 � 4Review of past knowledge DP , DN , RE� 4 � 4Agents for dependency management LA , TA


Fig. 1. Concepts representing various knowledge components.

concepts are knowledge components that can be usedto represent the participants views of interests, con-

w xcerns and tasks 40 . A concept may suggest otherconcepts, elaborate on others, and even depend onothers. A few specializations of concepts were alsoidentified. These include issues, alternatives, justifi-cations and assumptions. Issues are questions orconcerns that need to be resolved to arrive at deci-sions in NPD, and alternatives are various answers orsolutions to these issues. Justifications that are for oragainst these alternatives are also included in themodel. Finally, assumptions underlying concepts arealso represented. This model is similar to the issue-

Ž .based information systems IBIS model of argumen-w xtation 13 that has been used successfully in a wide

range of domains to represent complex problem solv-ing processes. It should be noted that the choice ofthe specific meta model is entirely up to the users ofthe tool. The system supports the definition andinstantiation of any model chosen by the users.

ŽUsing parent–child relationships or IS-A hierar-. Žchies and treating attributes as first-class objects so

.that they can have attributes of their own complexmodels can be easily specified. Our system providesa graphical editorrbrowser to define and navigatethrough knowledge components. Context sensitivemenus are provided for the users to define instanti-ate, modify, and link objects in the meta model.

7.3. Support for Knowledge Capture

After the meta model in Fig. 1 is defined, userscan create and modify process knowledge compo-nents and relationships among them using a usingthe graphical browserreditor. Each user may invokethe client GUI and connect to the same knowledgebase maintained by the server. Thus, multiple usersconnected to the same server may conduct ‘conversa-tions’ in terms of the primitives specified in the metamodel. In these structured conversations each team


member can add and modify various concepts andrelationships among them. They may seek clarifica-tions of concepts proposed by others. Using thisfacility, the team members can communicate their

w xviewpoints and expertise 27 and map their views ofthe problem with those of others. In our example, theusers may propose, suggest, elaborate on variousissues, alternatives, justifications and assumptions.

ŽThese knowledge components may be viewed and.modified, if permitted by other members of the

team. They may, in turn, respond by proposing otherconcepts and relationships. With such a conversa-

tion, various viewpoints are exchanged among themembers of the NPD team.

Fig. 2 represents the output of such a conversationderived from our case study, to represent a typicalscenario in PDA design. Here, three stakeholdersŽthe product manager, the marketing specialist and

.an RF engineer contribute to the definition of thevarious concepts. First, the product manager pro-poses a discussion between marketing and RF engi-

Ž .neer s on the factors that are critical in the develop-ment of a PDA. He postsrraises the issue ‘‘What arecritical factors’’ in the system requesting responses

Fig. 2. Conversation among group members.


from the two groups. Marketing proposes that size,price, cellular communication capabilities, comput-ing power, wide usage area, and battery life are allimportant factors to the market segment that thePDA is designed for. Many of these factors arestated in a language that may not be readily under-stood by the design team that needs to implementappropriate design features. To foster better under-standing, the product manager seeks clarificationsfrom marketing on the requirements for cellularcommunication. Marketing elaborates with details onthe coverage desired, RF features desired, DSP fea-tures, power management features, etc.

At this time, the product manager asks the RFengineer to state how the RF features proposed bymarketing can be implemented. The RF engineerelaborates on the specifications for the antenna, in-terference requirements, and bandwidth requirementsthat are to be addressed. He also wants to highlightthe fact that many of these requirements have strongdependencies on others. For example, the bandwidthrequirements will have a strong influence on batteryusage and therefore is of critical importance whiledeveloping power management features. This is fur-ther related to the computing power that is requiredby the user. These are identified using the ‘dependson’ links between these components in Fig. 1. Itshould be noted that each node in the diagram couldbe linked to an external document, a Web page or an

Žartifact to provide further details as discussed in.detail in Section 7.4 .

The discussions such as the above help the teamclearly state their viewpoints, understand the view-points of others, map their views to those of otherssuch that the team develops a shared understandingof the problem being solved. Even when the discus-sions are conducted in the context of structuredprocesses like the development of a house of quality,our system can be used to capture the process knowl-edge behind these processes.

7.4. Representation of Context

The larger context in which a participant hasdeveloped a particular perspective can be better un-derstood by others if they have access to the detailssuch as work products, supporting documents, etc.

These ‘sources’ may also be available in variousŽlevels of formality ranging from hypermedia docu-

. w xments to formal definitions . Quinn et al. 54 referto this as an elevation from know how to know whyŽknowing why a given choice was made over an-

.other , which he argues, makes a team more flexibleand innovative when faced with a previously unseenproblem. Using our system, a user can specify anexhaustive variety of information about concepts thatthey specify; These knowledge chunks include:Ø What information is represented — including

salient attributes or characteristics.Ø How this information is represented both by for-

mal and informal means and how it relates toother components of knowledge.

Ø Who are the stakeholders that played differentroles in its creation, maintenance, validation anduse.

Ø When this information was captured, modifiedand evolved.

Ø Where it is represented—in terms of sources that‘contain’ this information.

Ø Why a certain concept evolved, or was created.

7.4.1. Links to sourcesOur system provides the ability to link most of the

above information as attributes of any concept. Also,a user can link a concept to the sources that provideadditional information. For example, the RF engi-neer, by viewing the video clip of a focus groupsession in which the battery life of different compet-ing products and the reactions of the consumers arediscussed, may better understand the requirementsproposed by marketing. This clip is attached to thespecifications from marketing as an important ratio-nale.

Each object in the knowledge base can be linkedto static documents or to documents dynamicallycreated by searching the repository of hypermediadocuments on the WWW. Further, a context sensi-tive menu provides the facility to invoke external

Ž .tools such as a WWW gateway to retrieve docu-mentsØ that have been explicitly linked to an object,Ø that are indexed with the keywords defined as

attributes of the object, andŽØ that are considered ‘similar’ using a variety of

.search techniques .


In our example, the RF engineer is interested inreviewing details of FCC regulations on RF commu-nication while finalizing the RF features. He mayreadily retrieve all the documentation on the relevantgovernment regulations that is located in the depart-mental or corporate Intranets or the WWW. Heinvokes an indexing gateway provided by our systemthat is available as a menu option on the concept RFfeatures. His search for related documents may beguided by the following inputs:

Ž .Ø Keyword sŽ .Ø Boolean search operators and, or, etc.

Ø Date relevancyØ Thesauri to be used

Ž .Ø Substring options word stemmingØ Document hierarchy

It should be noted that the indexing gatewayprovided with the system can be substituted with anyother search procedure or external tool that can beinvoked with a system command. Thus, our systemprovides interfaces to knowledge chunks not cap-tured within the system.

w xFinally, recent research 52 recognizes the impor-tance of identifying the people involved in the cre-ation and maintenance of organizational knowledge,when explicit representation of such knowledge isnot feasible. In our system, such information ismaintained as attributes of concepts.

7.4.2. Informal and formal componentsInformal information can be maintained using

hypermedia documents. Our system supports formaldefinitions of hypermedia objects and linking themto the relevant concepts. Several attributes can bedefined for each hypermedia object that can help inclassifying, indexing and retrieving them. Some ex-amples of such attributes are: its creator, maintainer,

Ž .the other objects it is linked to, and the project sthat it is a part of.

In our case study, the marketing department isinterested in specifying a variety of information aboutconcepts they proposed. For example, they may pro-

Ž .vide details on the concept Battery Life BL withthe following information:Ø What: The duration for which the PDA functions

without requiring a recharge. It does not refer tothe physical life of the battery.

Ø How: A chart comparing the battery life of vari-ous competing products.

Ø Who: Created by marketing teamØ When: Automatic time stamp by the system at the

time of creationØ Where: Reference to a marketing department

memo discussing implications of battery life oncustomer satisfaction

Ø Why: A video clip containing a segment from afocus group discussing the importance of batterylife. This can be especially useful where tacit orinformalizable components of knowledge such ascustomer expressions and gestures are involved.Our case study, in agreement with existing litera-

w xture 17,53,75 , suggests that such a rich definition ofconcepts is considered invaluable by other partici-pants in the NPD team.

7.5. Knowledge Access

Our system uses the deductive query languageprovided by ConceptBase to define various types ofad-hoc queries that could be used to retrieve infor-mation of interest to different participants. Queriesare defined as special classes whose instances areanswers to the query. A graphical interface is pro-vided for displaying queries and retrieving desiredanswers. Recursive queries are very helpful in selec-tively retrieving contents of the knowledge base.

In our case study, a representative query wouldretrieve all documents that are related to a specificdesign issue. The answer is constructed by firstidentifying all alternatives that address the issue,their attendant justifications and assumptions andthen retrieving all documents that are linked to anyof these. Our case study suggests that a variety ofsuch ad-hoc queries can be tailored to the specificneeds of the various team members.

7.6. Assumption Surfacing

The need to explicitly state the assumptions be-hind concepts was repeatedly highlighted in our casestudy. As described in our meta-model, assumptionsand their relationships to other assumptions and con-cepts can be captured using our system.


Fig. 3 provides a snapshot of a discussion duringthe development of a PDA that illustrates the impor-tance of assumption surfacing. In this figure, theoutput of a design deliberation about a critical issue,viz., the protocol to be used for cellular networkcommunication, is shown. Initially, the various teammembers propose two alternatives. They are time

Ž .division multiple-access TDMA and code divisionŽ .multiple-access CDMA . A designer proposes the

use of CDMA. His recommendation is based on theassumption that the system will be marketed only in

Žthe US where this technology is used or that cover-.age in Europe is unnecessary . Marketing however

suggests that upgradability is an important considera-tion in the target market. That is, a PDA user must

be able to upgrade to any other cellular network thatmay eventually replace CDMA as the primary optioneven within the U.S. Given the high possibility of athird generation cellular standard based on global

Ž .system for mobile communication GSM emergingwithin a few years, another designer suggests supportfor the GSM protocol. This option is objected by theneed for backwards compatibility with CDMA basedsystems in the U.S. More importantly, to make thiscritical decision, it is important for the designers tounderstand the implicit assumptions behind the con-sideration proposed by marketing. Marketing is askedto clarify the total life span of the PDA during whichit should be upgradable. If it is a short duration, thenthe option to support GSM is irrelevant, as the third

Fig. 3. Managing dependencies and assumptions as demonstrated by our PDA development case study. The figure illustrates howdependencies between assumptions brought into the design decision by functionally diverse participants influences the final design decisionat each decision node.


generation standard will not be ready. However,marketing now states that the expected life of PDAis about 3 years, requiring serious consideration ofGSM. During such a conversation, critical assump-tions behind the various concepts such as issues,alternatives, justifications, etc. are made explicit,thereby helping the NPD team make better-informeddecisions.

7.7. ReÕiew of Experiential Knowledge

An important feature that was highlighted in ourcase study is the ability to retrace the various stepsthat were taken in the NPD process. This would helptake corrective action when past mistakes are re-vealed. Further, such a review of knowledge is alsouseful to facilitate understanding of decisions, aswell as for identifying the choice points where alter-native decisions could lead to different solution paths.The team would benefit from a review to understandhow the knowledge components were definedchronologically. Finally, the ability to selectivelyreview the history focusing on select aspects of theproblem will also be very useful.

The functionalities of our system to support sucha feature is based on the premise that a NPD teammay be interested in revisiting a decision process,

Ž .including the dead ends, in the same time order inwhich it happened. Such a review is used in explain-ing the process and outcomes to new participants oras a training mechanism. In our system, for eachassertion in the knowledge base a time stamp iscreated. This information can be used to trace the

Ž .steps in the evolution of a concept say, an issue .Such a replay could also facilitate reevaluation ofassumptions and decisions, leading to their revisions.In our case study, when a new design engineerwondered about the final decision to go with aCDMA cellular network instead of a newer technol-ogy, the system can present the various steps in thedecision process, in the order in which they oc-curred.

Very often the users may be interested in focusingtheir search through history to study the context in

w xwhich a specification or a decision was arrived at 2 .Such ‘reasoning backwards from outputs’ is impor-

tant in complex decision making situations and ismore useful than the traditional ‘what-if’ analysisinvolving ‘reasoning forward from data’. In the for-mer, the decision-maker starts with the goal andassesses whether ‘satisfying’ the goal can endurechanges in the inputs, whereas in the later case, thesensitivity of the results to changes in the inputs areassessed. In our case study, a design engineer mayjust be interested in all the assumptions leading toselection of a particular cellular standard rather thana comprehensive history of the various alternativesconsidered their justifications and their validity, etc.This can be done by selecting a menu choice from

Ž .any concept to retrieve all direct or indirect as-sumptions behind it. By selecting this option fromthe node GSM, the user will retrieve the assumptionthat the PDA’s expected life is 3 years.

7.8. Agents for Dependency Management

The meta model derived from our case studyprovides ability to explicitly represent dependenciesamong various concepts such as assumptions. Thecase study also suggests that this information can bemade more valuable if mechanisms for managingsuch dependencies are available. Our prototype sys-tem employs autonomous agents for maintaining de-pendencies at different levels of automation. Forexample, when a concept depends on another, theagents maintain the semantics of this dependency bypropagating relevant properties of one concept toanother. If a concept depends on an assumption, thenthe belief in that concept is based on the belief in therelevant assumption. Using deductive rules, the au-tonomous agents propagate these beliefs.

A major concern for the NPD team is that oftenthe repercussions of changes in critical assumptionsare not well understood, leading to very costly mis-takes and rework. For example, the change in thevalidity of an assumption, for example, can haveserious repercussions throughout the developmentprocess. Returning to the scenario discussed in Fig.3, the critical decision on whether to use GSM orCDMA hinges on, among other things, the life ex-pectancy of the product. When the product life isvery short, the option to provide GSM service is not


justified. The marketing team was asked to carefullyevaluate their assumption that customers indeed willuse the same PDA for 3 years. When their marketstudies revealed that with rapid changes in the indus-try, a typical consumer would not use the PDA morethan 2 years, the belief in this assumption wasrevised. With such a revision in our system, thesupport for the concept on upgradability and there-fore, the option of a GSM based protocol will beautomatically withdrawn.

Similarly, the dependencies in the network ofissues that get discussed, the various alternative solu-tions considered and their attendant justifications arecaptured and maintained by autonomous agents withdifferent levels of formality. In the simple case, thesystem warns the user about changes in relevantconcepts on which the concept of interest to himrherdepends. In the other extreme, changes to conceptsare automatically propagated. A network of depen-dencies can be set up among any concept describedusing our system. In our example above, instead ofautomated propagation of the beliefs due to changesin the assumption, the user may be notified to high-light the decision about using GSM needs to bereexamined.

8. Related Work

Our research has focused on providing support fora collaborative task with emphasis on capturing pro-cess knowledge in collaborative systems. Systems

w xsuch as gIBIS 13 and others that are inspired byŽ w x.this work e.g., IBE 39 have a similar goal. They

advocate the representation of informal informationas a part of a comprehensive project knowledge.These systems provide a hypertext interface to theIBIS model and are constrained by the limitations ofIBIS such as the lack of representation of inputs and

w xoutcomes of argumentation. Synview 43 is an ex-ample of a system that uses Toulmin’s argumenta-

w xtion framework 71,72 . This system provides facili-ties for indexing, evaluating and synthesizing infor-mation related to justifications for assertions. In con-trast to these systems that are limited to a specificmodel, we provide a generic framework with which

Ž .any model such as the IBIS and its extensions can

be easily developed to represent knowledge compo-nents. Further, unlike these systems that focus pri-marily on informal knowledge, we provide a muchtighter integration of formal and informal compo-nents of process knowledge. Systems such as Con-

w xstellations 57 facilitate access to informal knowl-edge by chunking multimedia information. However,the need to integrate informal information in hyper-text with formal models has also been suggested by

w xBhargava et al. 7 . A primary reason for providing aformal representation of the argumentation processŽ .whenever feasible is to facilitate automated reason-ing with the captured knowledge. Our work, there-fore, takes a comprehensive approach to dealing withinformal information advocating the creation of for-mal models to facilitate better integration. As amajor objective of our research is to provide auto-mated reasoning to support various stakeholder needs,we provide functionalities similar to those offered by

w xSIBYL 40,41 . Our framework is generic enough tosupport the DRL model proposed in SIBYL as wellas more comprehensive models of process knowl-edge components.

Our approach for assigning attributes to multime-dia objects for indexing and ease of retrieval is

w xsimilar to the scheme proposed in DEDAL 5 . Ourwork, however, is much broader in scope in thatmultimedia objects are used as adjuncts to and insupport of more formally defined knowledge compo-nents. Unlike DEDAL whose functionality is limitedto multimedia information, we provide a wide rangeof services to address the needs of NPD teams. Suchactive support beyond passive capture of knowledge,distinguish our system from several organizational

w xmemory systems such as gIBIS 13 .Ž . ŽQuality function deployment QFD as defined

w x.by Hauser and Clausing 34 is commonly used inw xNPD 16,34,45,63 . Our approach to capturing pro-

cess knowledge is highly complementary to thisapproach. QFD can be used to represent decisionsmade by a team along dimensions considered impor-tant to the customer and the product developmentteam. We contrast our approach in the followingways.

Ø The output of a QFD process leading to aŽ .house of quality HoQ involves the consideration of

a variety of viewpoints and expertise. Only the finaloutcomes of these deliberations are represented in


QFD, say as a QFD correlation matrix. Our approachcan complement the QFD process by capturing theserich deliberations as well. Thus, the output of delib-erations in our system can be HoQ.

Ø Capture of process knowledge about the QFDprocess itself can be very valuable in explaining aswell as evolving the HoQ necessitated by changes inthe alternatives considered in a QFD activity. Forexample, a design characteristic used in an HoQ maybe based on an assumption about the availability orimplementability of the technology in the productionprocess. If this assumption is invalidated later in theproduct development process, the repercussions ofthis can be easily ascertained by our system. Morefundamentally, the explicit identification of knowl-

Žedge components such as assumptions which are not.directly represented in a QFD process , can be ex-

tremely valuable.Finally, in contrast to group decision support sys-

tems that focus on the capture of informal informa-tion, we advocate semistructured capture of informa-tion. These semistructured knowledge componentscan contain informal information captured using suchsystems. In this respect, our work is complementaryto such systems in that we provide mechanisms forcapturing and managing knowledge represented us-ing richer media.

9. Discussion and Future Work

w xA field study 74 demonstrates the feasibility andusefulness of capturing semistructured knowledge ina complex problem solving situation, viz., designdecision making in large system development pro-jects. The business value of codification and captur-ing semistructured knowledge was also found in arecent study of 120 projects across a cross section of

w xfirms 33 . However, some components of processknowledge do not easily lend themselves to structur-ing. Also, an organization may use a variety of

Ž .means such as groupware systems to facilitate in-formal and formal interactions. Integration of oursystem with outputs from such sources of knowledgeis essential for a comprehensive representation ofprocess knowledge. As an initial step, we providefacilities for linking structured and unstructured

knowledge components. Extending this approach,providing links to textual outputs of deliberationsfrom traditional groupware systems is the subject offuture work. We are currently investigating integra-tion with a system designed to capture unstructureddiscussions. Further, we are also developing mecha-nisms to integrate the tool with document manage-ment tools. Users will be able to highlight segmentsof documents and create concepts directly from theminto the knowledge base. Such a non-intrusive cap-ture and maintenance of process knowledge can miti-gate the overhead involved. Another area of currentexploration is the use of concept classification tech-niques for identifying candidate concepts from text

w xdocuments 11 . Using these techniques, text docu-ments ranging from e-mail exchanges to group sup-port system outputs to project documentation can beused to identify potential concepts. Using the inter-faces to document management tools, these conceptscan be imported into our knowledge base. We arecurrently investigating the capture of process knowl-edge from electronic mail exchanges. Future workwill include the use of concept learning techniques tolearn concept descriptions from past experiences ofcommonly occurring design situations.

Our approach aids in sharing of knowledge andexperience to aid organizational learning. Theknowledge base of semistructured experientialknowledge lends itself well to the use of inductionand case based reasoning approaches to learning. Asa first step, we are using concept learning techniquesto learn concept descriptions from past experiencesof commonly occurring design situations.

The empirical evaluation of the usefulness of ourapproach is being carried out by incorporating ourmodels and mechanisms in several business environ-ments. Our evaluation would focus on the feasibilityof capturing and maintaining product developmentknowledge in information systems product develop-ment activities.

The work presented here makes the followingcontributions:Ø We identify problems associated with KM specif-

ically in the context of NPD by cross-functionalcollaborative teams.

Ø We map these problems to broad solutions andsubsequently translate these into specific KM sys-tem characteristics and requirements.


Ø A prototype KM system that meets these require-ments is used to demonstrate the implementationof our proposed solutions.

Ø We validate the relevance of the proposed ap-proach by exercising the system with scenarios ofusage drawn from an industrial case study.

Ø The implementation illustrates an infrastructurethat can be tailored to support various models ofcollaborative KM.In conclusion, acquiring comprehensive contex-

tual knowledge about product development processcan be very valuable in supporting the needs of thevarious participants. Such knowledge should inte-grate both formal as well informal components. Fur-ther, it should be able to represent the linkages orrelationships among various components. Due to thehigh ‘overhead’ involved this process, intelligentsupport for the capture, use, and maintenance ofprocess knowledge is essential for project success.

References

w x1 P.S. Adler, Technology and the Future of Work, OxfordUniv. Press, New York, 1992.

w x2 J. Allen, P. Hayes, Moments and points in an interval basedŽ .temporal logic, Computational Intelligence 5 1989 .

w x3 W. Applehans, A. Globe, G. Laugero, Managing Knowledge:A Practical Web-based Approach, Addison-Wesley, Reading,MA, 1999.

w x4 W.R.J. Baets, Organization Learning and Knowledge Tech-nologies in a Dynamic Environment, Kluwer Academic Press,Boston, MA, 1998.

w x5 C. Baudin, C. Sivard, M. Zweben, Recovering rationale fordesign changes: a knowledge-based approach, in: Proceed-ings of the IEEE Proceedings, Los Angeles, CA.

w x6 R. Bettis, M. Hitt, The new competitive landscape, StrategicŽ .Management Journal 16 1995 .

w x7 H. Bhargava, R. Krishnan, A. Whinston, On integratingcollaboration and decision technologies, Journal of Organiza-

Ž . Ž .tional Computing 3 4 1994 .w x8 R.E. Bohn, Measuring and managing technological knowl-

Ž .edge, Sloan Management Review 36 1994 .w x9 U. Borghoff, R. Pareschi, Information Technology for

Knowledge Management, Springer, New York, 1998.w x10 K. Carley, Organizational learning and personnel turnover,

Ž . Ž .Organization Science 3 1 1992 .w x11 H. Chen, P. Hsu, R. Orwig, L. Hoopes, J. Nunamaker,

Automatic concept classification of text from electronicŽ . Ž .meetings, Communications of the ACM 37 10 1994 .

w x12 R. Comerford, Pocket Computers Ignite OS Battle, IEEESpectrum, May 1998.

w x13 J. Conklin, M. Begeman, gIBIS: a hypertext tool for ex-ploratory policy discussion, ACM Transactions on Office

Ž .Information Systems 6 1988 .w x14 N.R. Council, Improving Engineering Design: Designing for

Competitive Advantage, National Academy Press, Washing-ton, DC, 1991.

w x15 A.W. Court, The relationship between information and per-sonal knowledge in new product development, International

Ž . Ž .Journal of Information Management 17 2 1997 .w x16 D. Daetz, W. Barnard, R. Norman, Customer Integration:

Ž .The Quality Function Deployment QFD Leader’s Guide forDecision Making, Wiley, New York, 1995.

w x17 P. Darke, G. Shanks, M. Broadbent, Successfully completingcase study research: combining rigor, relevance and pragma-

Ž . Ž .tism, Information Systems Journal 8 4 1998 .w x18 T. Davenport, D. DeLong, M. Beers, Successful knowledge

Ž .management projects, Sloan Management Review 39 2Ž .1998 .

w x19 T.H. Davenport, Process Innovation: Reengineering Workthrough Information Technology, Harvard Business SchoolPress, Boston, 1993.

w x20 T.H. Davenport, L. Prusak, Working Knowledge: How Orga-nizations Manage what They Know, Harvard Business SchoolPress, Boston, 1998.

w x21 G.I. Doukidis, F.W. Land, G. Miller, Knowledge-based Man-agement Support Systems, Ellis Horwood, Chichester, NY,1989.

w x22 P. Drucker, The Post Capitalist Society, Harper BusinessPress, New York, NY, 1993.

w x23 D. Duffy, Knowledge Champions: What Does it Take to be aSuccesful CKO?, CIO Enterprise, 1998.

w x24 W.E. Eder, Information systems for designers, in: Proceed-ings of the Proc. International Conference in EngineeringDesign, Harrowgate, pp. 1307–1319.

w x25 L. Fahey, L. Prusak, The eleven deadliest sins of knowledgeŽ . Ž .management, California Management Review 40 3 1998 .

w x26 J. Favela, C.J. Jerome, Accessing corporate memory in net-worked organizations, in: Proceedings of the Hawaii Interna-tional Conference on System Sciences, Hawaii, pp. 181–190.

w x27 G. Fisher et al., Making argumentation serve design, HumanŽ .Computer Interaction 6 1991 .

w x28 G. Fisher et al., Supporting indirect collaborative design withintegrated knowledge based design environments, Human

Ž .Computer Interaction 7 1992 .w x29 J. Galegher, R.E. Kraut, C. Egido, Intellectual Teamwork:

Social and Technological Foundations of Cooperative Work,LawrencerErlbaum Associates, Hillsdale, NJ, 1990.

w x30 L.H. Glickenhaus, Knowledge transfer: breaking boundariesŽ .with web-based networks, Law Practice Management 25 2

Ž .1999 .w x31 F. Golshani et al., Proceedings of the Sixth International

Conference on Information and Knowledge Management:CIKM’97, November 10–14, 1997, Las Vegas, NV, ACMPress, New York, 1997.

w x32 J. Grudin, Evaluating opportunities for design capture, in: M.Ž .Carroll Ed. , Evaluating Opportunities for Design Capture,

Lawrence Erlbaum Associates, Mahwah, NJ, 1996.


w x33 M. Hansen, N. Nohria, T. Tierney, What’s your strategy formanaging knowledge?, Harvard Business Review, March–April 1999.

w x34 Hauser, Clausing, The house of quality, Harvard BusinessŽ .Review 3 1988 .

w x35 M. Iansiti, A. MacCormack, Developing products on internettime, Harvard Business Review, September–October 1997.

w x36 A.R. Jassawalla, H.C. Sashittal, An examination of collabora-tion in high technology new product development process,

Ž .Journal of Product Innovation Management 15 1998 .w x37 A. Khurana, Managing complex production processes, Sloan

Management Review, Winter, 1999.w x38 N. Krishnakumar, R. Jain, Mobility support for sales and

Ž .inventory applications, in: T. Imeluski, H. Korth, Eds. ,Mobility Support for Sales and Inventory Applications,Kluwer Academic Publishers, 1996, pp. 571–594.

w x39 M. Lease, M. Lively, J. Leggett, Using an issue basedhypermedia system to capture the software life cycle process,

Ž . Ž .Hypermedia 2 1 1990 .w x40 J. Lee, Sybil: A qualitative decision management system, in:

Ž .Whinston, Shellard Eds. , Sybil: A Qualitative DecisionManagement System, MIT Press, Cambridge, MA, 1990.

w x41 J. Lee, Design rationale capture and use, AI Magazine 14Ž .1993 .

w x42 D. Leonard-Barton, S. Sensiper, The role of tacit knowledgeŽ .in group innovation, California Management Review 40 3

Ž .1998 .w x43 D.G. Lowe, Cooperative structuring of information: the rep-

resentation of reasoning and debate, International Journal ofŽ .Man Machine Studies 23 1985 .

w x44 J.G. March, Exploration and exploitation in organizationalŽ . Ž .learning, Organization Science 2 1 1991 .

w x45 S. Mizuno, Y.o. Akao, K. Ishihara, QFD, the Customer-drivenApproach to Quality Planning and Deployment, Asian Pro-ductivity Organization, Tokyo, Japan, 1994.

w x46 K. Morik et al., Knowledge Representation and Organizationin Machine Learning, Springer, Berlin, 1989.

w x47 R. Morrison, J. Kennedy, Advances in databases, in: 14thBritish National Conference on Databases, BNCOD 14, Ed-inburgh, Scotland, United Kingdom, July 3–5, 1996 Proceed-ings, Springer, Berlin, 1996.

w x48 J. Mylopoulos, Telos: representing knowledge about informa-tion systems, ACM Transactions on Information Systems 8Ž .1990 .

w x49 C.K. Nicholas, J. Mayfield, Intelligent Hypertext: AdvancedTechniques for the World Wide Web, Springer, Berlin, 1997.

w x50 I. Nonaka, The knowledge creating, Harvard Business Re-view, November–December 1991.

w x51 I. Nonaka, N. Konno, The concept of ‘Ba’: building afoundation for knowledge creation, California Management

Ž . Ž .Review 40 3 1998 .w x52 I. Nonaka, H. Takeuchi, The Knowledge-creating Company:

How Japanese Companies Create the Dynamics of Innova-tion, Oxford Univ. Press, New York, 1995.

w x53 W. Orlikowski, J. Baroudi, Studying information technologyin organizations: research approaches and assumptions, Infor-

Ž .mation Systems Research 2 1991 .

w x54 J.B. Quinn, P. Anderson, S. Finkelstein, Managing profes-sional intellect: making the most of the best, Harvard Busi-ness Review, March–April 1996.

w x55 B. Ramesh, V. Dhar, Supporting systems development usingknowledge captured during requirements engineering, IEEETransactions on Software Engineering, 1992.

w x56 B. Ramesh, K. Sengupta, Multimedia in a design rationaleŽ .decision support system, Decision Support Systems 15 1995

.w x57 V. Rao, R. Goldman-Segall, Capturing stories in organiza-

tional memory systems: the role of multimedia, in: Proceed-ings of the Hawaii International Conference on System Sci-ences, Hawaii, pp. 333–341.

w x58 Robillard, The role of knowledge in software development,Ž . Ž .Communications of the ACM 42 1 1999 .

w x59 R. Ruggles, The state of the notion: knowledge managementŽ . Ž .in practice, California Management Review 40 3 1998 .

w x60 R. Sanchez, A. Heene, Strategic Learning and KnowledgeManagement, Wiley, Chichester, 1997.

w x61 P.M. Senge, The Fifth Discipline: The Art and Practice of theLearning Organization, DoubledayrCurrency, New York,1990.

w x62 M. Shaw, M. Fox, Distributed artificial intelligence for groupŽ .decision support, Decision Support Systems 9 1993 .

w x63 M.L. Shillito, Advanced QFD: Linking Technology to Mar-ket and Company Needs, Wiley, New York, 1994.

w x64 M. Song, M. Montoya-Weiss, Critical development activitiesfor really new versus incremental products, Journal of Prod-

Ž .uct Innovation Management 15 1998 .w x65 S. Srivastva, The Executive Mind, Jossey-Bass, San Fran-

cisco, 1983.w x66 E.W. Stein, Z. Vladimir, Actualizing organizational memory

with information systems, Information Systems Research 6Ž . Ž .1 1995 .

w x67 G. Szulanski, Exploring internal stickiness: impediments totransfer of best practice within the firm, Strategic Manage-

Ž .ment Journal 17 1996 .w x68 D. Teece, Research directions for knowledge management,

Ž . Ž .California Management Review 40 3 1998 .w x69 R.E. Teigland, C. Fey, J. Birkinshaw, Knowledge Dissemina-

tion in Global R&D Operations: Case Studies in ThreeMultinationals in the High Technology Electronics Industry,Stockholm School of Economics, Stolkholm, 1998.

w x70 D.R. Tobin, The Knowledge-enabled Organization: Movingfrom ‘Training’ to ‘Learning’ to Meet Business Goals, Ama-com, New York, 1998.

w x71 S. Toulmin, The Uses of Arguments, Cambridge Univ. Press,Cambridge, UK, 1958.

w x72 S. Toulmin, R. Rieke, A. Janik, An Introduction to Reason-ing, MacMillan, New York, 1984.

w x73 M.A. Von Glinow, S.A. Mohrman, Managing Complexity inHigh Technology Organizations, Oxford Univ. Press, NewYork, 1990.

w x74 K.B. Yakemovic, E.J. Conklin, Report on a developmentproject use of issue based information system, in: Proceed-ings of the Computer Supported Cooperative Work, pp.105–118.


w x75 R. Yin, Case Study Research: Design and Methods, SagePublications, Thousand Oaks, CA, 1994.

w x76 M. Zack, An architecture for managing explicated knowl-edge, Sloan Management Review, Spring, 1999.

Balasubramaniam Ramesh is an Associ-ate Professor of Computer InformationSystems at Georgia State University. Dr.Ramesh received his PhD degree in In-formation Systems from New York Uni-versity. His research work has appearedin several leading conferences and jour-nals including the IEEE Transactions onSoftware Engineering, IEEE Expert,Annals of Software Engineering, Annalsof Operations Research, Concurrent En-gineering — Research and Applications,

Decision Support Systems and Journal of Systems Integration. Hisresearch interests include supporting collaborative work with arti-ficial intelligence, decision support and multimedia technologiesin the areas of requirements engineering and traceability in sys-tems development, concurrent engineering, NPD, knowledge man-agement, and business process redesign.

Amrit Tiwana is currently a doctoralstudent in the Department of ComputerInformation Systems at J. Mack Robin-son College of Business, Georgia StateUniversity, Atlanta. His research inter-ests include knowledge management, or-ganizational learning, and new productdevelopment. He is also the author ofThe Knowledge Management Toolkit:Techniques and Strategies for Building

ŽKnowledge Management Systems Pren-.tice Hall, 1999 .

Documents

Supporting Collaborative Process Knowledge Management in New Product Development Teams