evaluate a failed organizational change, identify a theory that could have been used to develop the change, and aapply that theory to the failed change. The paper must follow these standards:

An Improvisational Model of Change Management: The Case of Groupware Technologies Wanda J. Orlikowski and J. Debra Hofman Massachusetts Institute of Technology Sloan School of Management 50 Memorial Drive Cambridge MA 02142-1347 Sloan Management Review, January 1997 Table of Contents Acknowledgments Abstract Introduction An Improvisational Model for Managing Change Case Example: Zeta Summary of Zeta Case Enabling Conditions Aligning Key Change Dimensions Dedicating Resources for Ongoing Support Conclusions Footnotes References Figure s ACKNOWLEDGMENTS We would like to thank the edito r and reviewers for their helpful comments on an earlier version of this manuscript. We gratefully appreciat e the research support of MIT's Center for Coordination Science and Center for Information Systems Research.

An Improvisational Model of Change Management:The Case of Groupware Technologies Abstract In this paper, we present an alternative wa y of thinking about technological change in organizations. This alternative approach is motiv ated by a recognition that traditional models for managing technological change - in which the majo r steps of the change are defined in advance and the organization then strives to implement th ese changes as planned in a specified period of time - are not particularly useful given the more turbulent, flexible, and uncertain organizational situations that many companies face today. Traditiona l models are also not particularly useful for helping the implementation of technologies such as groupware whose unprecedented, open- ended, and context-specific nature make it difficult to predefine the exact changes to be realized and to predict their likely organizational impact. We suggest an alternative model of managing technological change, one that reflects the dynamic and variable nature of contemporary organizations and technologies, and which accommodates iterative experimentation, use, and learning over time. We label such a model of managing technological change "improvisational," and suggest that it may enable organizations to take advantage of the evolving capabilities, emerging practic es, and unanticipated outcomes that accompany use of new technolog ies in contemporary organizations. Introduction In the preface to her discussion of technology design, Suchman (1987: vii) refers to two different approaches to open sea navigation -- the European and the Trukese: The European navigator begins with a plan -- a course -- which he has charted according to certain universal principles, and he carries out his voyage by relati ng his every move to that plan.

His effort throughout his voyage is directed to remaining "on course." If unexpected events occur, he must first alter the plan, then respond accordingly. The Trukese navigator begins with an objective rather than a plan. He sets off to ward the objective and responds to conditions as they arise in an ad hoc fashi on. He utilizes information provided by the wind, the waves, the tide and current, the fauna, the stars, the clouds, the sound of the water on the side of the boat, and he steers accordingly. His effort is directed to doin g whatever is necessary to reach the objective.

(Berreman 1966, p.347) Like Suchman, we too find this contrast in a pproaches instructive, and will use it here to motivate our discussion of managi ng technological change. In particular, we suggest that how people think about managing cha nge in organizations most often resembles the European approach to navigation. That is, th ey believe they need to start with a plan for the change, charted according to certain general organizational principles, and that they need to relate their actions to that plan, ensuring throughout that the change remains on course.

However, when we examine how change actually occurs in practice, we find that it much more closely resembles the voyage of the Trukese. Th at is, people end up responding to conditions as they arise, often in an ad hoc fashion, doing wh atever is necessary to implement change. In a manner similar to Argyris and Schon's (1978) contrast between espoused theories and theories- in-use, we suggest that there is a discrepanc y between how people think about technological change and how they do it. Moreover, we suggest that this discrepancy significantly contributes to the difficulties and challenges that contem porary organizations face as they attempt to introduce and effectively implement technology-based change. Traditional ways of thinking about tec hnological change have their roots in Lewin's (1952) three- stage change model of "unfreezi ng," "change," and "refreezing" (Kwon and Zmud, 1987) .

