I would like to thank the members of Zeta Corporation who participated in this research, as well as Michael Gallivan, Cheng Goh, Lorin Hitt, and George Wyner who collected data during the initial research phase, and Debra Hofman for her comments on an earlier draft of this paper. The research support of the Centers for Coordination Science and Information Systems Research at the Massachusetts Institute of Technology is gratefully acknowledged.

Table of Contents

ABSTRACT

RESEARCH SITE AND METHODOLOGY

Research Setting

Research Methodology

Table 1: Number and Type of Interviews in Zeta Corporation

RESULTS

Table 2: Planned and Emergent Changes in CSD during different periods of ITSS Use

I. Initial Use of Groupware Technology within the CSD

Planned Change in Nature of Specialists' Work

Figure 1: Sample record from the Inform database

Figure 2: Sample record from the ITSS database

Planned Change in Nature of Managers' Work

Emergent Change in Distribution of Work

Emergent Change in Form of Collaboration

II. Later Use of Groupware Technology within the CSD

Planned Change in Nature of Global Support

Planned Change in Inter-departmental Coordination Mechanisms

Emergent Change in Knowledge Utilization

III. Assessing the Changes around Groupware Technology

CONCLUSION

Organizational Changes around Groupware

Process of Managing Change around Groupware

REFERENCES

FOOTNOTES

This paper examines the use of a groupware technology--Lotus Development Corporation's Notes(trademark)--in the context of customer support to understand how the technology was used to enable organizational changes over time. Building on its successful implementation of the technology two years ago, the customer support department underwent a number of organizational changes that altered the nature and distribution of work, forms of collaboration, utilization and dissemination of knowledge, and coordination with internal and external units. These changes were enacted through a series of intended as well as opportunistic modifications to both the technology and the organization. The effectiveness of this change process suggests a strategy of implementing and using groupware technology that focuses first on enacting some initial planned organizational changes, and then builds on these to enact emergent changes in response to the opportunities and conditions occasioned by the planned changes. Because groupware technologies are largely open-ended and adaptable, this process of evolving organizationally with the technology over time may be a particularly useful way of implementing organizational change around groupware.

Global, responsive, team-based, networked -- these are the watchwords for organizations of the nineties. As companies struggle to redesign and remake themselves in a new image, many are turning to advanced information technologies to enable more flexible and integrated processes. One class of technologies that is increasingly being used in this manner is that of coordination technologies or groupware. These are technologies that conceptually and architecturally represent a break with previous paradigms of organizational technologies that were dominated by the two models of on-line, mainframe-based, transaction processing systems on the one hand, and stand-alone, personal computer-based productivity tools on the other. With groupware, the intent is to provide support for coordination and collaboration through group access to technological capabilities such as shared repositories, discussion forums, and communication facilities.

While groupware has the potential to support dramatically different organizational designs and processes, that potential may be hard to realize in practice. A number of studies have pointed to the difficulties of integrating coordination technologies into work practices, raising issues such as a lack of critical mass, inadequate training, inappropriate expectations, and structural and cultural problems (Bullen and Bennett, 1990; Grudin, 1988, 1994; Horton, 1994; Kling, 1991; Markus, 1987; Markus and Connolly, 1990; Orlikowski, 1992; Perin, 1991; Rogers, 1994). Some studies, however, have identified conditions under which groupware appears to have been more effectively implemented. For example, Korpela (1994), found that in a networked organization, individuals were willing to use groupware to accommodate a shift to more cooperative work designs. Studying a customer support department, Gallivan et al. (1993) suggested that the successful adoption of groupware was critically influenced by a user-centered development strategy which emphasized specific functionality; a phased implementation strategy that involved multiple pilot studies, and the compatibility of the groupware application with the department's cooperative culture.

The experiences of technology implementation exert a critical influence on the subsequent use of that technology in an organization. While an important indicator of future effectiveness, a successful implementation does not guarantee that use of the technology over time will enable anticipated and beneficial organizational outcomes. Given the relative recency of groupware technologies, few studies have had the opportunity to examine the sustained use of such technologies over a period of time. This paper reports on a study that attempted to do so by following up on the Zeta Corporation, [1]which had experienced a successful implementation of groupware in its customer support department (Gallivan et al., 1993). Two years after the initial installation of the technology, I conducted a field study at Zeta to investigate what influence the ongoing use of groupware had had on the work practices, structures, and interactions of the customer support department.

The findings suggest that the customer support department had built on its successful implementation of groupware in interesting ways, and over the past two years had enacted significant organizational changes in a number of areas: nature and distribution of work, form of collaboration, utilization and dissemination of knowledge, and coordination with internal and external units. Some of these changes were intentional and planned, while others were more opportunistic and emerged from the ongoing practices of the department. In each case, these changes were accompanied by unanticipated consequences that arose as a byproduct of users utilizing the groupware to support their group work. The findings offer a number of contributions to our understanding of groupware technologies in use. First, they offer detailed information about the kinds of structural, processual, and interactional changes that are facilitated by groupware in a particular context over time, and the consequences of these changes for work, performance, and organizing. Second, the findings point to some generalized insights about the process of implementing organizational change around groupware. The particular process followed in this case -- the enactment of a series of planned and emergent changes over time -- was perceived by all major players to have been successful, and may represent a particularly effective and generalizable strategy for implementing organizational change around groupware, given the unprecedented, open-ended, and adaptable nature of this technology. Before discussing these results, I provide some background on the research site, and review the methodology followed in the study.

Research Setting

Zeta is a software company headquartered in the Midwest, with sales and client service field offices throughout the US and the world. The software development, product management, and customer support divisions of the company are located along Route 128 in Massachusetts. Zeta is one of the Top 50 software companies in the U.S., with $100 million in revenues and about 1000 employees. The company produces and sells a range of powerful software products providing capabilities such as decision support, executive information, and marketing analysis. The core technology of these products is the Omni language, a fourth-generation language (4GL) for analyzing multi-dimensional arrays of data. Omni and the application products that use it (e.g., ADS, DSS, FIN, XSS) run on a variety of computing platforms including PCs, Unix workstations, and mainframes. Zeta's products are used by thousands of corporations world-wide.

The focus of this study was the customer support department (CSD) which is part of the Technical Services Division headed by a senior vice-president and comprising Quality Assurance, Training, Documentation, and Customer Support. The CSD is managed by a director and two managers. Its mission is to provide technical support via telephone to all users of Zeta's products, including clients, consultants, value-added resellers, Zeta client service representatives in the field, and other Zeta employees. Technical support is provided by Customer Support Specialists (hereafter referred to as specialists), all of whom have been extensively trained in Zeta's products and in the techniques of problem-solving and providing real-time technical support. All specialists have college degrees, most in the areas of computer science, engineering, and business information technology. The department has grown from 10 specialists in 1990 to its current high of 50 specialists.

Technical support at Zeta is a complex activity. The products utilize advanced networking and database technologies, and allow users to build their own applications on top of the products. As this provides for an almost infinite set of possible problems that CSD specialists may encounter, customer calls are rarely resolved with a brief response. Problems typically involve several hours of research and include searches of reference material, attempts to replicate the problem, and review of program source code. Some incidents require interaction with members of other departments such as product development. Problems identified by specialists as bugs are sent on to product management where they will be assessed for criticality and if appropriate, scheduled for correction. The volume of calls to the CSD has increased significantly in recent years due to new product introductions and acquisitions, and the growing range of operating platforms supported. The CSD is divided into two groups: the General Support group, whose specialists support the Omni language and the executive (XSS) and financial (FIN) information products; and the Marketing Support group, whose specialists support the ADS and DSS products used in marketing analysis.

In January 1992, an initial purchase of the Lotus Notes technology was made to explore the feasibility of using it as a platform for developing a system to track customer calls to the CSD. At the time, the department was using a database (Inform) that had been developed in the Omni language. This database allowed the entry of call information (caller name and number, date and time of call, product referenced, problem description and resolution) and subsequent querying of the data to locate particular problem types. Significant problems with the use of Inform made its replacement a priority. On acquisition of Notes, a developer, newly assigned to the Technical Services Division, worked with one of the CSD managers and several specialists to design, prototype, and test a trial tracking system in Notes. By mid-1992, the Incident Tracking Support System (ITSS) had been developed, and evaluations of its use in practice began. The evaluation occurred in two phases: an experimental pilot involving the General Support group from July to September 1992, and an expanded pilot involving the Marketing Support group from September to December 1992. Both pilots exceeded expectations, with managers and specialists indicating support and enthusiasm for the new technology (Gallivan et al., 1993). By the end of 1992, the Technical Services Division declared Notes as the platform for incident tracking and related applications, and acquired an additional 200 Notes licenses. Gallivan et al.'s (1993) study ended in December 1992, with the CSD department poised to build on its successful initial deployment of Notes and effective implementation of the ITSS application.

Research Methodology

A follow-up study at Zeta was conducted two years later (July - December 1994). Data collection was concentrated within the CSD department, but also included members of other departments that had begun to use Notes to coordinate with the CSD via links to the ITSS system (product development, product management, and quality assurance). Multiple techniques of data collecting were used. Thirty-seven unstructured and semi-structured interviews of sixty to ninety minutes in length were conducted. All interviews were recorded and transcribed. Participants spanned vertical levels and functional groupings, and included specialists from both groups within the CSD, both CSD managers, the CSD director, the Technical Services senior vice-president, members of related departments (product development, product management, QA), and the technologists responsible for the Notes technology and all applications built within it (see Table 1 for a breakdown by function and level). Use of the technology by the specialists was observed by sitting with specialists while they were on the phone and keeping notes on their interactions with the Notes and ITSS technologies. These notes were supplemented with questions to the specialists on particular aspects of their actions. Documents were also examined, and these included records in ITSS, training, and bug databases, ITSS system and user manuals, and the feasibility analysis conducted in 1991 and 1992, which justified the acquisition of a new incident tracking system for the CSD.

