radical innovation without collocation ase...

Malhotra et al./Boeing-Rocketdyne Case Study

MIS Quarterly Vol. 25 No. 2, pp. 229-249/June 2001 229

SIM PAPER COMPETITION

RADICAL INNOVATION WITHOUT COLLOCATION:A CASE STUDY AT BOEING-ROCKETDYNE1, 2

By: Arvind MalhotraKenan-Flagler Business SchoolUniversity of North Carolina at Chapel HillChapel Hill, NC [email protected]

Ann MajchrzakMarshall School of BusinessUniversity of Southern CaliforniaLos Angeles, CA [email protected]

Robert CarmanAdvanced Technology ProgramsRocketdyne Propulsion & PowerThe Boeing Corporation6633 Canoga AvenueCanoga Park, CA [email protected]

Vern LottMetal Fabrication, Texas OperationsElectronic SystemsRaytheon Systems Company6000 Lemmon AvenueDallas, TX [email protected]

1Robert Zmud was the accepting senior editor for thispaper.

2This paper won first place in the 2000 SIM PaperCompetition.

Abstract

This paper describes how a unique type of virtualteam, deploying a computer-mediated collabora-tive technology, developed a radically newproduct. The uniqueness of the team�what wecall VC3 teams, for Virtual Cross-value-chain,Creative Collaborative Teams�stemmed from thefact that it was inter-organizational and virtual, andhad to compete for the attention of team memberswho also belong to collocated teams within theirown organizations. Existing research on virtualteams does not fully address the challenges ofsuch VC3 teams. Using the case of Boeing-Rocketdyne, we describe the behavior of mem-bers of a VC3 team to derive implications forresearch on virtual teaming, especially forstudying teams within emerging contexts such asthe one we observed. The data we collected alsoallowed us to identify successful managerialpractices and develop recommendations formanagers responsible for such teams.

Keywords: Virtual teams, supply-chain colla-boration, innovation, collaboration technology.

ISRL Categories: HA08, HA12, AA09, AC03,AD05, AIO113, BD103, DD05

Introduction

Suppose there is a ship carrying a team given thetask of creating a radical innovation. The productdevelopment manager realizes that to achievetruly radical innovation, she must include people


230 MIS Quarterly Vol. 25 No. 2/June 2001

who not only have never shared the same ship,but also have never shared the same ocean, theidea being that cross-fertilization of ideas wouldlead to development of radically new products.That is, innovation will come from bringing peopletogether from different companies, disciplines,products, markets, processes, and industries.Such a ship is hard to steer because the membersdo not have a common language. They areexperts in very different disciplines, different com-panies, and different products. They share nocommon history of design, or previous experienceworking together.

But suppose we are not satisfied with even thispossibility of innovation and we realize that, byputting people onto a ship to work together, theyare leaving their parent companies. Ironically, wedon�t want the people who will come�the �bestavailable��those people the parent company iswilling to have leave. We want the best and thebrightest that the company has to offer; the personwho deeply understands the company�s corecompetency, not just uses it; the �best able,� However, because these people are the best, theyare already involved in many internal companyprojects. How do we get them on our ship?

We don�t. We dismantle our ship, send everyonehome, and create a virtual ship where everyoneworks on the creative project from his or herdesktop, so that team members can remainavailable to both their parent organization and thecreative team. In fact, we make sure we pickpeople who were never on the same ship so thatcreativity is the only way out for this team. Suchteams essentially become focused SWAT teams,with little history working together, broughttogether to create revolutionary new concepts ona part-time basis and then disbanded. Becausethey are virtual, they are never truly �broughttogether�; rather the members are appointed tothe team one day and begin their work from theirdesktops the next. We call these teams VirtualCross-value-chain Collaborative Creative teams(or VC3 teams).

If inter-organizational creative teams are hard tosteer, and if virtual teams in general are hard tosteer, then VC3 teams are even harder. Moreover,how does a manager facilitate knowledge-sharing

in such an environment: where there is no com-mon history to establish knowledge-sharingnorms? Achieving the benefit of radical innovationwas one of the initial drivers and hopes of virtualteaming (Davidow and Malone 1992; Ring andVan de Ven 1994); thus, for researchers to under-stand how to ensure effective knowledge-sharingin such teams will contribute to fulfilling this initialdream.

What Does the Virtual TeamingLiterature Suggest for Managinga VC3 Team?

Research on virtual teams (Duarte and Tennant1999; Furst et al. 1999; Johansen 1992; O�Hara-Devereaux and Johansen 1994) has typicallyexamined cross-functional virtual teams withinfirms. Research on cross-organizational virtualteams is quite limited (DeSanctis and Monge1999). Existing research has generally focusedon managing virtual teams, such as motivatingteam member involvement (O�Hara-Devereauxand Johansen 1994), enhancing team members�identification with the group or organization(Nemiro 2000; Wiesenfeld et al. 1999), managinggroup process losses (Finholt et al. 1990), andbuilding trust (Javenpaa and Leidner 1999).

Only a small subset of this research has focusedon knowledge-sharing in virtual teams, articulatingthe types of knowledge content shared, normsdeveloped for sharing, and the effect of knowl-edge-sharing practices on team outcomes. Aneven smaller subset has focused on knowledge-sharing in inter-organizational virtual teams Thisresearch has found that knowledge-sharing invirtual teams is facilitated by evenly distributingknowledge to all team members (Cramton 1997),communicating knowledge of both content andcontext (Cramton 1997), ensuring that informalknowledge-sharing opportunities are not sup-pressed (Kraut et al. 1990), and allowing for deci-sion processes to not become too explicit to bemonitored by others (Bowers 1995). Underlyingthese findings is the long held recognition thateffective electronically-mediated communication,collaboration, and coordination rests on a sharedunderstanding among team members about the


MIS Quarterly Vol. 25 No. 2/June 2001 231

problem, norms (of knowledge capture, sharing,and use; of work distribution; and of roles andresponsibilities), and context for interpretingknowledge (Clark 1996; Clark and Brennan 1991,1993; Davenport and Prusak 1997; Dougherty1992; Krauss and Fussell 1990; Madhaven andGrover 1998; Marshall and Novick 1995).

For the virtual team to have such a sharedunderstanding usually requires that members startwith a common set of norms, context, and prob-lem definitions, either because they have workedtogether previously, or they have worked in thesame organization, product line, industry, ordiscipline. For example, Ahuja and Carley�s (1999)virtual team in a research organization consists ofindividuals with long-standing relationships (somesince the early 1980s). Wiesenfeld et al.�s virtualteams were from the same sales department of acompany.