According to this model, the organization prepar es for change, implements the change, and then strives to regain stability as soon as possible. Such a model, which tr eats change as an event to be managed during a specified period (Pettigrew, 1985) , may have been appropriate for organizations that were relati vely stable, bounded, and whose func tionality was sufficiently fixed to allow for detailed specification. Today however, given more turbulent, flexible, and uncertain organizational and environmental conditions, such a model is becoming less appropriate; hence, the discrepancy. This discrepancy is particularly pronounced when the technology being implemented is open- ended and customizable, as in the case of the new information technologies that have come to be known as groupware. [1] Groupware technologies provide electronic networks that support communication, coordination, and collaboration through faci lities such as information exchange, shared repositories, discussion forums, and messa ging. Such technologies are typically designed with an open architecture that is adaptable by end users, allowing them to customize existing features and create new applications ( DeJean and DeJean, 1991 ; Malone et al., 1992 ). Rather than automating a predefined sequence of operations and transactions, these technologies tend to be general-purpose tools which are used in different ways across various organizational activities and contexts. Organizations need the experience of using groupware technologies in particular ways and in particular contexts to better understand how they may be most useful in practice. In such a technological context, the traditional change model is thus particularly discrepant. The discrepancy is also evident when organi zations are using information technologies to attempt unprecedented and complex changes such as global integration or distributed knowledge management. A primary example of this is the current attempt by many companies to redefine and integrate global value chain activities whic h were previously managed independently. While there is typically some understa nding up front of the magnitude of such a change, the depth and complexity of the interactions among these activities is only fu lly understood as the changes are implemented. For many organizations, such init iatives represent a new ball game, not only because they haven't played the game before but because most of the rules are still evolving. In a world with uncertain rules, the traditional model for devising and executing a game plan is very difficult to enact. And as recent st rategy research has suggested ( Mintzberg, 1994 ; McGrath and McMillan, 1995 ), planning in such circumstances is more effective as an ongoing endeavor, reflecting the changing and unfolding environmen ts with which organizations interact. In many situations, therefore, predefining the technological changes to be implemented and accurately predicting their organiza tional impact is not feasible. Hence, the models of planned change that often inform implementation of new technologies are less than effective. We suggest that what would be more appropriate is a wa y of thinking about change that reflects the unprecedented, uncertain, open-ended, complex, and flexible nature of the technologies and organizational initiatives involved. Such a model would enable organizations to systematically absorb, respond to, and even leverage unexpected events, evolving technological capabilities, emerging practices, and unanticipated outcomes. Such a model for managing change would accommodate -- indeed, encourage -- ongoing and ite rative experimentation, use, and learning.

Such a model sees change management more as an ongoing improvisation than a staged event. In this paper, we propose such an alternative model. After presenting the model, we describe a case study of groupware implementation in a customer support organization to illustrate the value of this alternative model in practice. We conclude by discussing the conditions under which such an improvisational model may be a powerful way of managing the implementation and use of advanced technologies. An Improvisational Model for Managing Change The improvisational model for managing technological change is based on research we have done into the implementation and use of open-en ded information technologies. The model rests on two major assumptions which differentiate it from traditional models of change: first, that the changes associated with technology implementations constitute an ongoing process rather than an event with an end point after which the orga nization can expect to return to a reasonably steady state; and second, that the various tec hnological and organizational changes made during the ongoing process cannot, by definition, a ll be anticipated ahead of time. Given these assumptions, our improvisational change model recognizes three different types of change: anticipated, emergent, and opportunity-b ased. These change types are elaborations on Mintzberg's (1987) distinction between deliberate and emergent strategies. Here, we distinguish between anticipated changes -- changes that are planned ahead of time and occur as intended -- and emergent changes -- changes that ar ise spontaneously out of lo cal innovation and which are not originally anticipated or intended. An exam ple of an anticipated change would be the implementation of electronic mail software whic h accomplishes its intended aim to facilitate increased and quicker communi cation among organizational memb ers. An example of an emergent change would be the use of the electronic mail network as an informal grapevine disseminating rumors throughout an organization. Th is use of e-mail is typically not planned or anticipated when the network is implemented, but often emerges tacitly over time in particular organizational contexts. We further differentiate these two types of changes from opportunity-based changes -- changes that are not anticipated ahead of time but are introduced purposefu lly and intentionally during the change process in response to an unexpected opportunity, event, or breakdown. For example, as companies gain experience with the World Wide Web, they are finding opportunities to apply and leverage its capabilities in ways that were not anticipated or planned before the introduction of the Web. Both anticipated a nd opportunity-based changes i nvolve deliberate action, in contrast to emergent changes which arise spontaneously and us ually tacitly out of people's practices with the technology over time (Orlikowski, 1996) . These three types of change build on each other over time in an iterative fashion (see Figure 1) .