The data suggest that use of the Notes technology within Zeta enabled a number of organizational changes in the CSD over the two year period from December 1992 to December 1994. These changes were enacted both intentionally and opportunistically, and were accompanied by some unanticipated consequences. These results paint a picture of a technology-enabled change process that evolves over time through a series of ongoing technological and organizational adaptations that are planned as well as emergent. These two types of changes occur concurrently and are highly interdependent. In the case of Zeta's change process, planned changes dominated the initial period of technology use and set the stage for some emergent changes. In the period of later technology use, both planned and emergent changes were evident and enacted concurrently. Planned as well as emergent changes were typically accompanied by unexpected breakdowns, workarounds, and innovations that modified the process and outcomes of change.

Before discussing this series of changes at Zeta, a brief sketch of work in the CSD before implementation of Notes provides a useful backdrop to understanding the subsequent changes. A specialist recalled in detail what the workflow was like within the CSD before the implementation of the ITSS system.

Reflecting back on what we were doing with our Inform database ... we would type up plain paper forms, put them in an in-basket, and we had an assistant who would type those into the database system, because it was a one-writer type of system. ... We then proceeded to change the architecture a little bit, so everybody essentially had their own little personal copies of the call database. These would generate some files which would be picked up in a nightly batch routine and incorporated into the master, so that within twenty-four hours -- theoretically -- you could search in the master database against calls we took the day before. Big improvement, but the maintenance on the backend was quite expensive. ... Incorporating new forms in the database was very time consuming and fraught with errors as there were bugs. The other aspect of that database, the searching, was painful; it took a very long time. The way the data was organized did not really lend itself to efficient search algorithms.

The initial intentions for the new ITSS system were modest. As one manager recalls "basically, the goal was to replace Inform and provide more value." In replacing Inform, the CSD hoped to improve the tracking of calls, the dissemination of information about the calls, and the management of resources. As managers recalled:

We just wanted to make sure that we were capturing all the information, because it was known that with the Inform system people were not entering information at point of contact ... So we wanted to try and get more information. We wanted it to be available as much as possible in real time. So at 5pm on a Wednesday you could find out if a certain client had called at 11am that day or 2pm, as opposed to having to wander around support saying "did anybody talk to XYZ client today?"

In the days before we had ITSS, everyone had a stack of papers on their desks, or maybe they had entered some of their calls into a PC database, but it was their own local database that maybe they had uploaded into the server ... We were totally unable to produce any type of weekly reporting or any statistics about who called us and why. We weren't quickly able to categorize any of our problems. We had a system, but you questioned the data that was in there because it was cumbersome to get the data in there. It wasn't a real-time system, and people didn't enter calls in there until they were closed. You didn't get the running history. ... If a month had gone by, I had no clue what had gone on. So I would have to go and find the specialist who had worked on the problem and ask them to either remember what had happened or try and find some piece of paper that might have been written down.

With the implementation and use of Notes and ITSS, a number of organizational changes were enacted at different periods. Table 2 depicts these planned and emergent changes as well as the unanticipated outcomes that accompanied these changes. The following discussion examines these changes and outcomes in terms of the two periods of technology use -- initial and later -- and then describes the CSD's assessments of these changes.

I. Initial Use of Groupware Technology within the CSD

This period of using the ITSS technology within the CSD was dominated by the implementation of two planned organizational changes -- changes in specialists' work, and changes in managers' work. As a result of these planned changes, two further organizational changes emerged -- an opportunistic shift in the distribution of work within the CSD, and a change in the form of collaboration among specialists. Both the planned and emergent changes were characterized by a number of unanticipated outcomes described below.

Planned Change in Nature of Specialists' Work

The nature of the specialists' work appears to have changed in at least two ways: ongoing process documentation and online knowledge searching.

Process Documentation

Before the implementation of the ITSS system, most of the specialists' work in supporting customers involved research. This usually meant one or more of the following: searching the Inform database for similar previous incidents, reviewing product documentation and manuals for clues, recreating the problem, reading source code, and asking colleagues. Capturing details of the call and its resolution usually occurred after the fact, and in limited detail. Figure 1 shows a sample record from the Inform database. The new system, ITSS, was designed not just to capture a description of the problem and its subsequent resolution (as in Inform), but also all the steps taken in the process of resolving the incident. Capturing the full "incident history," now requires specialists to log the details of all the activities, however small, they have performed with respect to an incident. Figure 2 shows a sample record from the ITSS database. The documentation of an incident's history, from entry to resolution, provides a complete trace of the process undertaken within CSD to provide an answer to the client. This process orientation represents a change in the focus of the work from primarily research, to both documentation and research. Use of ITSS has thus shifted the work of support from being solely solving problems to both solving problems and documenting work in progress. For specialists, this represented a significant shift in the nature of their work:

Well, I think the thing that's changed the most is the fact that what we use Notes for is to document our work. I think that as we have gotten bigger, the support department in general, that becomes more and more important that you sort of need to have a paper trail, as it were, for what you've done in this interaction with this client. Before you would have, you know, miscellaneous sheets of paper and that sort of thing, nothing that you could really, you know, pull together.

Specialists reported a number of benefits from documenting work process. For example, the ongoing documentation about calls in progress helped them manage the cognitive load of the various problems they were researching, particularly when these activities spread over a number of days:

Name: JENNY             Date: 10/31/90                 Time:

11:00AM








Others: Duane King






Client Name: John Doe                         PHONE:

899-111-1234






Company: Acme Co.                              STATUS:



Time Spent: 30-45 min      Answered Date: 10/31/90        Time:

11:30AM






Product: Omni        Version No: 3.0             Operating

System:

Description: READ DIF FILE INTO WORKSHEET UNRAVEL INTO VARIABLE UPDATE REORGANIZE RECEIVED: SYSTEM ERROR ARGET01 PROBLEM HAS OCCURED. EXPORT/IMPORT DATABASE

Solution: TOLD HIM THIS WAS NOT GOOD! SHOULD EITHER 1) RESTORE FROM BACKUP AND CHECK DB OR 2) EXPORT/IMPORT DB.

Problem Category:

I find it helpful for myself to put in as much information as possible. I find that the more explicit I was earlier, the more it helps me remember when I got back to work on the incident. It gives me a detailed record of what steps I have already performed. It gives you mental feedback.

Another advantage was that the process knowledge helped specialists understand problems better and resolve calls. For example,

For call tracking, all of the history involved, who you contacted, when, what you discussed, how you went about trying to pursue the call is now included. Before with Inform, the phone calls, the personal notes, etc., they never got installed into the system at first. We may not get personal notes in still, but a lot more of what goes on in the call is now tracked. For example, when I'm asked to work on another call for somebody or to look at something, the initial description is okay, but there's always more details in the history where they've asked or tried certain things that didn't work. So I know where to start when I pick up the call and then maybe can add a few suggestions. That certainly wouldn't have happened before, unless there was a verbal exchange about the call and what they had done, but here it's all recorded, and you just look at it, it's in the system.

One specialist had an experience with using ITSS that was particularly revealing about the value of documenting. She was working on one of her calls. Searching in ITSS, she found a prior incident which exactly matched the error message she was seeking. Gratified, she examined the resolution and incident history fields of the incident, only to find them particularly unhelpful. Frustrated and annoyed at the specialist who had created the incident, she accessed the field that identifies authorship, only to discover this was one of her own previous incidents. This experience was recounted by other specialists as a lesson to all of them about the value of documenting their processes.

Incident: XX-1-0999

Owner: Gillian Smith Opened: 12/27/94 09:45 AM

------------------------------------------------------------------------------------------------------------------------------------------------
Company:	Acme Co.
Caller:	John Doe	Title:
Location:	444 Science Park Vista City, MA 02139	Rel:
Phone:	508-111-9999	Fax:	508-111-9999
Call Back:		Phone:

------------------------------------------------------------------------------------------------------------------------------------------------

Product:	DSX 4.13 {4.1700}
Platform:	PC STANDALONE - 486	Environment:	DOS 5.0
Module:	N/A	Workstation:	N/A

------------------------------------------------------------------------------------------------------------------------------------------------------------

Incident Description

Title: In DSX 4.x, how do you populate insample for each mrentry?

Description: Insample is dimensioned by geog, time, and mrentry. Doe wants to populate insample differently for different mrentries, but doesn't know how. He wants to know how.

Res. Type: General Question

Resolution:

------------------------------------------------------------------------------------------------------------------------------------------------------------

Incident Management

Assignee: Tom Brown

Status: Work in Progress Close Date:

Time Now: 10 Time Total: 50 minutes

Bug Number: Severity: 4

Interoffice #: T/O Assignee:

Other #s: Transfer Date:

Reviewed: Not Reviewed

Review Date: Reviewer:

------------------------------------------------------------------------------------------------------------------------------------------------------------

Incident History

***** 12/06/94 09:27:25 AM Jenny Jones (US) {Total Time = 50} (Work in Progress) (S4)

[Tom Brown = Assignee] [Gillian Smith, Tom Brown = MailTo]

"INSAMPLE is a keyword in the control file; you can set it as follows:

ControlfileKeyword ControlFileValue

INSAMPLE INSAMPLE 01011

INSAMPLE INSAMPLE 01013

Can be set with however many measures you want.

I've tried to reach Doe at the above #, but unable to. If he calls back we can give him this info. "

***** 12/05/94 12:11:43 PM Tom Brown (US) {Total Time = 40} (Work in Progress) (S4)

[Tom Brown = Assignee] [Gillian Smith = MailTo]

"Not sure if this is possible. Will consult with Jenny and see .... might have to wait for Arthur ? - We'll see.

Searched GROUCHO for some details. Nothing like this found for 4.13 - only references to the DOS DataServer."

***** 12/05/94 11:59:21 AM Martha Robinson (US) {Total Time = 20} (Open) (S4)

[Tom Brown = Assignee] [Tom Brown, Gillian Smith = MailTo]

"Tom, can you take a look at this call? Apparently Doe called back and would like an answer. If you can't take it please let me know. Thanks, Martha."

***** 12/02/94 10:11:06 AM Gillian Smith (US) {Total Time = 10} (Work in Progress) (S4)

"Talked to Arthur. He has worked with this issue before, and explained that it's complicated. He will refresh his memory and get back to me."