For some virtual teams, there is no sharedunderstanding when the team is initiated becausethe team members belong to different companieswith no previous working relationship. In this case,the shared understanding must be created. Mostvirtual teams studied to date that must create(rather than use) this shared understanding do soby collocating the team members for a period oftime at the beginning of a project when the workprocess is the most creative, contentious, andlikely to require significant consensus-building(DeMeyer 1991; Haywood 1998; O'Hara-Deve-reaux and Johansen 1994; Zack 1993).3 Onceshared understanding is created, team membersand tasks are dispersed back to their homeorganizations and locations, with future discus-sions coordinated through computer-mediatedcommunication using the shared social contextgenerated at the outset. For example, whenDaimler and Chrysler merged, they organized avirtual team of people from the purchasing depart-ments in Detroit and Germany. The cultures andprocedures of the two companies before themerger were so different that, initially, the virtual

team members had difficulty even communicating.Team members were then brought together for amulti-day meeting and social activities to "get toknow each other" and then sent back home tocontinue their purchasing activities as a virtualteam.

Bringing a team together in a single collocatedmeeting may be feasible if the team's task isconstrained to a limited set of possible solutionsusing a known decision process. In this singlemeeting, the solution space, decision process,roles, and responsibilities can be decided uponand people can disperse to work on their tasks.However, there is a limitation to this model ofvirtual teaming in which collocation creates theshared understanding. This model presumes thatthe concept, roles, context, and norms can becreated at the outset in a collocated meeting andthe virtual team's task is to refine or carry outthese expectations. But what about the dynamicswhen it is the creation of the initial concept itselfthat is the task of the virtual team?

When the task is a highly innovative one, as is thecase with VC3 teams, the methods used to createshared understanding for teams that can distributetheir work or follow routine work processes maynot apply. Creative work is substantially differentfrom routine problem-solving in the following ways:(1) solutions demand synthesis of domain specificknowledge (Kalay 1989), (2) solutions are gene-rated in unpredictable ways (Safoutin and Thurs-ton 1993), (3) tools to evaluate ideas are withoutprecedent so that both the analysis and solutionneed to be generated concurrently (Hendersonand Clark 1990), (4) the design process is a seriesof seemingly unresolvable tradeoffs, with prioritiesamong tradeoffs emerging as the design pro-gresses and the process gradually builds a con-sensus around the solution that meets thesepriorities (Fox 1993), (5) problems are often notwell-specified, being understood only as they aresolved (Sage 1992), (6) tasks cannot be easilyapportioned to individuals since everybody makesan unpredictable contribution to the process(Hubka and Eder 1996), and (7) expectationsevolve (rather than are fixed and followed) aboutthe task, work, collaboration, context, jargon, andassumptions (Gabarro 1990; Krauss and Fussell1990).

3An exception to this is Javenpaa and Leidner's (1999)study of virtual teams that needed to create a sharedunderstanding entirely virtually; however, their focus wason examining how the team's practices led to increasedtrust, not knowledge-sharing.



While there have been studies of virtual teamscharacterized as innovative, the teams rarely fulfillall of these characteristics of highly innovativecross-value-chain teams. For example, while soft-ware development is typically considered anunstructured and non-routine task (Kraut andStreeter 1995), software development is divisible,i.e., it is decomposable into small modules to bedeveloped independently, with the modules inte-grated into a common product. In fact, this is con-sidered best-practice software development. Thisdivisibility does not preclude informal interaction,but it does allow some work to be accomplishedwithout interaction as well as the clear assignmentof roles�features not found in highly innovativework.

These characteristics of highly innovative teamssuggest that a single collocated session is insuf-ficient to work out the expectations about theprocess, problem, or solution in VC3 teams. Innon-virtual creative teams, continuously collocatedmeetings would be held to allow the shared under-standing to evolve as new information and ideasare developed. However, continuously collocatedmeetings violate the precept and associated bene-fits of virtual teams. Moreover, these character-istics of highly innovative teams call into questionthe applicability of existing theories used toexplain behavior in virtual teams. For example,Jarvenpaa and Leidner point out that Meyerson etal.�s (1996) theory of swift trust assumes clear roledivisions and periodic face-to-face meetings. Asanother example, McGrath's (1991) time, inter-action, and peformance theory suggests that con-sensus formation is best reserved for face-to-face.But, if the team is continuously in a consensus-formation mode, as is the case in a team gene-rating, evaluating, modifying, and discarding newdesign alternatives each week, this would suggestthat consensus formation cannot occur virtually.We argue, therefore, that highly innovative deci-sion processes demand virtual knowledge-sharingthat is distinct from the knowledge-sharingtypically observed in research on virtual teams.Table 1 summarizes the distinctions.

The opportunity to observe a VC3 team over timeallowed us to address certain fundamental ques-tions about how to manage the knowledge-sharingprocess in VC3 teams:

� In what ways do processes of collocatedcreative teams need to be adapted to suit theknowledge-sharing needs of a VC3 team?

� How are the obstacles of a lack of initial sharedunderstanding overcome in a cross-organi-zational virtual environment? What impact doesit have on knowledge-sharing in the team?

� How are the obstacles to knowledge-sharingamong team members overcome in a virtualenvironment?

� How does the team ensure that team membersdo not feel left out from the knowledge-sharingprocess of the team, especially if certain teammembers resort to in-person, one-on-one inter-actions with some collocated (or nearby) teammembers?

� What steps can be taken or roles created tomake sure that appropriate knowledge is storedin the best possible manner for future retrievaland is accessible to team members withminimum search effort?

These are some of the issues that were ad-dressed by Boeing-Rocketdyne and several otherpartners in a VC3 team. The team succeededbeyond management�s expectations. The authorsof this paper were fortunate to be able to observethe team closely throughout its 10-month life andlearn how the team eventually addressed theseissues. It is their story to which we now turn.

The Case ofBoeing-Rocketdyne

The team, called SLICE for Simple Low-costInnovative Concepts Engine, was initiated byBoeing-Rocketdyne, the major manufacturer ofliquid fueled rocket engines in the United States.Rocketdyne�s rocket engines were facing newcompetition in an expanding market driven by theneed for commercial launches of communicationssatellites. Rocketdyne�s business objective withSLICE was to be able to drive the cost of a rocketengine down by 100 times, be able to get the



Table 1. Challenges of a VC3 Teams

ManagementFactors In the case of virtual teams�

In the case of Boeing-RocketdyneVC3 Team �

Objectives of theteam

� ...clearly defined objectives andtasks (e.g. softwaredevelopment)

� ...emergent new design with everchanging tasks

Development ofshared under-standing

� ...members often bring sharedunderstanding to the teamthrough a common allegiance toa profession or organization

� ...shared understanding must becreated since there are no commonallegiances

Frequent oppor-tunities for inter-action with teammembers

� ...opportunity for collocation fromtime-to-time allows forspontaneous face-to-faceinteraction�albeit minimal

� ...with members having primaryobligation to their own company,collocation is infeasible; allinteractions were through virtualmedia only

Role definition � ...roles can be well-defined atoutset, aiding team success

� ...roles must be flexible to respondto emerging task, problem, andsolution

Coordination norms � ...communication protocols aboutwhat gets communicated towhom, when, and how, can beestablished at the outset and aidteam success

� ...communication protocols aredifficult to define upfront since teamneeds change

engine to market 10 times faster than it had beenable to for the Space Shuttle main engine, andincrease the useful life of a rocket engine by afactor of three. The breakthrough nature of thistask cannot be underestimated: in the beginning,none of the senior technical managers at Rocket-dyne�who collectively had hundreds of years ofexperience designing rocket engines� thoughtthat it was possible; only an advanced programmanager was willing to try it.

The key participants in the SLICE team includedeight people: a project team leader, conceptdesigner, lead engineer, combustion analyst, andthermal analyst from two different geographically-separated organizations in Rocketdyne; a manu-facturability engineer and CAD (Pro-Engineer)specialist from Raytheon (then Texas Instruments)located 1,000 miles away, and a stress analystfrom MacNeal-Schwendler Corporation, located100 miles away. These individuals were picked to

work on the team because of their highly valued(world class) expertise in their specialty disci-plines. Team members from Raytheon andMacNeal-Schwendler, as well as the projectleader, did not have rocket engine designexperience, so the team did not share a commonunderstanding of the process by which rocketengines are designed. The team members hadnever worked together on previous team activitiesand thus they did not have a common set ofnorms for coordinating. The team worked for 10months on the project, with no team memberdevoting more than 15% of his or her time. Sincetime was precious, the team opted to minimizetravel; as a result, the only time that all memberswere collocated at a team meeting was the lastday of the project at the final technical review andcelebration. However, at the one-day kickoffsession, in which the team received training in thecollaborative tool, six of the eight members werepresent.



Figure 1. Internet Notebook Interface

The team faced many challenges. They neededto solve a product development problem in a trulyinnovative way. The team needed to perform itswork virtually without the benefit of face-to-facemeetings using a new collaborative technology(see Figure 1). The team was comprised ofpeople from different disciplines, different productexperiences, different organizations, and differentdesign processes who had never worked together.Finally, the team needed to converge on a designidea that was acceptable to Rocketdyne seniormanagement�s conservative perspective, since itwas senior management who needed to approvethe design for formal testing.

SLICE Team: TheSuccess Story

Despite these challenges, the team was a run-away success. The team successfully designeda thrust chamber for a rocket engine made of sixparts instead of the normal ~1,200 (a 200-folddecrease in part count), a manufacturing costreduction from $7 million to $0.5 million (a 14-folddecrease), and a predicted quality level of 9sigma, meaning less than one failure out of 10billion, instead of the current industry best-practiceof 6 sigma and more conventional 2 to 4 sigma for



rocket engine combustion devices. In addition,the normal first unit production cost of $4.5 millionwas reduced to $47,000. The team was able toachieve all of this with no member serving morethan 15% of their time, within budget, within 10months instead of six years, with more than a 50%reduction in total engineering hours compared totraditional teams. On the basis of a formal end-of-the-project technical review by the seven seniortechnical managers, the project was judged assuccessfully achieving its objectives. The mana-gers approved the design for the next step in thedevelopment process: a cold-flow test assessingthe validity of the analytic assumptions of liquidflow through the parts.

Fortunately, we were able to closely trace thelifecycle of the team using several data collectionmethods: ethnographic observation, panel ques-tionnaire surveys, interviews, �lessons learned�group meetings, and weekly logs of collaborativetechnology usage. One of the study authorsbecame a participant observer in the team�s pro-cess, attending all 89 virtual meetings andanalyzing all 651 entries in the CollaborativeTechnology referred to as the �Internet Notebook�(using the metaphor of an Engineer�s Notebook)and a Project Vault (for the files unlikely tochange). The entries included requirements,major models and analyses, budgets and sche-dules, as well as briefing charts and other docu-ments, creating a single source of product andprocess data. The log of the activity of the teammembers in using the Notebook and the Vaultwere examined to determine which functions ofthe technology team members used. Finally, alessons-learned session was conducted withsenior managers of the project.

Patterns across these data were investigated toidentify those management practices that seemedto contribute to the success of the team. Wefound three such practices were needed in orderfor this VC3 team to succeed:

(1) Strategy-Setting: Establishing an umbrellaagreement in advance of team formation

(2) Technology Use: Using collaborativetechnology not only to collaborate but also tomanage knowledge

(3) Work Restructuring: Restructure workprocesses without changing the core creativeneeds of the team

We elaborate each of these management prac-tices, using examples from our case to illustrateour points.

Management Practice 1: Strategy-Setting�Establish A VirtualTeaming Umbrella AgreementPreceding the CreativeTeam Project

Prior to the SLICE team, even prior to the concep-tualization of the SLICE team, senior managers,contract managers, and program managers at thethree companies engaged in a series of dis-cussions and negotiations. The three companieswere identified through a series of discussions inwhich best practices were shared and the skills ofemployees were discussed. These discussionstook about a year and focused on identifying thecomplementary skills that each partner companycould bring to a creative design process if onebecame needed, the compelling business reasonsfor each company to share their resources and theskills and knowledge of their employees in acooperative venture, and solutions for handlingthe risks associated with such a cooperativeventure. Resulting from these meetings was afairly simple written agreement between the topmanagers at each company, referred to as the"Continuous Ordering Agreement." This writtenagreement defined the contractual obligations thecompanies entered into on how intellectualproperty would be defined and allocated, howcompany confidential information would beprotected, how liability would be allocated, etc.Importantly, the agreement specified the level ofparticipation of member companies to a virtualteam, ensuring that one company would notdominate the process, nor reap the majority of therewards. This umbrella agreement did not refer toa particular project or task order, but was insteadintended to cover specific task orders when aparticular business opportunity arose to warrantthe companies teaming on a particular project.



Umbrella Agreement Comes In Handy

One of the companies suffered significant management upheaval during the course of the project andthe team members from that organization were pressured to renege on their commitment to be engagedin the design effort. The agreement of equal participation in the effort, however, prevented managementfrom pulling the team members. Thus, the management practice the team found critical to its successwas the creation of an umbrella agreement between firms that resolved issues of core competencies,contribution to team efforts, stability of team membership, and open information-sharing before the teamwas formed so that the team could progress in a supportive context.

To have had senior managers at each companysign this written agreement required many addi-tional non-written agreements. These agreementshad as much to do with trust and understandingbetween similar-level managers at the partnercompanies as it had to do with the specifics ofhow the agreement would be implemented withineach company. A critical part of creating the trustinvolved clearly defining how the risks were to bemanaged in each company. For example, onesenior manager would only agree once he wasconvinced that the senior managers at the othercompanies perceived each company's corecompetency in a design effort in complementaryand non-competitive ways. A senior manager atanother company was quite concerned about theuse of his engineers on design projects notcurrently part of his organization's product portfolioand showed no interest in teaming until he wasconvinced that the arrangement would broadenhis company's product portfolio in strategicallymeaningful ways. Another part of creating thetrust was working out how project responsibilitieswould be handled. Typically, project activities andbudgets are subdivided between organizations,having the effect of organizations focusing exclu-sively on their own deliverables and budget. Inaddition, the agreement called for the creation ofonly a team statement of work when the time for aspecific statement of work was required. Theteam statement of work would not decompose thetask into tasks specific to each company. More-over, there would be only one team budget withoutbreakouts for either companies or individuals.This type of an agreement forced the respon-sibility and associated budget for the entire teameffort to be allocated to all team members andallowed them the discretion to reallocate

resources as needed across organizationalboundaries. Every activity, therefore, was placedin the context of the total project scope andbudget.

Having the Continuous Ordering Agreement inplace proved critical to the success of the team.First, since it covered intellectual property andconfidentiality arrangements, the engineers on theteam reported that they could openly shareinformation since they did not have to worry aboutmanagement's concerns about sharing infor-mation. Second, having the agreement in placemeant that, when the business opportunity forSLICE did arise and a purchasing agreement witha statement of work needed to be generated andapproved before work could start, the elapsedtime from idea to project kick-off was dramaticallyreduced (from months to days). Finally, havingthe agreement in place protected the team frommanagement changes (see the box: UmbrellaAgreement Comes in Handy).

Management Practice 2: CollaborativeTechnologies are KnowledgeManagement Technologies

The team�s collaborative technology�the InternetNotebook and the Project Vault�were explicitlydeveloped by a third party in response to a list ofrequirements specified by several team members.The notebook technology allowed members tosecurely access it from anywhere; to create,comment on, reference-link, search, and sortentries that could consist of sketches, snapshots,hotlinks to desktop applications, texts or tem-plates; and an electronic white board that allowed



Technology Enabler: Coordination Protocol

� Use a pre-specified list of keywords (three keywords to describe each entry) in order to facilitate easeof finding entries later on.

� Receive training on the use of the Notebook before starting design work so time during meetingswould not be spent in training.

� Create reference links for each entry that was derived from or built on other entries in order tofacilitate later recall of the history of entries.

� Create and use notification profiles so that each person would be informed when new entries werecreated that were of a type they had chosen to be relevant.

� Use templates for agendas, minutes of meetings, action items, and decisions so that a standardizedsearch would yield relevant information.

� Take time before meetings to enter comments on others' entries (to encourage the asynchronouswork on the project and appropriate preparation for meetings).

� Create new entries when changes to existing entries are needed so that a train of thought could beobserved and the original author could preserve his ideas.

� Copy and paste important entries into the Document Vault for configuration control.

� Conduct meetings as electronic meetings (everyone logging into the Notebook at the same time andviewing and revising the same entry) supplemented with audio (as teleconferencing when needed)with everyone's complete attention devoted to the meeting.

� Use the Notebook for all communication and knowledge-sharing needs (including, for example e-mailand file sharing).

� Use the navigation search capabilities to find needed information quickly.

for near-instantaneous access to the same entry(see Figure 1). Thus, from the outset, the teamhad the advantage of having a technology expli-citly suited to their initially defined needs. Theteam focused their early discussions on creatinga coordination protocol for facilitating its colla-borative use (see the box: Technology Enabler:Coordination Protocol). The Project Vault allowedsecure common file storage and transfer for thesefiles, both large and small, on an as-needed basis.These capabilities thus created the immediatelyaccessible single source of both product andprocess data for all enterprise-wide activitiesassociated with the project.

The protocol the team developed made teammembers change the way they normally workedwith other engineers in fundamental ways: fromface-to-face discussions to complete reliance ontechnology for collaboration, from sharing infor-mation on a need-to-know basis to sharing allinformation with everyone on the team all the time,from using personal collaborative tools (e.g.,different e-mail applications across the com-panies) to using a single one. Initially, then, withthis coordination protocol, the team made a state-ment that said: all information will be entered intothe notebook and shared among all members allthe time.



Over time, this protocol needed to be modified incritical ways. Most of the modifications came notbecause collaboration was difficult using thetechnology but because the management of theknowledge became difficult. One such example ofthis need to develop new norms for managingknowledge occurred very early in the project. Theteam quickly discovered that there was too muchinformation being generated to be captured andthat much of the information was likely to haveonly transient utility (e.g., as new designs aregenerated, old designs, discussions, and analysesare of limited value); thus, their expectations thatthey would document everything was just toocumbersome. To manage the overwhelmingamount of knowledge needing to be conveyed, theteam learned to couple written documentation (asentries) with oral communication. That is, theproject team leader began to call for twice-weeklybrainstorming sessions using teleconferencingcoupled with the Internet Notebook (eventuallyyielding 86 �virtual meetings� in total or about 2.5per week). In preparation for each meeting, teammembers would post incomplete entries, whichwould then be the source of much discussionduring the teleconference. Thus, ultimately, theteam followed the protocol by sharing all knowl-edge with everyone�but only because everyonewas required to be on the teleconference andlogged into the network and view documents.

Another example of the team needing to modify itscoordination protocol to accommodate knowledgemanagement issues was the initial total relianceon the collaborative technology; i.e., the prohibi-tion of face-to-face discussions on the projectwhen chance encounters between project mem-bers occurred, as they occasionally occurredwhen some members saw each other at anothermeeting or in the company cafeteria. Threeweeks into the project, one member of the teamlet slip in a teleconference that he had had a face-to-face conversation with another team member;the remaining team members indicated that thiswas against the coordination protocol and muchdiscussion ensued. In the end, the team agreedthat the issue was not one of enforcing a rule thatprohibited face-to-face conversations but toensure that knowledge gained during face-to-facemeetings was shared with all. All team members,therefore, agreed to create entries that would

briefly describe the results of face-to-facemeetings from this point forward. This was criticalto maintaining a feeling of �equality� among teammembers.

Yet a third example of the team modifying itscoordination protocol to accommodate the com-plex knowledge management issues was theprotocol that insisted that team members woulddevote their exclusive attention at all virtualmeetings. The team quickly learned that col-located workers on other teams from their parentcompany often interrupted busy team membersduring lengthy teleconferences to ask questions. Initially, team members negatively viewed theseinterruptions and a team member�s willingness tosuccumb to these interruptions, even temporarily,during a teleconference. However, over time, theteam began to realize that the issue was nothaving the team member�s complete attentionduring a teleconference (since, often times, highlyspecific issues were discussed that did not haveimmediate consequence to all members), butrather having the team member�s knowledgeimmediately available during a teleconferencewhen needed. Thus, a team member might beanswering a question from someone at the parentcompany, but then return to the teleconferencewhen the project leader called, �Dick, we need younow; please return.� Thus, the coordinationnorms shifted from providing complete attention to�just-in-time knowledge-sharing.� This acceptanceof just-in-time knowledge sharing had an addi-tional benefit. Since team members were locatedin their own offices with their own powerfuldesktop tools, and given �permission� to performmultiple tasks simultaneously, team membersbegan to use their powerful desktop analysispackages to analyze designs during meetings.This is an activity that would normally have beenconducted �off-line� and it would have taken daysto get everyone back into a room to discuss theresults. Instead, doing just-in-time analysisprovided immediate feedback about the feasibilityof a design idea, saving the team weeks in thedesign process (see the box: Just-in-TimeAnalysis). Extension of these ideas led to aredefinition of the concept of a meeting, fromconventional meetings via telephone to meetingsas work time where all tools and skills are with youin the �meeting.�



1 2 3 4 5

Template

Sketching

Navigation

e-mail Notification

Authoring Entries

Snapshots

Remote Access

Reference Links

Hot Links

1 2 3 4 5

Template

Sketching

Navigation

e-mail Notification

Authoring Entries

Snapshots

Remote Access

Reference Links

Hot Links

Just-in-Time Analysis

In one distinct illustration, the combustion analyst sketched an idea into the Notebook during ateleconference�an idea that required a certain number of holes to be drilled into a metal plate. Asdebate raged about the number of holes, the CAD engineer used his desktop CAD tools to create amore detailed CAD drawing of the sketch and then analyzed it. He discovered during the tele-conference that the drawing required more holes than there was room for! The combustion analyst wasimmediately convinced of the problem with his idea. The team then brainstormed solutions to thisproblem, yielding a new sketch. This capability to answer questions analytically from the desktop duringmeetings greatly sped up the design process

(1 = not useful at all; 5 = very useful)

Figure 2. Ratings of SLICE Members at Project End on Usefulness of NotebookFeatures for Information Retrieval

Yet, even though the team eventually had over1,000 entries to search in the Notebook, and eventhough searching occasionally took 10 minutes ofa 45 minute teleconference (see the box: Knowl-edge Retrieval Is Hard), the team never found itdesirable to use reference linking, multiple key-words, and more than rudimentary search capa-bilities (by a first keyword or the date). Forexample, only 37% of the entries had two or morekeywords (not the three stipulated in the Protocol).

Why did the team profess to be interested insophisticated knowledge management (i.e.,knowledge capture and retrieval) capabilities butrarely use them? Upon further inspection, thereasons became clear: the team was generatingso many new ideas (20 conceptually distinctdesign ideas were generated and evaluated) insuch quick iterations that most of the knowledgein the repository was obsolete, and that which wasnot obsolete could be reasonably easily remem-



Knowledge Retrieval Is Hard

Lead Engineer: �LK and I have just started to talk about how to treat the annulus. They are in thefamous HB/LK entry; the one describing the sketch. Which one was that, HB?�

HB: �I forgot.�

Producibility Engineer: �Could it be 905?�

Lead Engineer: �No.�

Producibility Engineer, looking at another entry: �On the manifold, do you want to cast that flangeon it? I thought [another team member] had a better idea. But which entry was that?�

Other team member: �I don�t remember which one.�

Producibility Engineer: �Is it #867 since that was the last PRO-E model we had?�

Other team member: �I think it�s 915; no, maybe 911.�

bered and found by someone on the team, whenneeded. In other words, the tool did not (and couldnot) have a functionality to automatically deter-mine when something was obsolete, and no oneon the team was interested in "cleaning up" aftera design idea was discarded. It is not just that thetask of attaching keywords can be onerous for theteam members whose primary role is to creativelyconceptualize new products. Even if they tried toclassify the entries according to keywords, verysoon they found that information was changing toorapidly for them to gauge the nature of entries, letalone classify them based on keywords (see thebox: Changing Information Makes KeywordsObsolete).

Our conclusion for management practices, then,is that the key to designing collaborative techno-logies for VC3 teams is to recognize that it is acollaborative knowledge management system thatis, in reality, being designed and used. Thus,capabilities should be designed to facilitate knowl-edge management, and norms to encourageknowledge sharing and reuse should be identified.We believe that knowledge management evenwith a good collaborative tool is a very messy pro-cess and this team benefitted from �far-from-perfect� practices.

Management Practice 3: RestructureWork Without Changing CoreCreative Needs

In the beginning, the team thought it essential tocompletely restructure every work process it usedin order to adjust to the virtual teaming mode: fromthe engineering tools to how decisions weremade, from how meetings were run to how designideas were generated. Over time, however, theteam learned that while work processes needed tobe restructured to accommodate the virtual natureof the collaboration, restructuring should not affectthe basic creative needs of the team. The teamlearned that its ability to be creative rested onhaving three requirements met:

� a shared understanding of the problem, pos-sible solutions, analysis methods, andlanguage,

� frequent interaction with all team members inorder to share work-in-progress, brainstormideas, and test out solutions, and

� rapid creation of information that is highlycontext-specific (i.e., specific to a particularconversation or problem) and then equally rapiddiscarding of information.



Changing Information Makes Keywords Obsolete

At the end of the project, one team member suggested wistfully: �You know, it would have been agood idea if we had created a new keyword for each new concept so that we could search easier.�

Another member pointed out: �How could we? We often didn�t even know when we were doing anew concept rather than just a revision to the existing concept.�

Creative Need 1: Create aShared UnderstandingTo create a shared understanding within a crea-tive team, the team initially adopted the commonpractice found in their best-practice design teamsof centralizing the process around the lead engi-neer, who determined what needed to be sharedabout what. The concept behind �heavyweight�lead engineers is that they listen to different ideasfrom the different specialists and then offer newdesign solutions that meld the different perspec-tives. Because of their best-practice experiences,the team members encouraged the lead engineerto take a centralized role in the coordination ofinformation.

Despite initially agreeing on a centralized role forthe lead engineer, team members quickly foundthat, since a single repository was being used tohold all the information, team members becameknowledgeable not just about the information thelead engineer wanted to discuss with them, butabout all the information concerning the projectthat had been entered. This meant that teammembers were commenting on all aspects of thedesign, not just the aspect that was aligned withtheir discipline or the aspect that the leadengineer was interested in discussing with them.Individual team members reported that they foundthis enhanced participation to allow them to bemore productive as well as lead to a more excitinginvolvement in the project. While the lead engi-neer at first chafed at this change, he eventuallyaccepted the less centralized role. However, forall members of the team to fully participate in allaspects of the design, the team found it necessaryto develop a common language for brainstorming.Efforts to use discipline-specific or product-specific language failed since members were not

all equally versed in each other�s discipline orproduct. Instead, what worked was the use of�common-language� metaphors (see the box:Metaphors Create a Common Language). Without shared artifacts, shared understandingsuffers. To accelerate the development of sharedunderstanding, then, managers of VC3 teamsneed to help the team create shared artifactsquickly. One way the team did this early on wasthe creation of an entry in the Notebook thatcontained an empty matrix listing the 12 designsgenerated to that point. Each team member wasrequested to evaluate each design for itslikelihood of meeting the functional requirementsof each analyst�s area of expertise and to insertthe results of this evaluation into the matrix. Theteam obliged and found the process enormouslyvaluable�not for the outcome (the designreceiving the highest evaluation was eventuallydiscarded) but for the shared understanding aboutthe design process that the matrix created. In thewords of one team member, �With that entry, I feltwe were a team and we knew our role on thatteam.�

Creative Need 2: Engage inFrequent InteractionIn collocated teams, team members frequentlyreport that some of the best discussions occurspontaneously, based on frequent interactionswith collocated workers. Carrying this into theteam's virtual environment, team membersexpressed concern that one-on-one conversationswould harm the team since it could lead tomembers feeling left out, or feeling inadequatelybriefed about information critical to their per-formance on the team (see the box: GuardingAgainst Alienation).



Metaphors Create a Common Language

Stress tests indicated that the proposed injector would not be strong enough to survive lift-off. The teammembers struggled with various ways to increase the strength, spending some time trying to �point� outvarious places where the design could be reinforced. Nothing captured the imagination and consensusuntil one of the team members suggested that the team add reinforcement to the middle, �like anagitator in a washing machine.� That simple metaphor was immediately understood, accepted and usedas the basis for redesign.

Guarding Against Alienation

In the words of one team member: �It is very important to me to not feel left out. If I�m not there[meaning not physically collocated at Rocketdyne], I want to know I�m not missing anything.�

Incomplete Entries as Catalyst for Knowledge Generation

Halfway through the project, a new combustion analyst joined the team. One of the analyst's firstentries was a design concept that had an inaccurate parameter. When one of the team membersidentified the inaccuracy in a meeting, the analyst simply wrote a comment on his entry by crossingout the inaccurate number and replacing it with the right one, rather than feeling the need to createa new entry with the correct number. This simple act of the analyst changed the dynamics of theteam; after that point, the team members began putting more entries into the repository that wereless formal (e.g., spelling errors, for example), and with comments indicating corrections.

Thus the team replaced one-on-one conversationswith frequent all-team conversations. The teamalso handled this frequency of interaction issue bybroadening out the definition of interaction toinclude posting of entries to the knowledge base;team members who reviewed postings were vir-tually interacting with members. To facilitate fre-quent posting and review of entries, the teamleader forced the use of the Internet Notebook forall file-sharing and information-sharing; forexample, project management plans, statusreports, budgets and cost sheets, meetingagendas, meeting announcements, and meetingminutes were all posted exclusively through theNotebook. In addition, initially the members werereluctant to post entries in the repository becausethey had the impression that entries should becomplete before posting; in the words of one teammember, �this repository might be subpoenaed in

the future if there is an accident on the launchpad.� Over time, however, team members be-came less concerned about the completeness ofentries and more concerned about sharing entries.In fact, incomplete/inaccurate entries becameseen as a source for healthy discussion, which inturn led to new knowledge creation (see the box:Incomplete Entries as Catalyst for KnowledgeGeneration). Ultimately, the continuous sharingand documentation of work in progress was one ofthe biggest shifts from the norm for the engineers.Instead of each �engineer� accepting a workassignment, working it to its end, assuring itscorrectness, and preparing a pretty method topresent his results to the rest of the team, teammembers presented their ideas and sketches,relying on past experience and expert judgment.The more detailed analysis followed when ideasstabilized.



Creative Need 3: Rapidly CreateContext-Specific KnowledgeTwenty designs were generated in the course ofthe 40-week project, with most designs havingless than one week of life before being discarded.To rapidly create designs, team members from thedifferent disciplines would come to each tele-conference with design sketches that would havebeen entered immediately prior to the meeting;then, during the meeting, team members wouldmodify the sketches using the electronic drawingboard capability while explaining the reasons forthe change and how the change was intended toaffect the design parameters. The team foundthat drawing sketches by hand during meetingswas too time-consuming and thus modifyingexisting drawings was much more efficient. Inaddition, the team also came to realize thatsketches could not contain all the informationnecessary (because no member wanted to spendthe time to refine or elaborate the sketch for com-munication to others). Thus, the highly context-specific knowledge of the design (e.g., �this sketchpresumes that we use X type of material� or �thissketch assumes that the fluid will flow in thefollowing manner after take-off�) were saved forthe teleconferences when each sketch wasdiscussed and redesigned. Team members feltthat this process encouraged members to entersketches, albeit incomplete ones, and allowedmembers to focus their discussions on theassumptions of the design as they were madeexplicit in the conversations.

Summary of How to RestructureWork with VC3 TeamsTable 2 summarizes the way the SLICE teammanaged their core needs, comparing thesepractices to those often used in collocated teamsor virtual teams where concept development isdone in a collocated fashion. In sum, then, wefound that the team was able to function suc-cessfully because it changed its work processesto meet its core needs. That is, the core needs ofcreative teams do not change just because theteam becomes virtual and inter-organizational;how these needs are achieved, however, willchange.

Not only were new practices needed in setting thestrategy through an umbrella agreement, in de-signing technology that evolved with the team�sneeds, and in identifying work processes that faci-litated the creative effort, we found that effortdevoted to each practice area�strategy, techno-logy, and work�was different over the life span ofthe project. The team found that strategy prac-tices needed to be put into place before either thework or technology practices were initiated.

In addition, the team found that their dependenceon the technology and coordination protocol(albeit one that eventually changed) required thatthe technology needed to be in place before theteam�s work process started. In fact, the teamstart was delayed several times while the tech-nology was being debugged. Once the tech-nology was in place, however, the team learnedthat it needed the ability to modify the technologyas its work processes were adapted. In fact, 23versions of the technology were created duringthe course of the project, in large part the result ofcomplaints lodged by team members to thetechnology developer. As a result, a technologyfacilitator was required to attend all telecon-ferences so that problems could be fixed imme-diately (such as someone not understanding howto perform a particular operation, or a server goingdown and rerouting or notification was needed, ora team member using an old version of thetechnology). Finally, throughout the project, theteam needed to devote effort to its work practicessince many of the initial practices did not workonce the project got underway. Figure 3 depictsthe differential effort required in these three areasof technology, strategy, and work practices overthe course of the project.

Implications for Practice

Whether the objective be tactical in nature (i.e.,reduction in costs and time, increase in quality) orstrategic (i.e., increased flexibility, creation of newknowledge competencies), VC3 teams will in-creasingly be favored in the search for oraterenewal through shared destiny with other organi-zations. It is very likely that global and knowledge-intensive competition will make it imperative topool the intellectual capital of employees across



Table 2. Structuring Core Processes for VC3 TeamsCore Needs

of Creative TeamsPractices of

Collocated Creative TeamsPractices Adopted by

VC3 Teams

Development of sharedunderstanding

� Lead engineer is �spoke-in-the-wheel� for coordinatinginformation and consolidatingideas into new design proposals,which constitute the sharedunderstandings of the team.

� From spoke-in-the-wheelcoordination (with leadmanager/engineer in center) todemocratic coordination

� Encourage development anduse of �common-language�metaphors

Frequent opportunitiesfor interaction with teammembers

� Collocation allows for frequentand spontaneous interaction.

� Coupling use of knowledgerepository with synchronous andfrequent teleconferences

� Allowing for one-on-onediscussions when need arisesbut documenting results foreveryone

Rapid creation andsharing of context-specific transientinformation

� Most discussion verbal andundocumented, hard to capturethe context.

� Promote only minimal catalogingof new information�even to theextent of restricting it to�touchstones� and�placeholders�

� Timely and frequent discussionsof new entries in knowledgerepository to enable members tolearn the context

Early Warning Signs

! Team not being able to initiate their creative task�bogged down in seeking administrativeclearances.

! The collaborative tool not being utilized by team members for the creative task entrusted to them.

! Expression of dissatisfaction with processes by team members in early stages.

! Team process hits a dead end and new ideas not being floated or discussed.

! Sparse knowledge entry into the repository of the collaborative tool.

! Entries are being made into the repository but log files show that team members are not calling upentries.



Strategy

Technology

Work process

EffortRequired

Time

Figure 3. Effort Distribution Across Team�s Lifecycle

organizations and geographical distances, andthat increasing time demands are making itdifficult to do so through the traditional mode offace-to-face collocated teams. Organizations areturning to VC3 teams to solve this paradox.Although every VC3 team will take on a life of itsown, there are some early warning signals that, ifpaid heed to, can ensure the success of the team(See the box: Early Warning Signs).

The success of such teams will require not justprovision of technology but more importantlyformulation of appropriate inter-organizationalstrategy and structuring of conducive inter-organizational work processes and dramaticreassessments of current business contracts,practices and processes. Further, all three�technology, strategy and work processes� willhave to be flexible enough to be molded to therequirements of each of these teams dependingon their creative requirements.

Implications for Research

As with any case analysis, the generalizability ofthe results can only be assessed by observing

future similar cases and by applying theory tounderstand the behavior patterns. Thus, the firstimplication of this study for future research is toencourage researchers of virtual teams toexamine virtual teams varying in level of inno-vativeness. If these findings are supported infuture research, they suggest that an importantfactor determining how knowledge is shared invirtual teams is the innovativeness of the teamobjectives: highly innovative teams are innovatingin both process and product and thus theirknowledge-sharing practices are likely to evolveover time. Identifying patterns in this evolutionacross cases will be an important first step towardcreating a theory of knowledge-sharing in virtualteams.

This study offers another implication for research.As recently as 1999, DeSanctis and Mongereported that the literature suggests that �sometasks are performed less effectively when doneelectronically; for example: consensus formation�(p. 696). Later in their article, they state: �Aboutthe only consistent finding in the empiricalliterature with regard to task and media is that [thetasks of] thinking convergently, resolving conflict,or reaching consensus [are] better done face-to-face than electronically� (p. 697). Finally, they



conclude: �exchanges involving knowledge-elicitation or sharing may more readily lendthemselves to the virtual mode than thoseinvolving consensus formation....There is a greatneed for research that isolates the task conditionsthat are most effective in virtual settings� (p. 697).The SLICE case calls such statements intoquestion. Clearly, the eight engineers were per-forming tasks that involved convergent thinking,conflict resolution, and consensus development�and managed to do so without the use of face-to-face. Why the difference between our findingsand those in the extant literature? One explana-tion might be provided by DeSanctis and Mongewhen they point out that much of the researchresults described in the literature are based onstudies of electronic mail and computer-conferencing systems, rather than the type ofknowledge portal technology used in this case, aswell as communications that use multiple media.In electronic mail, it may be harder to combinecontext and content, whereas combining portaltechnologies with voice allows for making author-ship, documents, document histories, and teamcomments as well as context accessible to allparticipants simultaneously. Thus, one implicationof this case is to suggest that task-media fitquestions are not the right questions to ask atall�especially with highly innovative teams. Insuch teams, knowledge-sharing for purposes ofinforming others cannot be distinguished fromconsensus-building, since it is in the process ofconsensus-building that knowledge is shared, andvice versa. Thus, the research question is not oneof predefining which tasks will work and won�twork in virtual settings, but how tools, workprocesses, and group and organization structurescan be designed to facilitate knowledge capture,dissemination, and synthesis under different taskconditions.

Finally, the SLICE case clearly raised researchquestions about how to structure knowledge-management systems for radical innovation. Theengineers never effectively resolved the issuedespite working closely with the technologydeveloper to produce 23 different technologyversions during the 10 months of the team activity,and working closely with management to bepermitted to make extraordinary modifications inthe typical engineering work process. In the end,

the team members never did use the tool�spowerful navigation and search functionalities, nordid they ever document any but the most rudi-mentary context knowledge possible. Forexample, design rationale documents were neverprepared; as a result, a team in the future will notfind the 600-plus entries in the Notebook of muchvalue. The team also never did resolve the issuesof speedy knowledge retrieval. In the end, theyrecommended that VC3 teams should considerestablishing a role of a knowledge manager. Sucha knowledge manager can serve several func-tions. First, the knowledge manager can ensurethat valuable information is not left unrecorded inthe knowledge repository by reviewing theroadmap of the repository and identifying obviousgaps in logic. For example, if explanations,circumstances, and constraints for quantitativeestimates are missing from an entry (for example,the circumstances under which the impingingholes in a design would be too expensive), theknowledge manager could ask for more detail.Second, the knowledge manager can help toensure that outsiders such as managers canreview the entries in the information repository, byproviding an easy way for others to get theinformation they need. Finally, the knowledgemanager can ensure that the team is able to makeuse of the documentation that they create byreminding the team of past information andhelping them find it when needed.

This problem of how to design knowledgemanagement systems for innovation has beenrecognized by other scholars as well. Boland etal. (1994) and Malhotra (2000) attribute thisproblem to the simplistic representation ofknowledge management that an information-processing view promotes�a representation thatobjectifies information, presupposes a one-for-onemapping between words in an information systemand objects or conditions in the worlds, andoverlooks the fact that words are symbols whosemeanings are always multiple and ambiguous. Analternative representation of knowledge manage-ment could be one proposed by the distributedcognition literature (Hutchins 1991; Resnick1991). In this view, knowledge is not �shared� perse, but rather individual actors create anunderstanding of knowledge by acting andobserving how others act on this knowledge. A



knowledge management system designed tosupport distributed cognition would need to gobeyond the functionality of a searchable knowl-edge repository. In addition, the system wouldneed to provide an editable whitespace for easilycapturing new ideas and blending idea generationwith selection (Olson and Olson 1996). It wouldalso need to allow automatic categorization of theknowledge, so that users need not presuppose akeyword hierarchy or organization of the knowl-edge. Finally, it would need to support the simul-taneous display of multiple representations ofknowledge�representations that are distinctivefor different individuals as well as varied in level ofdetail (Boland et al. 1994). While the technologyused by the SLICE team had some of thesefeatures (an editable workspace), it did not haveall of them. Future research is required to deter-mine to what degree these additional features willhelp to alleviate the knowledge managementproblems the team encountered. Given the team�ssuccess, maybe technology for knowledgemanagement is less important than technologythat allows knowledgeable people to collaborate.

Acknowledgments

The authors would like to thank the participants ofthe Fifth Annual SIM Academic Workshop (Char-lotte, NC, December 1999) for their encourage-ment and feedback during the preparation of thispaper.

References

Ahuja, M. K., and Carley, K. M. �Network Structurein Virtual Organizations,� Organization Science(10:6), 1999, pp. 741-757.

Boland, R. J., Tenkasi, R. V., and Te�eni, D.�Designing Information Technology to SupportDistributed Cognition,� Organization Science(5:3), 1994, pp. 456-475.

Bowers, J. �Making It Work: A Field Study of aCSCW Network,� The Information Society (11),1995, pp. 189-207.

Clark, H. Using Language, Cambridge UniversityPress, Cambridge, England, 1996.

Clark, H., and Brennan, S. �Grounding theCommunication,� in Perspectives on Social

Shared Cognition, L. Resnick, J. M. Levine, andS. D. Teasley (eds), American PsychologicalAssociation, Washington, DC, 1991.

Clark, H., and Brennan, S. �Grounding in Com-munication,� in Groupware and Computer-supported Cooperative Work, R. M. Baecker(ed.), Morgan Kaufmann Publishers, SanFrancisco, 1993, pp. 222-233.

Cramton, C. D. �Information Problems in Dis-persed Teams,� in Academy of ManagementBest Papers Proceedings, L. Dosier and J. B.Keys (eds.), Georgia Southern University,Statesboro, Georgia, 1997, pp. 298-302.

Davenport, T. H., and Prusak, L. WorkingKnowledge: How Organizations Manage WhatThey Know, Harvard Business School Press,Boston, MA, 1997.

Davidow, W. H., and Malone, M. S. The VirtualCorporation, Harper, New York, 1992.

DeMeyer, A. �Tech Talk: How Managers areSimulating Global R&D Communication,� SloanManagement Review, 1991, pp. 49-58.

DeSanctis, G., and Monge, P. �Introduction tothe Special Issue: Communication Processesfor Virtual Organizations,� OrganizationalScience (10:6), 1999, pp. 693-703.

Dougherty, D. �Interpretive Barriers to SuccessfulProduct Innovation in Large Firms,� Organi-zation Science (3:2), 1992, pp. 179-202.

Duarte, D., and Tennant, N. Mastering VirtualTeams, Jossey-Bass, San Francisco, 1999.

Finholt, T., Sproull, L., and Kiesler, S. �Com-munication and Performance In Ad Hoc TaskGroups,� in Intellectual Teamwork: The Socialand Technological Bases of Cooperative Work,J. Galegher, R. E. Kraut, and C. Eguido (eds.),Earlbaum, Hillsdale, NJ, 1990, pp. 291-325.

Fox, J. Quality Through Design, McGraw-Hill,London, 1993.

Furst, S., Blackburn, R., and Rosen, B. �VirtualTeams: A Proposed Research Agenda,� Paperpresented at the Academy of ManagementMeeting, Chicago, IL, August, 1999.

Gabarro, J. �The Development of Working Rela-tionships,� in Intellectual Teamwork: The Socialand Technological Bases of Cooperative Work,J. Galegher, R. E. Kraut, and C. Egido (eds.),Erlbaum, Hillsdale, NJ, 1990, pp. 79-110.

Haywood, M. Managing Virtual Teams, ArtechHouse, Boston, 1998.



Henderson, R. M., and Clark, K. B. �ArchitecturalInnovation: The Reconfiguration of ExistingProduct Technologies and the Failure ofEstablished Firms.� Administrative ScienceQuarterly (35:1), 1990, pp. 9-30.

Hubka, V., and Eder, W. E. Design Science:Introduction to the Needs, Scope and Organi-zation of Engineering Design Knowledge,Springer, London, 1996.

Hutchins, E. �The Social Organization of Distri-buted Cognition,� in Perspectives on SociallyShared Cognition, L. B. Resnick, J. M. Levine,and S. D. Teasley (eds.), American Psycho-logical Association, Washington, DC, 1991.

Jarvenpaa, S. L., and Leidner, D. E. �Communica-tion and Trust in Global Virtual Teams,� Organi-zation Science (10:6), 1999, pp. 791-815.

Johansen, R. �An Introduction to Computer-Aug-mented Teamwork,� in Computer-AugmentedTeamwork: A Guided Tour, R. Bostrom, R.Watson, and S. Kinney (eds.), Van NostrandReinhold, New York, 1992, pp. 5-15.

Kalay, Y. E. Modeling Objects and Environments,Wiley, New York, 1989.

Krauss, R., and Fussell, S. �Mutual Knowledgeand Communicative Effectiveness,� in Intellec-tual Teamwork: The Social and TechnologicalBases of Cooperative Work, J. Galegher, R. E.Kraut, and C. Egido (eds.), Erlbaum, Hillsdale,NJ, 1990, pp. 111-144.

Kraut, R., Fish, R., Root, R., and Chalfonte, B.�Informal Communication in Organizations:Form, Function, and Technology,� in HumanReaction to Technology: Claremont Sympo-sium On Applied Social Psychology, S.Oskamp and S. Spacapan (eds.), Sage, New-bury Park, CA. 1990, pp. 145-199.

Kraut, R., and Streeter, L.. �Coordination in Soft-ware Development,� Communications of theACM (38:3), 1995, pp. 69-81.

Madhavan, R., and Grover, V. �From EmbeddedKnowledge to Embodied Knowledge: NewProduct Development as Knowledge Manage-ment,� Journal of Marketing (62:4), October,1998.

Malhotra, Y. �Knowledge Management and NewOrganization Forms: A Framework for Busi-ness Model Innovation,� in Knowledge Manage-

ment and Virtual Organizations. Y. Malhotra(ed.), Idea Group Publishing, London, 2000.

Marshall, C. D., and Novick, R. �ConversationalEffectiveness and Multi-media Communica-tion,� Information Technology and People(8:1), 1995, pp. 54-79.

McGrath, J. E. �Time, Interaction, and Perfor-mance (TIP): A Theory of Groups,� SmallGroup Research (22), 1991, pp. 147-174.

Meyerson, D., Weick, K. E., and Kramer, R. M.�Swift Trust and Temporary Groups,� in Trust inOrganizations: Frontiers of Theory andResearch, R. M. Kramer and T. R. Tyler (eds.),Sage, Newbury Park, CA, 1996, pp. 166-195.

Nemiro, J. E. �The Glue That Binds CreativeVirtual Teams,� in Knowledge Managementand Virtual Organizations. Y. Malhotra (ed.),Idea Group Publishing, London, 2000.

O�Hara-Devereaux, M., and Johansen, R. Global-work: Bridging Distance, Culture, and Time,Jossey-Bass Publishers, San Francisco, 1994.

Olson, G. M., and Olson, J. R. �The Effectivenessof Simple Shared Electronic Workspaces�Groupware and Authoring, 1996, pp. 106-126.

Resnick, L. B. �Shared Cognition: Thinking asSocial Practice,� in Perspectives on SociallyShared Cognition, L. B. Resnick, J. M. Levine,and S. D. Teasley (eds.), American Psycho-logical Association, Washington, DC, 1991.

Ring, P. S., and Van de Ven, A. �DevelopmentProcesses of Cooperative InterorganizationalRelationships,� Academy of ManagementReview (19), 1994, pp. 90-118.

Safoutin, M. J., and Thurston, D. L. �A Communi-cations-Based Technique for InterdisciplinaryDesign Team Management,� IEEE Transac-tions on Engineering Management (40:4),1993, pp. 360-372.

Sage, A. P. Systems Engineering, John Wiley &Sons, Inc., New York, 1992.

Wiesenfeld, B. M., Raghuram, S., and Garud, R.�Communication Patterns as Determinants ofOrganizational Identification in a Virtual Organi-zation� Organization Science (10:6), 1999, pp.777-790.

Zack, M. H. �Interactivity and CommunicationMode Choice in Ongoing ManagementGroups,� Information Systems Research (4:3),1993, pp. 207-223.



About the Authors

Arvind Malhotra is an assistant professor in theInformation Technology area at the Kenan-FlaglerBusiness School, University of North Carolina atChapel Hill. Arvind�s research interests are in thearea of consumer behavior in wireless and e-commerce environment, impact of e-commerce onsupply chains, organizational re-invention for digi-tal business, and adoption of technologies bylarge firms. He has received four research grantsfrom Dell to explore various research streamssuch as impact of wireless on industries, mea-suring e-service quality, and e-business metrics.He is a two-time winner of the SIM InternationalPaper award competition (1997, 2000). Arvindteaches the MBA course in information technologyand strategy and an elective course on managingin the wireless age. He has a bachelor's degree inElectronics and Communication Engineering, amaster's degree in Industrial and Systems Engi-neering and a Ph.D. in Information SystemsManagement from the University of SouthernCalifornia..

Ann Majchrzak is professor of informationsystems at the Marshall School of Business at theUniversity of Southern California. She holds aPh.D. in Social Psychology from the University ofCalifornia, Los Angeles. She was previously withthe Institute of Safety and Systems Managementat the University of Southern California. Herresearch interests focus on the development ofchange plans that optimize the synergy betweencomputer-based technologies, human capabilities,organizational structure, and business strategy.She has applied her research in such industrysectors as manufacturing, assembly, and engi-neering design. She has used her research togenerate tools to help technology and organi-zational designers, including HITOP, ACTION,and TOP Modeler (www.topintegration.com). Hertools have been used in Europe, Australia, Northand South America, and with such companies asFord, Hewlett-Packard, General Motors, TexasInstruments, and Hughes. Majchrzak has servedon three National Academy of Sciences com-mittees, written seven books, including TheHuman Side of Factory Automation, has a 1996Harvard Business Review article on �Building a

Collaborative Culture in Process-Centered Organi-zations,� and is the 2000 winner of SIM�s Inter-national Paper Award Competition. Her currentresearch interests include development of know-ledge management tools and processes and thedesign of stakeholder participation processes inthe IS development.

Robert Carman has been at Boeing/Rocketdynefor 17 years as a Program Manager, initially inLasers and Optics and for the last 11 years in pro-pulsion. His current program office is calledEnterprise Technologies, which deals with busi-ness practices, process, methodologies, and infor-mation infrastructures necessary to succeed in the21st century. His passions have been in reducedcost and development cycle time for productsachieved through revolutionary change. Prior toRockwell, Bob was at Los Alamos NationalLaboratory, Livermore National Laboratory, andthe MIT Lincoln Laboratory as a laser and non-linear optics expert of international recognition, atechnical team leader, and as an expert inweapons development within the director�s office.Bob has over 75 refereed publications, severalbook contributions, numerous patents andawards; has lectured in over 10 countries; and hastaught in several universities. His Ph.D. is inPhysics from Harvard University, his BA is fromAdelphi University, and his program managementtraining is from West Coast University.

Vernon Lott is manager of information technologyfor the Texas Metal Fabrication operations ofRaytheon. He has a Bachelor of Science degreein Mathematics from the University of SouthernMississippi. He was previously the Raytheon pro-ject manager on the AIMS (Agile Infrastructure forManufacturing Systems) project, a DARPA agilemanufacturing pilot where he concentrated onbusiness practices for supply chain managementand engineering collaboration. He served as anindustry advisor to the National Center for Manu-facturing Sciences for computer integrated manu-facturing. Projects he has lead include imple-menting ERP (Enterprise Resource Planning),FMS (Flexible Manufacturing Systems), andwarehouse and material handling automation. Hiscurrent interests are factory modeling and manu-facturing planning.

radical innovation without collocation ase...

Documents