While there is no predefined sequence in whic h the different types of change occur, the deployment of new technology often entails an initial anticipated organizational change associated with the installation of the new hard ware/software. Over time, however, use of the new technology will typically involve a series of opportunity-based, emergent, and further anticipated changes, the order of which cannot be determined in advance because the changes interact with each other in response to outco mes, events, and conditions arising through experimentation and use. One way of thinking about this model of change is to consider, as an analogy, a jazz band. While members of a jazz band, unlike members of a sy mphony orchestra, do not decide in advance exactly what notes each is going to play, they do decide ahead of time what musical composition will form the basis of their performance. Once the performance begins, each player is free to explore and innovate, departing from the orig inal composition. Yet, the performance works because all members are playing within the sa me rhythmic structure and have a shared understanding of the rules of this musical genr e. What they are doing is improvising -- enacting an ongoing series of local innovations which em bellish the original structure, respond to spontaneous departures and unexpected opportunitie s, and iterate and build on each other over time. Using our earlier terminology, the jazz musici ans are engaging in anticipated, opportunity- based, and emergent action during the course of their performance to create an effective and creative response to local conditions. Similarly, an improvisational model for managing t echnological change in organizations is not a predefined program of change charted by manageme nt ahead of time. Rather, it recognizes that technological change is an iterative series of different changes, many unpredictable at the start, that evolve out of practical e xperience with the new technologies. Using such a model to manage change requires a set of proce sses and mechanisms to recognize th e different types of change as they occur and to respond effectively to them. Th e illustrative case presented below suggests that where an organization is open to the capabilities offered by a new technological platform and willing to embrace an improvisational change m odel, innovative organizational changes can be achieved. Case Example: Zeta Zeta is one of the Top 50 software companies in the US, with $100 million in revenues and about 1000 employees. It produces and sells a range of powerful software products providing capabilities such as decision support, executive information, and marketing analysis. Zeta is headquartered in the Midwest, w ith sales and client service field offices throughout the world. Specialists in the Customer Service Department (CSD) at Zeta provide technical support via telephone to clients, consultants, value-added resellers, Zeta client service representatives in the field, and other Zeta employees who use the pr oducts. This technical support can be quite complex. Specialists typically devote several hours of research to each problem, often searching through reference material, attempti ng to replicate the problem, and/or reviewing program source code. Some incidents require interaction with members of other departments such as quality assurance, documentation, and product devel opment. The CSD employs approximately fifty specialists and is headed by a director and two managers.

In 1992, the CSD purchased the Lotus Notes groupw are technology within which they developed a new Incident Tracking Support System (ITSS) to help them log customer calls and keep a history of progress towards reso lving the customers' problems. Following a successful pilot of the new system, the CSD decided to commit to the Notes platform and to deploy ITSS throughout its department. The acqui sition of new technology to facilitate customer call tracking was motivated by a number of f actors. The existing tracking system was a home-grown system which had been developed when the department was much smaller and Zeta's product portfolio much narrower. The system was not real-time, entry of calls was haphazard, information accuracy was a concern, and performance was slow and unreliable. It provided little assistance for reusing prior solutions and no support for th e management of resources in the department.

The volume and complexity of calls to the CS D had increased in recent years due to the introduction of new products, the expanded sophis tication of existing products, and the extended range of operating platforms supported. Such shifts had made replacement of the tracking system a priority, as CSD managers we re particularly concerned that the home-grown system provided no ability to track calls, query the status of pa rticular calls, apprehend the workload, balance resources, identify issues and problems before they became crises, and obtain up-to-date and accurate documentation on work in progress a nd work completed. In addition, calls would occasionally be lost, as the slips of paper on wh ich they were recorded would get mislaid or inadvertently thrown away.

The initial introduction of the new ITSS system was accompanied by anticipated changes in the nature of both the specialists' and managers' wor k. In contrast to the previous system, which had been designed to only capture a brief description of the problem and its final resolution, ITSS was designed to allow specialists to document every step they took in their process of resolving a particular incident. That is, it was designed to enable the capture of a full incident history. As specialists began to use ITSS this way, the focus of their work shifted from primarily research-- solving problems--to both research and documentation--solving problems and documenting work in progress.

The ITSS database quickly began to grow as each specialist documented his/her resolution process in detail. While documenting calls took time, it also saved time by providing a rich database of information which could be searched for potential resolutions. Moreover, this new database of rich information served as an unexpected and informal learning mechanism by providing the specialists with exposure to a wi de range of problems and solutions. As one specialist noted: "If it is quiet, I will check on my fellow colleagues to see what ... kind of calls they get, so I might learn something from them . ... just in case something might ring a bell when someone else calls." At the same time, however, using the ITSS database as a sole source of information did pose some risk, since there we re no guarantees as to the accuracy of the information. To minimize this risk, the specialis ts tacitly developed a set of informal quality indicators to help them distinguish between reliable and unreliabl e data. For example, resolutions that were comprehensively documented, documente d by certain individuals, or verified by the customer were considered more re liable sources of information. In addition to these changes in specialists' work, use of the new system by the CSD managers improved their ability to control the department's resources. Specialists' use of ITSS to document calls provided managers with detailed workload information, which was used to justify increased headcount and adjust work schedules and shif t assignments on a dynamic and as-needed basis.