------------------------------------------------------------------------------------------------------------------------------------------------------------

One of the interesting unanticipated outcomes of process documentation was that specialists became very focused on what they documented and how they articulated issues. On the one hand, this focus reflected a cooperative motivation. They wanted to document their incidents in a way that would be most helpful to others. For example:

We are trying to document so other people can benefit. ... If you do document well then typically the next person doesn't have to document again. They can just give a little synopsis and say, "Refer to this one for details." So it provides time-savings in effort and avoids duplication of information.

I'm finding I have to be more careful about how I formulate things. Sometimes I think it takes forever for me to put some comment in because I want to make sure that it's technically accurate, that what I'm saying is correct, non-ambiguous -- mostly because I hate it when people send me queries that have the negative of those qualities. When we used personal notes before I wouldn't have to worry about that, because I knew nobody else had to look at that. And usually I was going to verbalize my queries or comments, rather than have them written and seen.

On the other hand, specialists were very aware that their process documentation was publicly available -- at least to everyone in CSD -- and possibly to other departments and offices in the future. Reflecting this political awareness, they monitored and censored what they did and did not enter into incident histories. For example,

The accessibility of the database is something that I'm always aware of and I think I'm very guarded in what I put into the database. ... I am always concerned about being politically correct, professional, diplomatic

I'm always very careful about how I will word a response or even a question from a client even an internal person. ... I know it's very easy to sit there and really put in some sarcastic comments about the person and in a way it kind of makes you feel better to do that, but I've always not done that specifically for the reason that a year or even six months from now that person may see that incident and take offense and it could jeopardize future relations.

The change in specialists' work to require process documentation suggests an expansion in job definition. Specialists were not only solving problems as effectively as they could, but they were also attempting to articulate and document their cognitive processes and research activities in a manner that was professional, diplomatic, and of value to others. While the work of process documentation took time, it also saved time later when specialists were able to draw on and leverage that information. The expansion of support work to include a process component was reinforced by a change in managers' work (see below) that began to examine specialists' process documentation as part of their performance evaluation.

Knowledge Search

While online knowledge searching had been a part of the specialists' work process with their previous Inform system, searching that database was cumbersome and usually of moderate value given questionable data quality and limited information content. The provision of a powerful search capability within ITSS allowed the specialists to quickly and easily search their database of well-documented incident histories. ITSS was not only a technology for entering calls and documenting work process and problem resolutions. It had also become a valuable knowledge archive, a resource drawn on in the process of research. The continual growth in the size of the ITSS database -- from some 4,000 records in December 1992 to 35,000 in December 1994 -- meant that the value of the knowledge archive continued to increase over time.

Specialists reported resolving more of their problems through online searching. Estimates of what percentage of calls were resolved merely by searching the ITSS database ranged from a low of 35 percent to a high of 75 percent, with the variation due to differences in call complexity and type of product involved. Searching ITSS provided possibly reusable problem resolutions as well as knowledge about problem-solving process. It offered a detailed trace of the work required to resolve different kinds of problems. Two interesting, and unanticipated outcomes of online knowledge searching were ongoing learning, and technological dependence. With respect to learning, the activity of searching the ITSS knowledge archive exposed the specialists to a range of problems and solutions. This had the unanticipated result of keeping the specialists more informed and more aware than they would have been before daily use of ITSS. As such, searching also served as an informal and ongoing learning mechanism. Specialists observed:

I would say even when I'm busy, I typically, every day, review the calls that come into my group. I do it because I like to see what calls are coming in to see if there's anything I haven't seen before, so that I can at least make a small mental note of it, so if it comes up next time I'm on the phone -- you know, basically seeing everything that goes on even though I'm not participating. So then I'll be more prepared when it does come to my turn.

If it is quiet I will check on my fellow colleagues to see what their day was like ... I just see what kind of calls they get, so I might learn something from them. Just to say, "Oh, this is a good call to remember, this is a good error." .. it's like I learn from it. I mean, just in case something might ring a bell when someone else calls.

The corollary of having a particularly valuable knowledge archive to work with is that work practices become increasingly dependent on it in a number of ways. With respect to the physical technology, the unavailability or poor response of the technology created obvious problems for the specialists, for example,

You must have heard, we lost part of our searching capability for like two days. Monday, Groucho[2] died. The way they've got it working now is they've got the one database which is where you basically do all your work, and it's only maintained for like two or three months, ... and then there's this other one which they keep on Groucho, which is all the calls and they have the search indexing defined in that. That database died on Monday. Well, actually, Groucho died over the weekend. I mean, you just came in Monday morning and, it's dead. And we didn't have it for two days. I mean, it was terrible.

Another dependence was the risk inherent in relying on knowledge from the ITSS database when there were no guarantees that the knowledge was correct. The specialists recognized their vulnerability here and developed some norms around using the knowledge base so as to minimize their risk. They looked for patterns among the incidents, sought resolutions that were confirmed by the customer, and confirmed answers with individuals in person. For example:

There is a data integrity problem, because you're relying on people. You know, obviously when new people first start, they may have an idea, but they're not sure. What I find is you have to check several calls to see if you can see a pattern, and to see, "They [the client] called back and said this resolution work." I wouldn't take the resolution unless I was absolutely sure it worked.

An interesting metric developed by the specialists to assess data quality was their use of incident authorship as an indicator of quality. Each incident that is entered is automatically assigned a unique identifier, which includes a code identifying the particular specialist who entered it. Specialists learned the identifying codes of their colleagues, and used these to gauge the quality of knowledge likely to be had in the incident's history and problem resolution fields. For example:

You tend to evaluate information differently from different people. So if you see 40 items from a search you go to the incidents of those folks you've gotten good information from in the past.

I know by the author of the incident. Like for example, I know certain people in the department, and I know that Arthur has a reputation for writing short novels as resolutions. I mean, he's a wonderful source of information and when he has an incident, he really spends the time to put a lot of detail in it. And it's extremely helpful. And I know that he spends a lot of time doing it. So when I get an incident from him, I'm very comfortable with that information. Whereas, some of the other people in the department will put one or two sentence resolutions. And it tends to make it a little vaguer and more difficult to be confident about.

Most specialists indicated that the ITSS database was much more accurate than the previous one, Inform. An important element in this increased accuracy was the use of an explicit quality control mechanism, where senior specialists dynamically monitored and corrected errors or areas of ambiguity in the incidents of new hires and more junior specialists. For example:

We kind of go through the calls and watch the type of information, and give them feedback on it. Occasionally we'll open up a incident, re-edit something, and put them in the comments section, mail them the comment just saying, "I changed this. If you run into one of these again would you make sure you state this."

We'll see somebody's filled an incident out and maybe there were two answers to the problem, and they only really put one answer in the resolution. We might add to their resolution, send them mail just saying, "I added a second option. If the client happens to call back there's this second option we can offer them. And it's also here for search purposes."

While senior specialists promoted appropriate work habits among less experienced colleagues, they did express some concern that junior specialists were beginning to take the ITSS knowledge for granted and not adopting a suitably critical stance. One explained:

What I recommend is people look at more than one call. Don't just take one call and say, "Oh, this is it; this is the resolution." That is a danger, and what tends to happen now is people will just tend to take a resolution out of the database and give it to someone, instead of researching it. We ask that people do both, that they would try it, or that they would see a pattern that the resolution worked. But you see less and less people doing that because they take more calls, and they need to give a rapid response. And it's easy to just say "Oh, I have four things. I'll just tell them to try these four things and hope that it works and they don't call me back."

What this pattern of taken-for-grantedness reveals is a psychological form of technological dependence that was an unanticipated consequence of changing specialists' work around ITSS. This dependence occurs when (particularly more junior) specialists rely exclusively on the technology, and then feel less capable when the technology is unavailable. For example,

We're extremely dependent on these databases. Without them I feel underconfident. I feel I can't do this.

I noticed last week or two weeks ago when Groucho crashed and nobody could search. I noticed that everyone walked out of their office and said, "Oh what do I do, Groucho is down. I don't know what to do." Some of the other people who have been here a while said, "Why don't you just open the book and actually try to research the problem, do some testing, start up Omni, try things out." ... But people almost didn't know what to do when they didn't have the searching available, especially the newer people. They are so dependent on it. I thought, "What's the big deal? Just look through the book or whatever." But these people aren't thinking that way because they have been trained here to do it this way and it really threw them, I think.

Because the work of support had become defined in terms of using the ITSS technology, junior specialists knew no other way of doing support. For many of them, its unavailability created some cognitive and performance problems.

Planned Change in Nature of Managers' Work

A specific objective of the ITSS design and implementation was to address the unavailability of information on the nature and flow of work through the CSD and the utilization of resources. Use of ITSS changed this, and the nature of managers' work changed as a result. They were now able to manage resources more effectively, and perform online process and performance monitoring. Two unanticipated outcomes resulted from this shift in work, a fear of electronic surveillance and some competition among the specialists.

Resource Management

ITSS allowed managers to manage the resources of their department, both in the short term -- being able to dynamically adjust the work schedule to handle volumes and avoid crises -- and in the long term -- being able to assess whether people should be hired, and then using the information to justify this assessment. For example, managers observed:

I now know who's feeling overwhelmed. Before, I didn't know who was overwhelmed. I had no idea. Now if I see that one person has a lot of open issues, and I need to give them some time off the phone, I can do that. I can adjust the schedule at any time.

The system allows us to manage our calls more effectively so that we don't have crises. Crises come up because of misinformation, because someone doesn't get notified or the call doesn't get escalated appropriately or as quickly as it needs to. And when you have a system that allows us on a daily basis to go in and look at calls and quickly zero in on accounts that need to be zeroed in on, we can immediately see if something needs to be reassigned or if we need to get development involved right away. We're managing something before it becomes a crisis. What the system has allowed really, is crisis defusion

I'm able to really see how many calls we take. Before, many times most people didn't enter their calls, and about 50 percent of the calls never ended up actually into our system. And so for head count, that's my one way to get people -- on the numbers. And when you don't have that information, or management knows the information that's there is not accurate, that's a problem. It was really difficult to do a head count. Now, that's not the case.

Specialists' use of ITSS to document their calls ensured that managers had much more information on workload and temporal flow of calls, and as a result could justify increased headcount and dynamically adjust schedules to deal with local changes in workflow.

Process and Performance Monitoring

Specialists' use of ITSS to document their work processes meant that there was now a detailed process trace of every incident worked on by the CSD. Managers indicated that access to this information increased their accountability and their ability to follow-up with clients:

Well, we are certainly documenting more of an audit trail for the problem, which is very helpful. We're becoming much more accountable for issues. I'll get a call from the field saying some client is having major difficulties and if I don't have it documented in ITSS then I can't really address the issues. ... Previously, before we had ITSS, when I would get a call like, "Well, I called in three weeks ago, and I haven't heard anything" -- what do you say to a client? Because I had no documentation on what had or had not transpired with the client. And now I do. So now I can say, "Well, you have heard from us. We called you on this date, and this date," and that really shuts them up.

Specialists similarly appreciated the benefits that the process trace provided them vis-a-vis the customers. The process documentation was a very effective mechanism for "CYA," as one specialist put it. Others concurred:

I'm not worried about a client calling and saying I've never called him back. I never have that worry on my hands. We used to worry about that because, well, some clients lie. And this prevents that from happening. ... they don't do that anymore now because they know that we can check.

Everything is much more organized now and there's an audit trail of everything that's done which eliminates a lot of the gray area where the client said they did this and we didn't do that. We can always prove that we did do that and a lot less slips through the cracks.

The shift to work practices that produced a written trace further meant that much more of the work process was available to managers for monitoring. Managers' evaluation criteria of specialists' performance were explicitly expanded to include documentation, or as one manager explained "how well do they document each incident" and another elaborated:

I look at how well they document their incidents. All of these factors play in: are they accurately describing the problem?; by me reading the resolution am I going to be able to take this resolution and apply it to another call?; the history, if person A is out for a week am I able to go and look at their calls and understand where we're at with each call?

Managers' access to ITSS gave them not just more information on volume of calls, but information on the types of action taken to research a problem, the kinds of interactions engaged in to get and give help, the quality of problem-solving strategy attempted, and the quality of the final resolution. This information provided managers with a much richer understanding of the various activities specialists performed to accomplish their work, and a more accurate means of evaluating work performance, as evident in the following remarks by managers:

[In ITSS] you can see all their interaction going across the screen. ... When I'm looking at incidents, I'll see what help other people have offered, and what type of information are they offering. And that does give me another indication of how well everybody can offer assistance, share information, work together.

We evaluate their technical skills. Again, Notes is part of the way you do that -- looking at the calls they close and how well they resolve them. Where did they go to look for help? Do they get in and get their hands dirty?

I also look at problem-solving skills. ... It's difficult to assess that. I do it usually by just reviewing their open calls and seeing what history and thought process they've gone through.

The managers at Zeta also recognized the need to supplement the information obtained from a Notes database with other input. They also evaluated performance by observing specialists interacting on the phones and with each other in meetings. For example, one manager noted: "I'll be on conference calls many times with somebody in the group, and you can see how well they can handle describing the technical information to the client."

Two unanticipated outcomes of managers' electronic performance monitoring were a fear of electronic surveillance, and an opportunity for social comparison. With respect to the former, a few specialists expressed concern at being "under the microscope." For them, performance monitoring raised issues of self-identity, pressure, and criticism, for example:

You know, they talk about big brother, but, I mean, your boss is supposed to know what you're doing, so what's the big deal? But the real issue is, are they going to start micromanaging the volume? ... Are we going to be measured strictly on volume, or are we going to be measured strictly on how quickly we dump calls?"... I think that's the concern, it's a professional, personal, self-image thing.

As for management, I'm always very careful and very aware that there are politics in any company. You won't get away from it, and these are tools that can be used. I think that they are set up to help the technical support group. That's their primary function. But any of this can be used by management, you know for the good of the company and whether that's also for the good of the employee, may or may not be. So, I think that as far as I am concerned, that's just something that I'm always aware of and careful about.

I know that managers look in on our calls, because I have gotten comments back about having to qualify certain pieces of a call or provide further status, so I do know that they look. How I feel about it depends, I think, on my busyness. On some occasions when I've been very busy and under a lot of pressure, the first thing that comes to my mind is, "God I just wish they'd stop," but when I have time to go home and think about it and relax, I can understand what they're doing and why they're doing it. But at the time it's not taken as positive reinforcement or support from the management. My first gut reaction is to resent it and to just think that it's more pressure.

There was, however, considerable acceptance on the part of most specialists that work monitoring was part of the job and something that could be positive when used to reflect well on individuals and the department. In part, this is attributable to the cooperative culture and to how management have used the data in their evaluations:

Management uses the numbers to justify more personnel, to bring back problems to developers to alert them to what's been happening with a new product. They're your advocate. Numbers have become more of a positive for us rather than being used against us.

They review your work. I mean that's the definition of being a boss and being an employee. So yeah, they're going to read my work. I would not expect them not to. It's not like this is my database, that I put all of my secret hopes and dreams in. You know, it's a working database of what I'm doing. It's a tracking record, so that if I get hit by a bus, they know where I am, and where to pick up, but also they can see what I'm doing. It's my brag record. I have more calls in there than anybody else.

As the last quote implies, those who feel they are performing well welcome electronic monitoring as it makes their competence and productivity more visible and obvious.

The second unanticipated outcome of performance monitoring was that the ITSS system facilitated a form of social comparison and self-evaluation among the specialists, for example:

We look at the day view in ITSS and take a look to see, you know, how many calls this person took versus how many calls I took, and how many calls they closed. And it isn't really competitive as more to get an idea of where I should be. How many calls do people close at a time, or if I have 15 calls open, is that a standard or am I really off base? Am I falling behind? Should I really start working harder at this, that, and the other thing? It's a good guideline. And you can drill down. I think [the managers] take a look at the types of calls that we're getting and which are easier and harder calls. They keep things in perspective whereas I don't normally do that. I just look at the volume of calls and say, "Well, I closed two and I have twelve open. Where am I? What was wrong with me today?" How I feel about that depends on the day. If I've gotten quite a few calls and I think that they're easy calls and I haven't closed them and I feel overwhelmed, I feel like "What was wrong with me today? I know I can do this. What am I doing wrong? Or do I need a vacation now?" It does make you think.

The possibility for specialists to look up each others' workloads also inhibited the tendency to inflate claims of being overworked:

The thing that used to drive me crazy is that people would make all sorts of claims about the volume of work that they were doing ... and there was lots and lots of "poor me," which would drive me crazy because I was doing everything I could to get up to speed, and I was thinking, "Hey I'm going as fast as I can." And when Notes came in and you saw the real numbers, it sort of stopped all that.

Process and performance monitoring was facilitated by the availability of information about work process. This same information availability created visibility of both work and worker, and for some specialists it raised questions of professional identity and autonomy, while for others an opportunity to reveal their competence and accomplishments. Within the CSD, the latter experience of electronic exposure predominated and was clearly tied to how process and performance monitoring was conducted by the managers. A change in these management practices might provoke a shift in the specialists' experiences.

Emergent Change in Distribution of Work

When managers realized the potential of the groupware technology to facilitate the distribution of work within the CSD, they opportunistically initiated a change in the department's division of labor by establishing the position of support partners. This distribution of work, however, ran into some unanticipated difficulties, and the managers responded by initiating a further structural change which established the role of intermediary.

Support Partners

Up till this point, specialists took their own calls and resolved them primarily individually, occasionally consulting with others. Incidents remained the responsibility of the individual who initially took (i.e., "owned") the customer's call. Using the technological capabilities of the Notes groupware technology, CSD managers initiated a new distribution of work that allowed calls to be reassigned dynamically, thus changing ownership of the call after it had been received. Less experienced (junior) specialists were placed on the so-called "front line" to take all customer calls. More experienced (senior) specialists were placed on the "back line," not taking calls but working on calls that had been assigned to them by the front line specialists. Each junior specialist on the front line was assigned a "partner," a senior specialist in the back line. Junior specialists were now expected to electronically transfer calls they felt they could not handle to their partners. Senior specialists were expected to accept the calls assigned to them by their partners, as well as to proactively monitor the calls received by their junior partner to ensure they were handling them adequately, and stepping in with assistance if it was clear the junior specialists were out of their depth or on the wrong track. A manager explained that this new distribution of work was greatly facilitated by the technology:

Notes is a wonderful vehicle for this because the partner's able to see what's coming in as it's coming in, without having to get up from their chair, without having to physically sit next the person.

Many junior specialists reacted positively to the establishment of partnerships. For example,

It's nice because you know these unending sagas that you occasionally get involved in, we don't have to cope with them, we in the front lines. We can just sort of toss them over our shoulder to one of the back end people.

It makes it, you know, easier, because you don't have to -- if you're on the phone and you know that it's a real busy day you don't have to worry, "Oh god, how am I going to able to solve this major crisis, and plus take all these other calls that are coming in?" So this reduces the level of stress that people have, because you don't have to worry about it. If you can't handle it, you pass it.

Conceptually, the partnership idea was sound, but it frequently broke down in practice whenever a critical assumption underlying the idea of partnership -- that front line specialists would transfer their difficult calls to partners -- was violated. An unanticipated outcome of the establishment of the partnership relationship was the apparent reluctance of many junior specialists to reassign their calls to their designated partners. A senior specialist noted:

What we were finding was that the right calls weren't getting transferred to the right people. I think one of the difficulties is that people on the front line like to hang on to their calls and work on them. ... It's kind of a catch-22, because they take too many calls, I think, which overloads them, and it creates more stress, where they should be offloading more calls. But they work on them, which is kind of the opposite of what I thought would happen. I thought they would assign a lot more calls, ... but that's not been the case at all.

Junior specialists explained their reluctance to transfer calls in a number of ways -- concern about overloading their partners, desire to feel competent in the job, and interest in learning. For example,