ITSS also supplied managers with more accurate information on specialists' work process, for example, the particular steps followed to rese arch and resolve a problem, the areas in which specialists sought advice or were stalled, and the quality of their resolutions. As managers began to rely on the ITSS data to evaluate specialists' performance, they expanded the criteria they used to do this evaluation. For example, quality of work-in-progress documentation was included as an explicit evaluation criterion a nd documentation skills became a factor in the hiring process.

As the CSD gained experience with and better understood the capabilities of the groupware technology, the managers opportunistically introduced a change in th e structure of the department to further leverage these capabilities. This change had not been planned prior to the implementation of ITSS, but the growing reliance on ITSS and an appreciation of the capabilities of the groupware technology created an opportunity for the CSD to redistribute call loads. In particular, "first line" and "sec ond line" support levels were estab lished, with junior specialists being assigned to the first line, and senior specialists to the second line. Partnerships were created between the less experienced, junior sp ecialists and the more experienced, senior specialists. Front lin e specialists now took all incoming calls, resolved as many of these as they could, and then electronically transferred calls to their second line partners when they were overloaded or had calls which were especially difficult. In addition to handling calls transferred to them, senior specialists were expected to pr oactively monitor their front line partners' progress on calls and to provide assistance as needed. While this partnership idea was conceptually sound, it regularly broke down in practice. Junior specialists were often reluctant to hand off calls, fearing that su ch transfers would reflect poorly on their competence or that they would be ove rloading their more senior partners. Senior specialists, in turn, were usually too busy re solving complex incidents to spend much time monitoring their junior partners ' call status or progress. In response to this unanticipated breakdown in the partnership idea, CSD mana gers introduced another opportunity-based structural change. They created a new role, that of an intermediary, which was filled by a senior specialist whose job it was to mediate between the first and second lines, regularly monitoring junior specialists' call loads and work in progress, a nd dynamically reassigning calls as appropriate. The new intermediary role served as a buffer between the junior and senior specialists, facilitati ng the transfer of calls and relieving senior specialists of the responsibility to constantly monitor their front line partners. W ith these structural changes, ITSS in effect changed the prior undifferentiated and fixed division of labor within the department to a dynamic distribution of work reflecting di fferent levels of experience, various areas of expertise, and shifting workloads. In response to the new di stribution of work, managers adjusted their evaluation criteria to reflect the changed responsibilities and roles within the CSD. Another change which emerged over time was a shif t in the nature of collaboration within the CSD from a primarily reactive mode of collaboration to one that was more proactive. Because all specialists now had access to the database of calls being worked on in the department, they began to browse through each others' calls to se e which ones they could provide help on. Rather than waiting to be asked if they had a solution to a particular problem (which is how they had solicited and received help in the past), specialists actively browsed through the database of calls seeking problems for which they could offer he lp. This shift from solicited to unsolicited assistance was facilitated by the capabilities of the groupware technology, the complex nature of the work, existing evaluation criteria that stre ssed teamwork, and the long-standing cooperative and collegial culture in the CSD. Consider the following specialists' comments: "Everyone realizes that we all have a certa in piece of the puzzle ... I may ha ve one critical piece, and Jenny may have another piece. ... And if we all work separately, we're never going to get the puzzle together. But by everybody working together, we have the entire puzzle"; "Here I don't care who grabs credit for my work ... this support depart ment does well because we're a team, not because we're all individuals" (Orlikowski, 1995) . Managers responded to this shift in work practices by adjusting specialists' evaluation cr iteria to specifically take unsolicited help giving into account.

As one manager explained: "When I'm looking at in cidents, I'll see what help other people have offered, and that does give me another indicat ion of how well they're working as a team." After approximately one year of using ITSS, the CSD implemented two further organizational changes around the groupware technology. Both of these had been anticipated in the initial planning for ITSS, although the exact timing for th eir implementation had been left unspecified.