You can just assign a call to a partner, but I don't. I only assign the call if he offers to take it. That way you're not really dumping on the other person.

I never - I don't like passing off calls, so I take pretty much everything. I don't know, it's kind of like a cop-out for me because I want to learn more about things and it would be kind of a way of not learning. It wouldn't be a learning process.

While junior members were kept informed on the progress of the calls they reassigned, vicarious learning is different from actual experience; it is the difference between spectator and player. And many specialists took pride in being accomplished players. To overcome this reluctance to transfer calls and maintain the partnership concept, managers initiated a second emergent structural change in the CSD, authorizing intermediaries to moderate the flow of work between the front and back lines.

Intermediaries

In each of the two groups within the CSD, a senior specialist was dedicated to serving as an intermediary, and this involved periodically monitoring all the customer calls entered by the front line specialists into ITSS, helping to resolve these calls where possible, and ensuring that call re-assignments to senior specialists, when appropriate, took place. A manager described it this way:

[The intermediary] is more or less kind of protecting the front line people as a group -- not protecting, but overseeing so they're not burdened. I think they would like to be able to handle the calls and sometimes they're reluctant to give them up. So [the intermediary] will keep an eye on how long the call has been open, what kind of questions have they been asking, so that if it looks like they've come to a stop or they haven't worked on it in x number of days, then she would take it and assign it.

The ITSS system enabled the creation of this new role, as an intermediary pointed out:

We couldn't have had this type of role before, because you need to have a real-time system so I can monitor the calls that come in as the day goes by and see which ones are critical, and which calls need to be transferred to others.

The creation of the intermediary role helped to defuse some of the tension felt by junior specialists to give up calls and assign work to others. In addition, the intermediary served as a buffer for senior specialists, so that they did not have monitor their junior partners all the time. A further benefit of the role was that it provided an opportunity for quality control over the information entered by junior specialists, and the opportunity to further reinforce norms around timely, complete, and accurate process documentation. As one intermediary noted:

What I do, for the six people that are taking incoming calls, I'm reviewing their comments. And if they're not documenting their calls well, it's reflecting not so well for them. The aim here is for them to keep us up to date on exactly what the status of every call is. So I make comments like, "Please update your call." Sometimes I put it in the incident history, or sometimes I just send them mail, through Notes and say "Please update me on these calls and let me know what the status is."

The shift in work organization represented by the creation of partnerships among the specialists and the establishment of an intermediary role to mediate between the front and back lines, allowed a more balanced distribution of work across less and more experienced specialists, and specialists with different areas of expertise (e.g., communications, mainframe systems). Prior to ITSS there was no mechanism for easily and dynamically transferring calls to others, so specialists worked on those calls they received personally. With ITSS, the groupware capabilities of the technology enabled a more dynamic distribution of work via three different coordination mechanisms: (i) junior specialists--recognizing that they could not handle particular calls--would pass these to their partners; (ii) senior specialists--inspecting the calls being worked on by their junior partners and recognizing where these junior specialists were overwhelmed, out of their depth, or on a wrong track--would offer to take responsibility for particular calls; and (iii) intermediaries--inspecting the calls being worked on by junior specialists and recognizing where the junior specialists were overwhelmed, out of their depth, or on a wrong track--would reassign calls to senior specialists with the appropriate expertise.

Emergent Change in Form of Collaboration

Before ITSS, collaboration took place through face-to-face interactions, whether one-on-one or in group meetings. While such interactions still occurred, the use of ITSS created an additional mechanism through which specialists could seek and give help -- electronically through the ITSS technology. Use of this new electronic mechanism for collaboration led to an interesting emergent change in the CSD: it shifted the form of collaboration from being primarily reactive to being primarily proactive. Because all specialists had access to the database of calls being worked on in the department, they browsed through each others' calls to see which ones they could provide help on. Rather than waiting to be asked if they had a solution to a particular problem (reactive collaboration), they actively sought problems that they had solutions for (proactive collaboration). For example,

Sometimes, if I see something that's open on somebody's calls which I've seen before, I may put a note in the incident and say "Hey, I think I've seen this before, this might be this and this." Everybody does that, everybody snoops on the calls and says, you know, "Try this," or whatever. And I find a couple of times that's really been helpful for me.

We all help each other out, you know. Like if I see Martha's gotten 15 calls and I've only gotten 3, I'm going to go in and I'm going to help her, whether she feels she needs it or not. I'm going to do some research for her. She does the same for me. And it's because, you know that one day you'll get killed, the next day you don't get killed. So, you're going to help whoever is getting hit the hardest that day.

This emergent change in the collaborative behavior of specialists was facilitated not only by the groupware technology at their disposal, but also by the particularly cooperative culture in the CSD, which was documented by Gallivan et al. (1993) and confirmed in this study. My observations indicated a high level of cooperation and camraderie. This is reflected in these specialists' comments:

Here I don't care who grabs credit for my work. You know, it's like we're all -- we're all the support department. We're not just individuals, you know. This support department does well because we're a team not because we're all individuals. I think it's the only way the support department can work successfully.

We'd be in trouble if we didn't appreciate help. I mean if we had attitudes like "You're interfering, you're trying to show me up." If you get attitudes like that in support then you're in trouble, because then you're not working as a team. And you have to work it as a team.

The complex nature of technical support work, evaluation criteria that stressed team work, and the communal atmosphere fostered by the CSD management further contributed to the cooperative environment, one where giving and seeking help were obvious and natural aspects of daily work.

An unanticipated consequence of this new form of electronic collaboration was that it shifted the mode of interaction from being primarily face to face to being primarily online. Because help seeking, help giving, and call assignment were now mediated through the ITSS technology, there was now a less compelling reason to meet in person, for example:

Notes has changed the dynamics in the group. That was something that I used to like. Because to me it was invaluable to talk to other people about things, because you can only think of so many things and it will exhaust your knowledge of the problem. And a fresh outlook on a call, and even just talking to somebody, getting some energy from them, sort of to spur you on to work on more, that you just don't get when someone says [in the incident], "Try this, try A, B and C." You don't get the detail that you would have if you had spoken to them.

The thing that seems to be lost as you become more attached and dependent on Notes is that you begin to lose some personal interaction with members of your group. I've noticed stretches of two to three days where I'm at my desk trying to resolve my calls as quickly as possible, and I haven't talked to anyone. ... It's like, if Lotus Notes has the answers why should I go talk to anyone?

Specialists and managers indicated that they had to consciously schedule some face-to-face interaction -- both in structured group meetings or informally over breakfast or lunch -- to offset this change.

II. Later Use of Groupware Technology within the CSD

After about a year of using the ITSS technology within the CSD, a more mature use evolved and this later period was characterized by the implementation of two planned organizational changes -- the establishment of global linkages with overseas support offices, and technological coordination with local departments. At the same time, an emergent change was enacted as well -- the opportunistic leveraging of the knowledge in the ITSS database through the creation of a training mechanism within the CSD and the establishment of knowledge dissemination channels to distribute technical knowledge throughout and beyond Zeta. Also associated with this later period of ITSS use were a number of unanticipated organizational outcomes.

Planned Change in Nature of Global Support

The nature of support provided by Zeta to its world-wide customer base changed when managers decided to roll the ITSS technology out to the three main overseas support offices -- U.K., Europe, and Australia -- during 1993 and early 1994. These ITSS installations were executed by the technologists who had implemented the ITSS technology in the U.S. office. With this technological change, all four support offices had access to each other's ITSS databases, thus giving all support specialists within Zeta a more extensive knowledge base to search on. One U.S. specialist explained the benefit of having information on foreign computing environments:

We get their databases, they get ours. They sometimes get problems over in the U.K. offices that are specific to configurations or whatever that are pretty much U.K. in nature. Yet we get a lot of calls within the United States from international divisions of companies who are dealing with a support desk at a foreign office. So we may have never had this configuration before, yet information that the U.K. office has provided us gives us a situation where we have the same information as if we had run into that.

In general, however, the availability of ITSS in overseas offices enabled overseas specialists to search on the U.S. ITSS knowledge base (which was much larger), and to facilitate the assignment of calls that they could not solve to the U.S. office (which had more specialists and more expertise). Overseas specialists had previously had no access to the U.S. database of incidents, and assigned calls to the U.S. via faxes and telephone calls. Most specialists preferred the electronic mode of interacting with overseas offices as it avoided the inconvenience of time differences inherent in synchronous telephone conversations. In addition, and perhaps more importantly, use of ITSS ensured that more information about transferred incidents was provided than would have been the case previously. Voice mail, for example, was too unstructured and typically lacked the detail required in ITSS incident forms. With ITSS, as one specialist noted, "you get the history of the entire incident, where you wouldn't with voice mail."

Occasionally, a breakdown in norms about global collaboration created some unanticipated problems. For example, when overseas specialists failed to assume their share of the work and responsibility for resolving incidents, the U.S. specialists' expectations about collaboration were violated, creating some frustration:

It doesn't seem to be working as well, I think, as they would like. ... A lot of times, it's almost as though we're getting the problem third hand from the client without any analysis or testing on the part of the other office. ... If we ask for details on a certain piece of it or ask them to clarify a certain point, it may be days, sometimes it's weeks before a response will come through and then it may come through with a "Is this resolved yet?" So there seems to be a great gap in communication. I would have expected the system to have brought it closer or narrowed that gap, but I don't think that it has.

I was just yelling about the overseas office to [my manager] -- how they just transfer the call and they don't bother to do any research on it. ... I would say there is a fair amount of [incidents] that if they bothered to search in the database they would have found their answer and it wouldn't have generated the call to us. It's just very frustrating because here you are working with somebody, you work for the same company, you're on the same team, ... but it's taking you three days to five days to close a call because you're not getting information from them.

While the norms and expectations of electronic work distribution and collaboration were well established in the U.S. office and the specialists applied these to interactions with their overseas colleagues, it was not apparent that specialists in the overseas offices shared these same norms and expectations. As a result, some global use of the groupware technology was not working as effectively as it could. In response, CSD managers had been in touch with their overseas counterparts to try and promote a more common and collaborative view of global support.

Planned Change in Inter-departmental Coordination Mechanisms

A further planned change around the ITSS technology enacted by the CSD during 1994 was the development of a number of bug tracking systems (one for each Zeta product) which were linked into the ITSS system. The designers of the ITSS application worked with members of the product development, product management, and QA departments to develop a prototype bug tracking system based on the ITSS template and existing bug tracking systems. A pilot test of one Notes-based bug tracking system was then run for about four months to evaluate the feasibility of the application and its linkages to the support department. Declared a success, a number of other bug tracking systems were developed and implemented throughout Zeta.

The implementation of these bug tracking systems with links to ITSS enabled specialists to directly transfer bugs they had found into the appropriate bug tracking systems, and to query the status of various bugs simply by accessing and searching the different bug tracking systems. This eased the task of reporting bugs, gave specialists more information on the status of bugs, and allowed them to change the priority of various bugs if customer calls indicated that such an escalation was needed. Specialists found this change in their coordination with other departments particularly useful:

The bug system provides a way to keep track of the work between the QA department finding the bug, the development fixing the bugs, and the status of the fix. But what's great is that we've actually hooked it in our incident system so that when a call comes into support and it turns out that it's a bug, we just click on a field and boom, it merges into the bug system, and so now we can keep track of it that way as well. Before that was really frustrating, we really went into a black hole. It was weeks and weeks before we even, you know, even made it to development and who knows when it got fixed. So, now I've got a reference of the bug number of how it's referenced in the bug database, and I can just go over there and search and see the status of what's been done with it.

The reactions of the other departments using the bug tracking systems and interacting with ITSS and the CSD were mixed. Product management and QA staff were enthusiastic because it facilitated coordination and consistency, eased the labor-intensive aspects of their jobs, provided more information, and enhanced their interaction with the support department. For example,

[Before] there was no sharing between the different groups. And the only way we saw it to have consistent recording between the groups and to be able to share information more easily is if everybody was on Notes. And I think that once we got there, we were really excited about it.

The interaction with support has been good because we can both sort of know what we're talking about without having to rehash the whole thing. The interaction is probably about the same as before, but we both get more out of it, I think, because we have a basis for what we're talking about.

The development department, however, was much less enthusiastic and this proved to be an unanticipated barrier to further expansion of inter-departmental coordination mechanisms. The developers' resistance to the bug applications appeared to be rooted in three factors. First, developers perceived the work of bug tracking and interacting with support as less central to their work. Bug fixing and interacting with support specialists were only part of developers' responsibilities, with the development of new products and new releases being their main concern. Hence, the technology that mediated less central tasks appeared less relevant to developers, in contrast to the CSD specialists whose use of ITSS was central to their work. As a developer observed:

It's probably a sense that [bug tracking] isn't the real work. It's a little bit outside. We're trying to produce a product. [Notes] is only a tool that helps us build a product, but it's not really sort of part of the product itself.

Second, developers worked under stringent time constraints to get the next release of their product out, and as a result had little time to learn to use the new bug tracking system. For example,

We resisted formal training as much as we could for lack of time. We were under some pretty severe deadline pressures. I really would have preferred not to have changed the bugs systems at all, just because I knew it was going to be extra time.

You might want to know more about OLE/2 or something like that, but you're probably not going to spend a lot of time learning about Notes, or Notes databases.

Third, developers interacted with Notes (and the applications that ran on it) less as users than as developers. With their technical understanding of database products, many were critical of the Notes product as a software system, finding shortcomings in its interface, database capabilities, and underlying design. Some of this reflects a "not invented here" reaction, an implicit contrast with the previous home-grown system the developers had used. For example,

I think trying to find bugs is a little bit more difficult than it was in our Omni-based system, just because we had a very good database underlining our bugs system and we could slice and dice the data as we chose. Especially when it comes to making an ad hoc query, you want to find out which bugs have this, that or the other characteristics. I mean, it's not something that you set up in advance. It's something that you'd just like to, all of a sudden on the spur of the moment would like to know which bug satisfies which characteristics. That's fairly difficult to do in Notes, but it's fairly easy to do in the Omni system.

There are no statistical capabilities, and I think that's a big minus for a bugs system. If you wanted to graph your bugs data, you know, to graph reported versus fixed bugs, that kind of thing, over a certain period of time. Or to graph severity of bugs reported over time, or something like that, or by programming group, or by individual programmer. That's the kind of thing that you'd like to be able to check on if you're a development manager. So, what ends up happening is that someone experimented with getting some of the Notes data back into Omni and then doing graphs or whatever on that. It seems like a roundabout way of getting to the statistics.

While further expansion of inter-departmental coordination between support and development seems stalled for now, developers did acknowledge that benefits had accrued from the process of developing the bug tracking systems and linking them to the ITSS system:

I think it made us all think a little more about the flow of the bug tracking system, and made us aware that we should be more responsible for the other groups involved. I think people are a lot more careful about documenting what they've done, perhaps it's easier to do that now. It's easier to go in and put in a comment when you're changing some little thing on a bug. Notes is good at keeping a record of comments. And it's nice to be able to sort through the history of the bug. We couldn't really do that before.

Emergent Change in Knowledge Utilization

Having established a large, rich, and growing knowledge base in the form of the ITSS database, the CSD began to use that knowledge to create benefits beyond those of specialists' problem solving. In particular, two opportunistic innovations were enacted by the technologists and specialists -- a training mechanism for new hires, and electronic channels for disseminating and publishing technical knowledge outside of the CSD. The move to disseminate ITSS knowledge also produced some unanticipated problems for the CSD: managing the time to produce quality knowledge, and controlling access to the knowledge.

Training Database

As the number of incidents in ITSS grew, some specialists realized the potential for using the knowledge in ITSS to serve as a mechanism for training newly-hired specialists. Such a mechanism supported training in the use of Notes and ITSS, provided information about the nature and content of the ITSS database, and through the completion of process documentation offered practice in the techniques of technical problem-solving. A few senior specialists extracted sample problems from the ITSS database and created a "training database" which new hires worked with to try and resolve problems. Their interaction with this training database was then monitored by a designated mentor. One senior specialist described this training process:

What we do is we go through a process with the trainee of giving them some initial training, getting them installed with Notes, getting them kind of oriented in Notes, and then we give them this database and the database has simulated calls in it, and basically, in trying to answer those calls, they use all the tools and resources we have available in support to solve them. Then they have to enter the call, or at least the things they've done on the call as if they were normally treating a call. And then, as the trainee is working through problems the trainer automatically gets mail of everything the trainee is doing. 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 sit down and actually sit with them and review things. It's sort of an on-line interactive thing, so it works pretty well.

The results of this new training mechanism were impressive, with new hires beginning to take customer calls within five or six weeks instead of the typical eight weeks. As a senior specialist noted: "We cut a couple of weeks off of the training period, which is pretty substantial. It gets people in there quick." Mentors and managers also used this training mechanism to influence the work habits and norms of new specialists:

I've tried, with the new people that I've got, to promote the fact that "This information is not only for you. Other people use this and if you put good information in there and everybody else does, everybody's job's a lot easier." So, you sort of try to get everybody's mind set that way.

While I am in a state of kind of watching this person and kind of mentoring them through the new hire training process, we can sort of mold their habits if you will, correctly and initially, and if we can do that then they're more valuable to the group later on.

The other thing that going through this demo database provides us is that, by the time they're done, they know how to use Notes mail and they know how to use Notes databases, how to search, how to enter comments, so they're very comfortable with Notes. Then when they get on the phone with the clients they don't have that reaction of, "Oh, I don't know what to do, and I missed half of what the client said because I was trying to find out which buttons to push."

The lessons it seems are not lost on the specialists:

When I got hired we went over the formalities of how we should present ourselves on the phone and in the Notes. And how to be professional as well, and that is why they gave us a demo database, the demo for us to play with, and so the reviewer, more like a mentor, would look at it and say, "Okay, this is the way you should say it. You have the right answer, but you're not presenting it well. Here is the correct way, use it as a reference."

Knowledge Dissemination

Another change that had emerged opportunistically from the CSD's use of ITSS was the establishment of channels for disseminating technical knowledge from the CSD to other Zeta departments (through a mechanism known as Source Zeta). In addition, there were plans to extend knowledge dissemination to clients (through a mechanism known as ITSS publishing). Source Zeta was a product-based set of six company-wide bulletin boards within electronic mail (which everyone in the firm has access to). Different departments (e.g., development, product management) used these bulletin boards to announce information or distribute knowledge about particular products. The CSD chose this mechanism to distribute knowledge from their ITSS database about the products they supported. The mechanism was described by one senior specialist:

We also use Notes for tracking our Tech Support notes. The new product that just came out for our group, ADS, the documentation is still catching up to the product. So in the meantime, if we run into a problem, over and over again, we will write it up in a Tech note, and distribute it via Source Zeta. But we decided that rather than just throwing things out there and having them be unfinished, we would create a small internal work group to review the Tech notes before they got disseminated. So somebody creates a Tech note and it gets into the Review database. And then five or six people in the group all review it and stick their comments on as added-on documents. Then the author incorporates those comments and rewrites the note as necessary. And then when everybody is happy with it, it then gets moved to the cc:Mail bulletin board.

The initiative for writing Tech notes and submitting these to Source Zeta lay with the specialists. While specialists were encouraged to write and submit such notes for review, there were no requirements to do so. For specialists, the incentives appeared two-fold: to help the field service representatives, and to gain some visibility within the company:

The incentive is more or less trying to save somebody else time. You document something that you spent a lot of time on so that somebody else doesn't have to spend the time later on.

I think [specialists] know that the fact that they've made a submission is kind of a demonstration of providing value to rest of the group and the company as a whole. So it is a very visible note of productivity, regardless of the review I think. ... The primary author's name is associated with it, and it's distributed through a grouping that indicates it came from support. So I suppose it has both personal and group recognition.

While all specialists felt the technical knowledge dissemination was a good idea, there were some unanticipated problems with the amount of time available to produce high quality and sanitized knowledge for dissemination. There was also a concern that people would not take the necessary time to produce a quality product and instead use the review mechanism to gain visibility at the expense of others. For example,