First, the ITSS application was installed in three overseas support offices, with copies of all the ITSS databases replicated regularly across the four support sites (US, UK, Australia, and Europe). This provided all support specialists with a more extensive knowledge base on which to search for possibly helpful resolu tions. The use of ITSS in all the support offices further allowed specialists to transfer calls ac ross offices, essentially enacting a global support department within Zeta. Second, the CSD initiated and funded the development of a number of bug tracking systems which were implemented within groupware and deployed in Zeta's departments of product development, product management, and quality assurance. These bug tracking applications, which were modeled on the ITSS application, were linked into ITSS and enabled specialists to enter any bugs they had discovered in their problem resolution activit ies directly into the relevant product's bug tracking system. Previously, the repor ting of bugs by the CSD to other departments was done manually, took many weeks, and involved minimal communication. With the new bug tracking applications and linkages to ITSS, specia lists could also directly query the status of particular bugs, and even change their priority if customer calls indicated that such an escalation was needed. Specialists in particular found this ch ange very valuable. For the other departments, the link with ITSS allowed users such as product managers and developers to access the ITSS records and trace the particular incidents that had uncovered ce rtain bugs or uncovered certain use problems. Only the developers had some reservations about the introduction of the bug tracking application, rese rvations that were associated w ith the severe time constraints under which they worked to produce new releases of Zeta products. In addition to the improved coordination and integration achieved with other departments and offices, the CSD also realized further opportuni ty-based innovations and emergent changes within their own practices. For ex ample, as the number of incidents in ITSS grew, some of the senior specialists began to realize that the inform ation in the system could be used to help train newcomers. By extracting certain records from the ITSS database, these specialists opportunistically created a trai ning database of sample problems with which newly hired specialists could work. Using th e communication capabilities of the groupware technology, these senior specialists could monitor their traine es' progress through the sample database and intervene to educate when necessary. As one seni or specialist noted: "So we can kind of keep up to the minute on their progress. ... If they're on the wrong track, we can intercept them and say, 'Go check this, go look at that.' But it's not like we have to actually sit with them and review things. It's sort of an on-line, interactive thing." As a result of this new training mechanism, the time that it took for new specialists to begin ta king customer calls was reduced from eight weeks to about five weeks.

An emergent change realized during this time re lated to access control. An ongoing issue for the CSD was who (if anybody) outside of the CSD should be given access to the ITSS database with its customer call information and specialists' work-in-progress documentation. This issue was not one that had been anticipated prior to the acqui sition of the technology. While the managers were worried about how to respond to the increasing demand for access to ITSS as the database became more valuable and word about its content spread throughout the company, they continued to handle each access request as it came up. Over time, they had used a variety of control mechanisms ranging from giving limited acce ss to some "trusted" individuals, generating summary reports of selected ITSS information fo r others, and refusing any access to still others.

As one of the managers explained, it was only af ter some time that they realized that their various ad hoc responses to different access requests amounted to, in essence, a set of rules and procedures about access control. By responding loca lly to a variety of requests and situations over time, an implicit access control policy fo r the use of ITSS had evolved and emerged. Summary of Zeta Case Figure 2 represents the change model around the groupware technology followed by Zeta in its CSD. Along with the introduction of the new technology and the development of the ITSS application, the CSD first implemented some planned organizational changes, expanding the specialists' work to include work -in-progress documentation and ad justing the managers' work to take advantage of the real-time access to worklo ad information. These changes were anticipated prior to introducing the new technology. As specialists and managers began to work in new ways with the technology, a number of changes emerged in practice, such as the specialists developing norms to determine the quality and value of prio r resolutions, and managers paying attention to documentation skills in hiri ng and evaluation decisions. Building on these anticipated and emergent changes, the CSD introduced a set of opportunity- based changes, creating junior-senior specialist pa rtnerships to take advantage of the shared database and communication capabilities of th e technology, and then adding the new role of intermediary in response to the unexpected problems that arose around partnership and work reassignment. These changes were not anticipate d at the start, nor did they simply emerge spontaneously in working with the new tec hnology. Rather, they were conceived of and implemented in situ and in response to the oppo rtunities and issues which arose as the CSD gained experience and developed a deeper understanding of the new technology and their particular use of it. This change process ar ound the groupware technology continued through the second year at Zeta when some anticipated organizational changes were followed by both emergent and opportunity-based changes associat ed with unfolding events and the learning and experience gained by using the new technology in practice. Overall, what we see here is an iterative and ongoing series of anticipated, emergent, and opportunity-based changes which allowed Zeta to learn from practical experience, respond to unexpected outcomes and capabilities, and adap t both the technology and the organization as appropriate. In effect, Zeta's change mode l cycles through anticipated, emergent, and opportunity-based organizational changes over time. It is a change model which explicitly recognizes the inevitability, legitimacy, and value of ongoing learning and change in practice. Enabling Conditions Clearly, there were certain asp ects of the CSD and the Zeta organization which enabled it to effectively adopt an improvisational change model to implement and use the groupware technology. Our research at Zeta an d other companies suggests that at least two sets of enabling conditions are critical: aligning key dimensions of the change process, and dedicating resources to provide ongoing support for the ongoing change process. We will consider each in turn. Aligning Key Change Dimensions An important influence on the effectiveness of any change process is the interdependent relationship among three dimensions: the tec hnology, the organizational context (including culture, structure, role s and responsibilities), and the change model used to manage change (see Figure 3) . Ideally, the interaction among these three dimensions is compatible, or at a minimum, not in opposition. First, consider the relation of the change model and the technology being implemented. When the technology has been designed to operate lik e a "black box," allowing little adaptation by users, an improvisational approach may not be more effective than the traditional approach to technology implementation. Similarly, where the technology is well-established and its impacts are reasonably well understood, a traditional planned change approach may be effective.