It's kind of hard because it's a lot of time. It's not even just writing it, because I actually review it. I'm on the review committee and that's where a lot of time is as I've got to review every document. ... But it's just a matter of finding the time and I mean, certainly the calls are going to have precedence over doing this. So it's a matter of finding a lull in your work that you're able to do it.

I suppose the review process also allows an author to be lazy, to some extent. They can put down whatever information they want to discuss, even in a kind of a rough framework that they know may have some inaccuracies and throw it out there, and save themselves some work with some details that they may not have been sure of which is why they didn't put them in there. I'm sure other people would fill it in. So they can call it their own document if they really knew how to use the review process.

A second channel of knowledge dissemination included customers. This was the idea of ITSS publishing, where the CSD hoped to provide extracts of ITSS and the Tech notes databases and make these available to customers, either on a per-request basis via fax or e-mail, or through a browsing mechanism such as may be established through the Internet and the World Wide Web. Some of these plans were described as follows:

ITSS Publishing is a concept basically where we plan to take incidents from ITSS ... common incidents or very difficult incidents, clean them up extensively, and come up with something that we can fax or electronically send to a client that would answer their problem.

I see ITSS Publishing as being like a great database to have with like Internet access or something like that where a client could just -- without us even being involved -- get to this database and look up the stuff that they want to look up.

The delay in implementing this second knowledge dissemination plan was due to time constraints. As a senior specialist noted, the lack of resources to produce high quality, sanitized knowledge for consumption by customers, was inhibiting:

The reason that it hasn't really gone anywhere is time commitment again. Who is going to do the clean up? Who has got time? Everybody is pretty stressed out as far as time, especially in support. [ITSS Publishing] is going to be the kind of thing that is going to take a lot of editing.

A significant unanticipated consequence of the CSD's various knowledge dissemination innovations, was the problem of access control. The consequence of having a valuable knowledge base that one leverages in various ways, is that more and more people become aware of it and want access to it. Because of the detailed process documentation of incidents in the ITSS database, CSD managers and specialists were particularly concerned about giving broad access to the ITSS database. In particular, they were concerned about inappropriate assignment of blame and the use of information out of context. Managers explained their concerns:

There's some reluctance to give full access to ITSS. I mean this is people's work in progress. Sometimes the stuff they do isn't correct. I don't want someone jumping down someone's throat because maybe they didn't give the right answer right out of the starting gate. And there is some worry that that would happen. And if they had access to ITSS, they could see who had calls open. And I don't want somebody calling and saying, "Hey, why haven't you answered this call yet?"... There is a vulnerability and you want to protect the people that work in support. They're doing a tremendous job under an unbelievable amount of stress. So, you don't want them getting attacked from other quarters.

I have had situations where other departments want it as their knowledge base to solve their own problems, and I don't like to give it to people for that reason, unless they do support. And the reason is because this isn't really a knowledge base; this is a history of all the problems we take in. And just because one incident might tell you to do something one way doesn't necessarily mean that's going to solve that particular problem. And as a support professional you know that. ... But somebody in the marketing group is not going to understand it, or the sales group, especially the sales group. Because they will read and they'll take it as gospel, and it's not. It's just to give you some hints to how to solve a problem.

Interestingly, concern over fingerpointing was also apparent in the other departments using Notes, product development and development. One manager reported:

I think that is one of the big problems with Notes is that because people do have access to each other's information and that information is used to finger point. ... The current product that I am working on, there is a lot of finger pointing going on and it is a shame because I have had a lot of experience in reading bug systems and you can get any report that you want out of a bug system to support whatever it is you want to say about a particular person or group and that person can turn around and say something different out of the same data. So it all depends on how you interpret the data. ... It's interesting because, before, the big question was, "Alright, can we ship the product yet? If we can't what are the bugs left?" Now the question is, "Is the QA department working quickly enough? Is the development department working quickly enough?"

In response, CSD managers developed various policies and mechanisms for restricting access to the ITSS knowledge base. For example, they allow restricted access to individuals on the basis of their personal trustworthiness:

We have allowed some access on the basis of whether we would trust them, where we know that the information would not be used against us. ... If other people were to move into, say one particular person's job, we'd take the access away. I don't know how long we can operate like that, but right now we're the only people with the tool and we pretty much say who uses it.

They also offered alternative mechanisms for obtaining ITSS data, which did not require direct access to the Notes database. A manager provided a specific example of such an alternative:

The western region heard about this great database that we had. And they were particularly interested in finding out what their clients call us about. ... So, as a way to pacify them I got a copy of a client list from them, and I would on a weekly basis go in and just highlight the week's activity in a view of those clients. And it got down to where it was taking me about 20 minutes a week. And I would just highlight it and get it off into a file. I was faxing it to them. And then they started saying, "Well, we want access to your system, we can't read the faxes." So, I exported it into a write-formatted file and started cc:Mailing it, so they didn't have that complaint.

The CSD had thus developed a set of sensibilities about data access which reflected their concerns about whether their data might be used against them, or used inappropriately as guaranteed solutions rather than the "working knowledge" which it was. These sensibilities are expressed in the overview to the ITSS users' guide, which includes the following cautions:

ITSS is, for the most part, the backbone of Technical Support. It has become so valuable that other groups are requesting access to it for everything from account management to client addresses. Reasonable requests for access to ITSS information will be considered, but let the users beware!!! ITSS is intended as a call tracking application, not a technical notes database or a Client tracking database. The information in ITSS is provided "as is", with no guarantees. It represents the best efforts of Technical Support Specialists working in a very complex support environment under serious time constraints.

[highlighted in red] Any use of ITSS that negatively impacts Support will not be allowed, and all offenders will have their access revoked immediately.

III. Assessing the Changes around Groupware Technology

While no formal measures of productivity were kept by the CSD, both managers and specialists reported that use of ITSS had improved their personal and the department's effectiveness. Other benefits noted by the specialists included the centralization of relevant information, the ease of accessibility, improved ability to handle increased volume of calls, and an enhanced image of the support department now held in the company. For example, specialists observed:

The more we add to it the more centralized our information is. When I first started, [information was] kind of all over the place, and you had to go in and out of several things. We're moving everything into Notes, so now you can pretty much stay in one desktop and just run through and find what you need. Also, the commands to get what you're looking for are the same regardless of what information you're looking for. The search is the same, opening the database, that type of thing. It's not like three separate applications that all have their own interface that you kind of have to muddle through and remember which key strokes do what. So, it's a lot easier coming up-to-speed.

We've definitely noticed improvements in what's available, and access to it just makes the job that much more easy. And in our situation with all the new stuff we've got coming out that's real important, because if you can shrink the work load and shrink the research time, then you can handle more volume. So it kind of keeps our work load somewhat balanced. If we weren't adding all these things to Notes then our work load would be overwhelming and we wouldn't be able to do what we're doing. As we add things to Notes, it kind of allows us one or two more calls a day that we can handle.

Because we have a lot more information, I think it makes us look more organized. ... And I think that it has had a great impact on support in terms of our image.

Managers noted that their expectations for the technology had not only been met, but also exceeded. They believed the ITSS application had had a positive impact within the CSD department, enabling for example, improvements in productivity, accountability, and decision making:

Our call volume has increased significantly. A year ago we had about 500 to 600 calls a month. I think this month we're going to hit 1200. So, we've almost doubled our call volume in a year time. We would not be able to handle this volume of calls without ITSS. It amazes me that we're handling twice as many calls as we were a year ago with not twice as many people. ... It certainly has been a stressful time for us; but I think if we didn't have ITSS it would have been unbearable.

I think we're closing calls faster, though I don't have any real statistics to prove that. ... The way we look at things is number of days that something's remained open. And since we went with Notes, we've closed 50 percent of the calls in one day. Now, the problem is I don't know what it was prior to Notes, so I don't know if this is an improvement or not.

I think in terms of Support, the expectations have been met or exceeded, and I would chalk that up to the technology worked as well as it said it would, and the fact that the team -- both the team that was developing the application and the team that was receiving it -- had a very positive attitude from the start ... It has made a tremendous difference.

For me, it gives me a window into the day-to-day operation type information. ... We can now give realistic data about the nature of the problems, how many we're having, just a lot more analysis. So not only did we, at one time, declare it a success, but it's just sort of reinforced on a daily basis. By now there's no justification, it's moved into assumption mode.

Managers indicated that the technology had also facilitated the development of work strategies, mechanisms, and policies not initially anticipated. Equally important, however, was their and the specialists' willingness to continue making organizational changes around the use of groupware. Such continued changes had allowed them to learn and build on their use of the technology as their understanding and practice of technology-mediated customer support evolved over time.

This paper reports on a study that investigated the ongoing use of groupware in an organization that had previously successfully implemented the Notes groupware technology in one department. The findings offer two kinds of lessons: one having to do with the specific kinds of organizational changes facilitated by the use of groupware technology over time, and the other with the process of managing change around groupware technologies.

Organizational Changes around Groupware

The findings suggest that over time the groupware technology in the department was used to enact a number of significant changes in the nature and distribution of work, the form of collaboration and interaction, the coordination among units, and the utilization of the knowledge accumulating in the groupware repository. These changes had not all been anticipated or planned by the department in question, rather some had emerged as the department evolved in its understanding and experience not only of the technology, but of how the technology could be utilized and adapted to modify and improve the department's work structures, processes, and policies.

With respect to the work itself, the technology was deliberately designed to produce documentation of the process. This changed the nature of support work from primarily problem solving to both problem solving and documentation. This groupware-based documentation offered managers a full audit trail of the work accomplished on all calls taken within the department, increasing their accountability and ability to dynamically balance work load, redesign schedules, and justify headcount increases. Interestingly, the documentation also enabled other changes. By providing a shared window into the nature and status of all the work needing attention in the department, the technology facilitated spontaneous forms of help-giving that had not been possible previously. Such a shared window allowed, for the first time, a truly group view of the work being performed by all the specialists, and thus the possibility of proactive collaboration. Even though work continued to be executed individually, the shared window facilitated by the groupware technology had begun to blur the distinctions of individual and group work in important ways. When customer problems (calls) were individually documented on private scratch pads, then researched and resolved individually (with occasional face to face consultation of others), the notion of individual workspace, responsibility, and ownership are clearly defined. When customer problems (calls) are recorded in a public electronic space that is accessible by the rest of the group, then researched and resolved by any of the group members, the work is no longer sensibly understood as individual. It has become shared, the joint responsibility of the group.

To take advantage of this new shared window on support work, managers in the department made a number of structural adjustments. They established the notion of partnerships, arranging for junior members of the group to be teamed with more senior members so as to allow a more balanced distribution of work that took into account experience and expertise. The technology allowed senior members to electronically monitor and mentor their junior partners, while also allowing junior members to reassign work or seek help from senior partners if they felt overwhelmed. Despite the changes in structure and the availability of technological means to transfer work, many individuals experienced difficulties handing calls off to their partners. Unexpected social issues emerged as salient, such as the delicate negotiation of assigning work to more senior colleagues, the need to feel personal accomplishment, and the opportunity for learning that was somewhat foregone when work was transferred. Recognizing these issues, the mangers instituted further structural change by creating an intermediary role to ensure that junior members transferred calls they could not handle to senior partners, and to provide senior members with some breathing space in their monitoring of junior partners. Because the intermediaries were senior specialists, they served as another skilled resource that could inspect and resolve the calls shared by the group.

Process documentation also enabled other changes in the customer support workplace. It provided the ability to leverage the process knowledge in the database, facilitating the creation of a training facility and a mechanism for disseminating sanitized versions of the knowledge to the rest of the organization and later to customers. It further created a technology platform from which a number of organizational innovations were developed. One such innovation had been the integration of the department with overseas support offices and related departments more locally. While the protocols for coordinating across these organizational boundaries were still evolving as the individuals learned to interact electronically, the possibility for closer integration of work processes was now possible, at least technologically. The organizational motivation to do so might require some time to incubate.

As work is now documented and shared, it was now also visible. And with visibility came scrutiny and vulnerability. The shared work of the department was routinely inspected, utilized, and monitored by all members of the department. Norms for intervening in others' calls had to be developed, but once established people became accustomed to the shared electronic space being observed and worked on by many others. Managerial monitoring of work performance raised some initial concerns, and while a few lingered, most members had come to understand that this was the manner of the new electronic workplace. If they were to work electronically, then such work would have to be evaluated. That managers used the groupware information to evaluate and review work reinforced how central use of the technology had become to the execution of work. Not using this information would have been inconsistent with the push towards greater use of the technology to mediate support work. The cooperative culture along with the respectful, open, and collegial atmosphere promoted within the department helped substantially in this acceptance. A more hierarchic, competitive, controlling environment would likely raise serious concerns about the use of groupware technology to monitor and evaluate work.

Beyond the immediate department in which the work was being done, the value of the knowledge being generated attracted the attention of others who desired access. The emergence of appropriate policies around access control took time, but were grounded in an understanding of the importance of trust and information context. The former issue refers to the need to ensure that those with access will not use it to blame, punish, or construct convenient scapegoats. The latter issue refers to the need to ensure that those with access understand the context within which the contents were generated. As a working database, the knowledge pertained to specific problems at particular points in time. It was not generic knowledge, universally applicable, and neither was its veracity guaranteed. Given the tendency to equate technology with progress, it is particularly easy to slip into the mindset that data from a computer must somehow be "correct." The policies around access control that have emerged in this department reflect a political and contextual understanding of the nature of data in a database, one often missing in other contexts.

Inevitably, the more technologically mediated the work, and the more valuable and effective that mediation, the more dependent the work and the worker become on the technology. This dependence was apparent on two fronts: a physical dependence on the availability of the hardware, network, software, and data quality, and a psychological dependence on the knowledge contained within the technology. The former is manageable with various backup mechanisms, tests, and review procedures. The latter is more problematic to manage because it represent a state of mind. It is particularly problematic for members of the department who have never known support work without the use of groupware technology. For them, it is almost as if the work is inconceivable any other way. Hence the loss of cognitive security when the technology becomes unavailable. Such users have no alternative mental model to substitute that would facilitate their work. Providing training that specifically offers such alternative models for working with and without the technology might offer some defense against this form of dependence.

Process of Managing Change around Groupware

In this paper, I have described the set of intended and opportunistic changes enacted by one organization experimenting, learning, and evolving with the new class of technologies known as groupware. In addition to learning about the specific organizational changes enacted by Zeta in its CSD, the effectiveness of its use of groupware suggests a possibly generalizable strategy for implementing and using new groupware technology. Such a strategy proposes a process of change management that first enacts some initial planned organizational changes, and then later builds on these to enact emergent organizational changes in response to the opportunities and new conditions occasioned by the planned changes. In turn, these emergent changes, together with the prior planned changes, provide a technological and organizational base from which further planned and emergent changes may be enacted. This ongoing series of planned and emergent changes was not a predefined program of change charted by Zeta management ahead of time. Rather, it evolved out of practical experience using groupware technology to solve a particular organizational problem, learning from ongoing use, responding to unexpected developments, and allowing further innovation and adaptation of both the technology and the organization. These findings suggest that where an organization is open to the opportunities offered by a new technological platform and willing to make ongoing organizational adaptations, much change can be accomplished.

Because groupware technologies are relatively new, typically open-ended, and largely adaptable, the change process followed by Zeta's CSD may be a particularly useful way of implementing organizational changes around groupware. In contrast, for example, to transaction processing systems (such as order entry or payroll) or functionally-specialized tools (such as word processing or tax preparation software) groupware provides a bundle of technological capabilities that may be understood, utilized, customized, and appropriated in a variety of different ways, many of which are highly context-specific and many of which are yet to be invented by users within those contexts. The implementation of a fixed set of predefined organizational changes can only begin the process of effectively utilizing groupware technology. Organizations need the experience of trying to use groupware in particular ways and particular contexts to understand how it may be useful in practice. Thus a process of change that exploits ongoing adaptation and learning provides an opportunity to generate understanding of the kinds of organizational changes that are possible with groupware, and feasible within a particular context and time period.

Clearly, more empirical investigation of other organizations adopting such a change process are needed to validate and qualify the process outlined here. However, the effectiveness of the change process within Zeta suggests the value of a strategy of implementing and using groupware technology that iterates between planned and emergent organizational changes over time. Allowing organizations to experiment with, discover, learn from, evolve, and continue to evolve organizational adaptations and innovations around a new technology over time may thus be a particularly appropriate process of implementing organizational change around groupware.

Bullen, C.V. and Bennett, J.L. 1990. "Groupware in Practice: An Interpretation of Work Experience," in Proceedings of the Conference on Computer Supported Cooperative Work (October, Los Angeles, CA), ACM/SIGCHI, NY: 291-302.

Eisenhardt, K.M. 1989. "Building Theories from Case Study Research," Academy of Management Review, 14: 532-550.

Gallivan, M., Goh, C.H., Hitt, L.M. and Wyner, G. 1993. "Incident Tracking at InfoCorp: Case Study of a Pilot Notes Implementation," Working Paper #3590-93, Center for Coordination Science, MIT Sloan School: Cambridge, MA.

Grudin, J. 1988. "Why CSCW Applications Fail: Problems in the Design and Evaluation of Organizational Interfaces," in Proceedings of the Conference on Computer Supported Cooperative Work, (September, Portland, OR), ACM/SIGCHI & SIGOIS, NY: 85-93.

Grudin, J. 1994. "Groupware and Social Dynamics: Eight Challenges for Developers," Communications of the ACM, 37: 93-105.

Horton, M.S. 1994. "Contrasting Strategies for Groupware Implementation: Early Outcomes and Challenges," Presentation at The Lotus Notes Workshop (February, University of Michigan, Ann Arbor, MI).

Kling, R. 1991. "Cooperation, Coordination, and Control in Computer-Supported Cooperative Work," Communications of the ACM, 34, 12: 83-88.

Korpela, E. 1994. "Path to Notes: A Networked Company choosing its Information Systems Solution," in Proceedings of the IFIP Conference on "Transforming Organizations with Information Technology" (August, Ann Arbor, MI), North-Holland, Amsterdam: 219-242..

Markus, M.L. 1987. "Towards a "Critical Mass" Theory of Interactive Media: Universal Access, Interdependence and Diffusion," Communication Research, 14: 491-511.

Markus, M.L. and Connolly, T. 1990. "Why CSCW Applications Fail: Problems in the Adoption of Interdependent Work Tools," in Proceedings of the Conference on Computer Supported Cooperative Work (October, Los Angeles, CA), ACM/SIGCHI & SIGOIS, NY: 371-380.

Miles, M.B. and Huberman, A.M. 1984. Qualitative Data Analysis: A Sourcebook of New Methods. Sage Publications, Newbury Park, CA.

Orlikowski, W.J. 1992. "Learning from Notes: Organizational Issues in Groupware Implementation," in Proceedings of the Conference on Computer Supported Cooperative Work (November, Toronto, Canada), ACM/SIGCHI & SIGOIS, NY: 362-369.

Perin, C. 1991. "Electronic Social Fields in Bureaucracies," Communications of the ACM, 34, 12: 75-82.

Pettigrew, A.M. 1990. "Longitudinal Field Research on Change: Theory and Practice," Organization Science, 1, 3: 267-292.

Rogers, Y. 1994. "Exploring Obstacles: Integrating CSCW in Evolving Organizations," in Proceedings of the Conference on Computer Supported Cooperative Work (October, Chapel Hill, NC), ACM/SIGCHI & SIGOIS, NY: 67-77.

Strauss, A. and Corbin, J. 1990. Basics of Qualitative Research: Grounded Theory, Procedures, and Techniques, Newbury Park, CA: Sage Publications.

Yin, R.K. 1989. Case Study Research: Design and Methods (rev. ed.), Beverly Hills, CA: Sage.

Footnotes

[2] Groucho is the name of one of the servers used by the CSD. The others are Chico, Moe, and Curley.