However, when the technology being implemented is new and unprecedented, and additionally has an open-ended and customizable nature, an improvisational model providing the flexibility for organizations to adapt and le arn through use becomes more approp riate. Such is the case, we believe, with the groupware t echnologies available today.

Second, the relation of the change model to organizational context is also relevant. A flexible change model, while likely to be problematic in a rigid, control-oriented or bureaucratic culture, is well-suited to a more informal and cooperative culture such as the one characterizing the CSD.

In another study (Gallivan et al., 1994) , we examined the MidCo organization's successful adoption and implementation of CASE (Computer-Aid ed Software Engineering) tools within its IS organization. While MidCo, a multi-national chemical products company with revenues of over $1.5 billion, was a relatively traditional organization in many ways, key aspects of its culture--a commitment to total quality manage ment, a focus on organizational learning and employee empowerment, as well as a long-term tim e orientation--were particularly compatible with the improvisationa l model it used to manage ongoing organizational changes around the new software development technology. Finally, there is the importan t relationship between the technology and the organizational context. At Zeta, the CSD's cooperative, team -oriented culture was compatible with the collaborative nature of the new groupware techno logy. Indeed, CSD's existing culture allowed it to take advantage of the opportunity for im proved collaboration afforded by the groupware technology. Moreover, when existing roles, respons ibilities, and evaluation criteria became less salient, the CSD managers expanded or adjust ed these to reflect new uses of the technology.

Compare these change efforts to those of Alpha, a professional services firm which introduced the Notes groupware technology to leverage knowledge sharing and to co ordinate distributed activities (Orlikowski, 1992) . While the physical deployment of groupware grew very rapidly, anticipated benefits were reali zed much more slowly. Key to the reluctance to use groupware for knowledge sharing was a perceived incompatibility between the collaborative nature of the technology and the individualistic and competiti ve nature of the organization. As in many professional services firms, Alpha rewarded in dividual rather than team performance, and promoted employees via an "up or out" set of evaluation criteria. In such an environment, knowledge sharing via a global Notes network wa s seen to threaten status, distinctive competence, and power. In contrast to Zeta, mana gers at Alpha did not adjust policies, roles, incentives, and evaluation criteria to better align their organization with the intended use and capabilities of the technology they had invested in. Dedicating Resources for Ongoing Support An ongoing change process requires dedicated su pport over time to adapt both the organization and the technology to changing organizational conditions, use practices, and technological capabilities. Opportunity-based ch ange, in particular, depends on the ability of the organization to notice and recognize opportuni ties, issues, breakdowns, and unexpected outcomes as they arise. This requires attention on the part of appropriate individua ls in the organization to track use of the technology over time and to implement or initiate organizatio nal and/or technological adjustments which will mitigate or take advantage of the identified problems or opportunities. At Zeta, it was the managers and technologists who primarily played this role, incorporating it into their other responsibilities. So, for example, the managers adjusted the structure of their department by introducing first li ne/second line partnerships to facilitate a dynamic division of labor, and then made further adaptations by intro ducing an intermediary role to overcome some unanticipated difficulties associated with the initial change. Similarly, the technologists working with the CSD incorporated enhancements to the ITSS system as they realized ways of improving ease of use and access time. The CSD's commitment to noticing and responding to changes when appropriate did not end after the implementa tion of the technology. The managers clearly realized that the change pro cess they had embarked on with the use of groupware was an ongoing one, as one manager noted: "We've had IT SS for two years. I'm surprised that the enthusiasm hasn't gone away. ... I think it' s because it's been changed on a regular basis....Knowing that [the changes are going to get implemented keeps you wanting to think about it, and keep going." Ongoing change around the use of groupware te chnology also requires ongoing adjustments to the technology itself as users l earn and gain experience with the new technology's capabilities and their uses of it over time. Without de dicated technology support to implement these adaptations and innovations, the continued experi mentation and learning in use central to an improvisational change model may be stalled or thwarted. At Zeta, the CSD's use of groupware and ITSS was supported by a dedicated technology group. Initially consisting of one developer, this group grew over time as use of the technolo gy expanded. After two years of technology use, the group included four full-time technologists who provided technology support for the various systems that had been deployed within Zeta vi a the Notes platform. The group also maintained strong ties with all their user s through regular meetings and communications with them. This dedicated and ongoing technical s upport ensured that the technology would continue to be updated, adjusted, and e xpanded as appropriate.

The value of ongoing support to enable ongoing organizational and technological change was similarly important in another organization we studied, the R&D division of a large Japanese manufacturing firm (Orlikowski et al., 1995) . A newly-formed product development team within the R&D division installed its own groupware t echnology, the Usenet news-system (a computer conferencing system). Similar to Zeta, the team's use of this new technology also iterated among anticipated, emergent, and opportu nity-based changes over time. Here, a small group of users who had previously used the groupware technol ogy took on the responsibility to manage and support its ongoing use for themselves and their colleagues. They tracked technology usage and project events as they unfolded, responded as appropriate with adjustments to communication policies and technology functionality , and proactively made changes to the team's use of the conferencing system to leverage opportunities as they arose. Conclusions Global, responsive, team-based, networked--these are the watchwords for organizations of the nineties. As managers redesign a nd reinvent organizations in a new image, many are turning to information technologies to enable more flexib le processes, greater knowledge sharing, and global integration. At the same time, effec tively implementing the organizational changes associated with these technologies remains di fficult in a turbulent, complex, and uncertain environment. We believe that a significant factor contributing to these challenges is the growing discrepancy between the way people think about technological cha nge and the way they actually do it. We have proposed here that people's assumptions about technology-based change and the way it is supposed to happen are based on models which are no longer appropriate. Traditional models for managing technology-based cha nge treat change as a sequential series of predefined steps which are bounded within a specif ied period of time. With these models as a guide, it makes sense -- as the European navigator does -- to defi ne a plan of action in advance of the change and track events against the plan, st riving throughout the change to re main on track. Deviations from the intended course -- the anticipa ted versus the actual -- then require explanation, the subtle (and sometimes not-so-subtle) implication being that th ere has been some failure, some inadequacy in planning, that has led to this deviation. Indeed, many organizational mechanisms such as budgeting and resource pla nning are based on these notions. The problem is that change as it actually occurs today more closely resembles the voyage of the Trukese navigator, and the models and mechanisms most commonly used to think about and manage change do not effectively support the experience of change in practice. In this paper, we have offered an improvisati onal change model as a different way of thinking about managing the introduction and ongoing use of information technologies to support the more flexible, complex, and integrated structures and processes demanded by organizations today. In contrast to traditional models of technological change, this improvisational model recognizes that change is typi cally an ongoing process made up of opportunities and challenges which are not necessarily predictable at the star t. It defines a process which iterates among three types of change -- anticipated, emergent a nd opportunity-based -- and which allows the organization to experiment and learn as it us es the technology over time. Most importantly, it offers a systematic approach with which to understand and better manage the realities of technology-based change in organizations today. Because such a model requires a flexible and responsive environment, adopting it implies that managers relinquish what is often an im plicit paradigm of "command and control" (Zuboff, 1995) . An improvisational model, however, is not anarchy and neither is it a matter of "muddling through." We are not implying that planning is an activity which is unnecessary or should be abandoned. We are suggesting, instead, that a pl an is a guide rather than a blueprint (Suchman, 1987) , and that deviations from the plan, rather than being seen as a symptom of failure, are to be expected and actively managed. Rather than pre-defining each step to be taken an d then controlling events to fit the plan, the idea is to create an environment which facilitates im provisation. In such an environment, management provides, supports, and nurtures a set of expectations, norms, and resources which guide the ongoing change process. Malone (1996) refers to such a style of managing as "cultivation." Consider again the jazz band. While each member of the band is free to improvise during the performance, the result is typica lly not discordant. Rather, it is harmonious because each player operates within an overall framework, conforms to a shared set of values and norms, and has access to a known repertoire of rules and resour ces. Similarly, while many of the changes at Zeta's CSD were not pre-pla nned, they were compatible with the overall objectives and intentions of the department's members, their shared norms and team orientation, and the designs and capabilities of the technology at hand.

Effectively executing an improvisational change model also requires aligning the technology and the organizational context with the change model. Such alignment does not happen automatically. It requires explicit and ongoing examination and adjustment, where and when necessary, of the technology and the organization. As such, mechanisms and resources allocated to ongoing support of the change process are critical. Tracking and noticing events and issues as they unfold is a responsibility that needs to be owned by appropriate members of the organization. Along with the responsibility, these organizational members require the authority, credibility, influence, and resources to implement the ongoing changes. Creating the environment, aligning the technology, contex t, and change model, and distributing the appropriate responsibility and re sources are critically important in the effective use of an improvisational model, particularly as they re present a significant (and therefore challenging) departure from the standard practice in effect in many organizations today.

It is important to bear in mind, however, that an improvisational model of change will not apply to all situations. As we have noted, it is mo st appropriate for open-ended, customizable technologies or for complex and unprecedented ch ange. In addition, as one of our reviewers noted, "jazz is not everyone's 'cup of tea'... some people are incapable of playing jazz much less able to listen to what they consider to be ' noise.'" We noted above that some cultures do not support experimentation and learning. As a resu lt, they are probably not receptive to an improvisational model, and are less likely to succ eed with it. However, as these organizations attempt to implement new organizational forms, they too may find an improvisational model to be a particularly valuable approach to mana ging technological change in the 21st century. References Argyris, C. and Schon, D.A. Organizational Learning, Reading, MA: Addison Wesley, 1978. DeJean, D. and DeJean, S.B. Lotus Notes at Work, New York: Lotus Books: 1991. Gallivan, M.J., Hofman, J.D., and Orlikowski, W.J. "Implementing Radical Change: Gradual Versus Rapid Pace," Proceedings of the Fifteenth International Conference on Information Systems, Vancouver, British Columbia, Canada, December 14-17, 1994: 325-339.

Kwon, T.K. and Zmud, R.W. "Uni fying the Fragmented Models of Information Systems Implementation," in R.J. Boland Jr. and R.A. Hirschheim (Eds.) C ritical Issues in Information Systems Research, New York: John Wiley and Sons, 1987: 227-251.

Lewin, K. "Group Decision and Social Change," in Newcombe, E. and Harley, R. (Eds.) Readings in Social Psychology, New York: Henry Holt, 1952: 459-473. Malone, T.W., Lai, K.Y. and Fry, C. "Experiments with OVAL: A Radically Tailorable Tool for Cooperative Work, Proceedings of the Third Conference on Computer Supported Cooperative Work, Toronto, Canada, November 1992: 289-297.

Malone, T.W. Private communication. 1996. McGrath, R.G. and MacMillan, I.C. "Discovery-Driven Planning," Harvard Business Review, 72, 1, 1995: 44-54.

Mintzberg, H. "The Fall and Rise of Strategic Planning," Harvard Business Review, 72, 1, 1994:

107-114.

Orlikowski, W.J. "Learning from Notes: Organi zational Issues in Groupware Implementation," Proceedings of the Third Conference on Computer Supported Cooperative Work, Toronto, November 1992: 362-369.

Orlikowski, W.J. "Evolving with Notes: Organizational Change around Groupware Technology," Sloan School of Management Working Paper #3823, MIT, Cambridge, MA, 1995.

Orlikowski, W.J. "Improvising Organizational Transformation ove r Time: A Situated Change Perspective," Information Systems Research, 7, 1, 1996: 63-92. Orlikowski W.J., Yates, J., Okamura, K. and Fujimoto, M. "Shaping Electronic Communication:

The Metastructuring of Technology in Use," Organization Science, 6, 1995: 423-444.

Pettigrew, A.M. The Awakening Giant. Oxford, UK: Blackwell Publishers, 1985.

Suchman, L. Plans and Situated Actions: The Probl em of Human Machine Communication.

Cambridge, UK: Cambridge University Press, 1987.

Zuboff, S. In the Age of the Smart Machine, New York: Basic Books, 1988 Footnotes [1] Not all goupware technologies are flexible and customizable (e.g., fi xed-function electronic mail systems). We are interested here only in those that are (e.g., Lotus Notes).