Here's what we have on this site

Home
News
Online Publications
Publications List
JD's Background
Links
Feedback to JD
Search this site

Groupware Implementation: Reinvention in the Sociotechnical Frame

Proceedings of the 1996 Conference on Computer-Supported Cooperative Work. New York: Association for Computing Machinery, 1996

Slightly revised version to appear in Information Communication & Society (iCS), 1998, in press.

Tora K. Bikson

The RAND Corporation

1700 Main St.

Santa Monica CA 90407 USA

JD Eveland

California School of Professional Psychology

1000 S. Fremont Ave.

Alhambra CA 91803 USA

ABSTRACT

Sociotechnical systems theory suggests several themes about implementation, including continuous mutual adaptation of tool and context, task emphasis, the priority of process, and changes in evaluative criteria over time. The effectiveness of these ideas is illustrated in the experience of the World Bank in its implementation of a group decision support system, GroupSystems.

Keywords

Groupware, innovation, implementation, technological change, sociotechnical design

INTRODUCTION

Instances of implementation of CSCW tools have been studied from many different perspectives in many different contexts. The Proceedings of each of the six CSCW Conferences to date are full of stories of implementation experiences -- effective, ineffective, and all six degrees of separation in between. We learn from stories, as we generalize to our own experiences.

The story that we set forth in this brief case is, however, not just a story. It also particularly illustrates the working out in practice of propositions derived from socio-technical design and implementation theory -- and provides a cautionary note about thinking that groupware is immune to organizational behavior. In contrast, implementation works all the better if we take advantage of what we have learned about how organizations shape and evolve new tools and the systems in which they are embedded.

Perhaps the most helpful direction is provided by sociotechnical systems theory. Originally developed in the context of manufacturing technologies in industrial organizations, it has afforded a robust foundation for understanding relationships between new information technologies and service sector organizations. Extensive reviews of the long history of this approach are available [16,17]. Briefly, sociotechnical systems theory treats an organization as a complex whole comprising two interdependent subsystems: a social system involving work groups, jobs, task interdependencies, work flow, and the like; and a technical system including, for example, electronic hardware, software, networks, applications, tools, and so on.

Each system is open, susceptible to effects of events in the environment. The technical system is influenced when new products or processes become available that extend or alter what it can do for the organization; the social system is affected by the entry of new members or new practices initiated by extant members as well as by downsizing, outsourcing and other changes in organizational design. The two are reciprocally influential, so that change in one of these systems inherently leads to change in the other. When new technologies are introduced, users may have to acquire new skills or learn new work procedures; pressures for more collaboration or workflow changes resulting from process redesign may require redeployment of available technologies as well as acquisition of new ones. Successful innovation, from this perspective, turns on mutually adaptive social and technical system changes.

This theory suggests several propositions that have been corroborated in previous research on information and communication technologies in information intensive work:

bulletThe changes in both the social and technical systems cannot be predicted in advance, except in the most general terms
bulletSince social and technical systems are reciprocally influential, questions about what works cannot be answered for each independently; instead, successful innovation is a function of their joint optimization in a given context.
bulletImplementation processes, the series of decisions and actions by means of which a new technology is incorporated in the day-to-day work of an organization, will have as strong an influence on outcomes as properties of the technology per se or the prior work context -- and probably stronger.
bulletThe consequences of technological innovation evolve over time, given reciprocal effects and mutual adaptations between social and technical systems; short- and long-term organizational outcomes are likely to differ substantially.

The case reported here suggests how, with appropriate attention to sociotechnical dynamics, a groupware application can come to have major organizational payoffs. The key enabling factors are attention to process and embracing the idea of continuous implementation through interaction between the tools and the social arrangements that embed them at the point of the task interface.

THE CONTEXT

The World Bank is an organization that lives at the cusp of the world's most troubling problems. The Bank's charter is to alleviate poverty by providing economic, technical and financial assistance to the poorer countries of the world. It pursues this mission chiefly by lending money for development, with loans averaging approximately US$20 billion per year. Member countries donate part of the Bank's operating funds and underwrite its bonds; the Bank then borrows the major part of what it loans on the open market. Viable borrowing and lending, in turn, depend on acquiring and applying knowledge about the nature of development in ever-changing country contexts over time [15]. The Bank's primary business processes thus rely on core competencies involving global finance and development.

The Bank has a multinational workforce of approximately 10,000 headquartered in Washington DC/USA. It also has about 70 field offices, and headquarters staff typically spend up to 120 days a year traveling to the countries with which they work [15]. The workforce is organized around four kinds of functions: operations, finance, research and support. Information technology at the Bank includes a centrally-managed infrastructure and institution-wide tools, with decentralized applications managed by particular organizational units to meet task-specific objectives.

The culture of The World Bank is similar to that of other knowledge intensive organizations. Its highly educated professional and managerial staff outnumbers support staff by about two to one. These knowledge workers are skeptical, tough and sophisticated; work styles tend to highly individualistic rather than collaborative [15]. On the other hand, the considerable complexity of the Bank's business processes requires complex interactions. For example, most managers and professionals are members of diverse groups that comprise disciplinary, sectoral and country expertise; they meet periodically to review progress and make decisions about the Bank's strategy in a given region or country. Staff members themselves come from 150 different countries [13], so that organizational politics can at times mingle inextricably with world politics.

The Bank spends millions of dollars a week -- literally -- on meetings. Same-time same-place meetings remain the formal structure for collaboration in most organizations whose tasks demand pooled knowledge and experience or agreement and coordination among multiple stakeholders. Nonetheless, meetings had become the subject of constant complaint. They took too much time away from "real" work, with little to show in return; meeting outcomes were often unclear, follow-up actions were often unspecified, all too often, another meeting was needed to handle unfinished business. Subsequent meetings, however, were rarely able to build on a shared accurate record of prior progress. It was in this environment that a search for technological solutions to managerial problems led to the implementation described here.

This case is about what happened at the Bank when a new piece was added to the sociotechnical equation: a group decision support system (GDSS). GDSS's are one of two general classifications of "groupware", the other being group communications systems such as Lotus Notes[14]. GDSS's usually operate in an electronic meeting room that provides networked interactive computer support to same-time same-place participants [11] and require professional facilitators.

The software installed at the Bank, Ventana Corporation's GroupSystems V, offers facilities for anonymous concurrent brainstorming, group structuring of meeting comments (e.g., by outlining), assessment of decision alternatives (e.g., by ranking or voting) and real-time feedback (e.g., by visual displays of graphs, charts, counts, ranks and the like, as well as text) [18]. The software runs on networked workstations; it also uses an operator's workstation, CPU storage, and audiovisual equipment (e.g., large shared screens, printers) to which system outputs may be directed by the operator ("technographer"). At the Bank, a dedicated room to house such an electronic meeting support system, including 14 LAN-linked workstations, was opened for use in May 1993 as a joint venture of two support units, the centralized information technology and facilities department (ITF) and the organizational development department (ORG).

RESEARCH PROCEDURES

This study of GroupSystems implementation is part of series of studies of electronic technologies at the Bank and other international organizations [2]. Information was gathered in semi-structured interviews and supplemented by archival material (e.g., memoranda, newsletter items, internal evaluation data, reports). Interviews were organized around a common protocol, guided by the conceptual framework reviewed above, that addressed antecedents and consequences of the introduction of groupware as well as properties of the technology and the implementation process itself.

Key informants associated with the social and technical sides of groupware decision making and implementation at the Bank were interviewed, as were representatives of GroupSystems user units. They included the heads of the two departments (ORG and ITF) responsible for major decisions from initial planning to full scale operation of the electronic meeting room; the two co-leaders of the design/implementation team (one from each department); facilitators who guide user groups' interactions toward a meeting's objectives; technographers who oversee the operation of GroupSystems software and provide real-time help; the current GroupSystems coordinator; and members of both operations and support units that have made use of the new technology to conduct at least one meeting. Data were gathered in Spring 1995.

Information obtained from interviews was analyzed qualitatively, following the pattern-matching procedure described by Yin [20] and successfully employed in other organizational case studies of the implementation of new information technologies [6,7]. Interview notes were organized across respondents according to key components of the interview protocol (where components were based on sociotechnical systems theory as it applies to the case at hand); archival material was included when relevant. The information base was then examined to determine what common themes would emerge for each component and whether different role incumbents would systematically differ in their experiences or evaluations of GroupSystems technology.

GROUPWARE AND THE IMPLEMENTATION PROCESS

Like most technology implementations, the incorporation of GroupSystems into the Bank's repertoire took place in a series of small steps. None could be considered as uniquely determining the course of events but collectively they added up to what seems in retrospect (although not necessarily so at the time) a well-organized and rational process. The chronology of events ran like this:

1. 1989: attending a conference on same-place same-time collaboration support, the ORG department head first learns about GroupSystems technology and thinks it might help make the Bank's meetings more effective.

2. 1990: he pursues this idea by (a) designating an ORG professional to do feasibility research and (b) trying out the technology at a university not far away as part of a real country strategy exercise, using a nearby site and facilitator.

3. 1991: the ORG head arranges more trial groupware uses (a) at local IBM facilities, with an IBM facilitator and (b) at the University of Arizona, where the technology originated.

4. 1992: the ORG head approaches ITF with a proposal to implement GroupSystems technology as a joint venture of the two departments. ITF concurs and a group is formed to steer the venture; co-leaders for a design and implementation team are chosen from ITF and ORG.

5. Throughout 1992: trial use in borrowed facilities continues; visits are made to other organizational users to see how similar technologies perform in different contexts and to learn from their experiences; participation in user group conferences is encouraged.

6. End of 1992: ORG and ITF decide to (a) acquire the software, (b) construct and configure an electronic meeting room and (c) recruit an initial group of Bank facilitators and technographers committed to hands-on learning about how GroupSystems technology works; serving on the design/implementation team, they become the human infrastructure for the Bank's groupware.

7. March 1993: when the facility and humanware are functional, ORG requests and receives top-level funding support for a 9-month pilot operation of the technology before offering it for general use throughout the Bank.

8. May 1993: the electronic meeting room is officially "founded" and the pilot period begins; although pilot users are real groups within the Bank, the sessions are candidly acknowledged to be learning experiences. 102 sessions are conducted before the pilot ends in December 1993, with the IT newsletter heralding "a new way to 'do' meetings in the Bank".

9. January 1994: GroupSystems technology is offered for Bank-wide use; a participant evaluation tool is activated.

10. June 1994: a formal coordinator for GroupSystems is named to manage the operation of electronic meeting facilities for the Bank.

Several features of the implementation process are worth comment. First, there is the high-level champion. Literature on technological innovation in organizations consistently cites the commitment of a high-level champion as one of the strongest success predictors [3,6,12]. What is unusual here is that the high-level initiative came from the organizational behavior department (ORG) rather than from an information systems department. Probably as a result, according to several implementation team members, GroupSystems technology was viewed from the outset as an "adjunct of group process," a "valuable set of tools to add to the toolkit" for organizational development. This emphasis contrasts sharply with standard practice, where the technology itself is typically the focus [4]. Even at the Bank, "most often, the technical issues are given far more substance" [15].

Second, the case shows an unusual degree of sociotechnical balance. Once the head of ORG had gained enough background knowledge of the technology to be convinced it was worth serious exploration, he enlisted the head of the information technology and facilities (ITF) department as a partner in what the latter subsequently called "a joint venture to offer groupware capabilities within the Bank." The two units collaborated closely throughout the implementation effort. In particular, co-leaders were chosen for the design/implementation team, one from ORG and one from ITF; other members of the team reflected these two orientations as well. The electronic meeting facility was housed within ITF but managed by ORG; ITF provided funds for construction, hardware and software, while ORG secured the funds for training and staffing. Although the importance of real cooperation between social and technical experts in implementation processes has been stressed in the literature, it rarely happens [6]; as far as anyone knows, this was the first joint ORG-ITF venture at the Bank.

Another noteworthy aspect is the real user design/implementation team. Relying on an appropriately constituted team to make most day-to-day design and implementation decisions once senior management has signed off on its charter is another strong success prescription from innovation research. If it is most often honored in the breach, that is probably because it is often time-consuming and costly, and may even involve tensions, disputes or role conflicts that are difficult to resolve [12]. Here, the team comprised about 12 core members (including the co-leaders) who were expected to become the Bank's first facilitators and technographers. More peripheral "steering committee" members, including country operations and support unit representatives like those expected to become future groupware clients, provided oversight, advice and, eventually, trial users.

Core members of the implementation team were hand picked for their interest and ability. Future facilitators all had human resource backgrounds and were "carefully chosen," said the ORG head, for their "exceptional facilitation skills" as well as for their receptivity to new technology. Since these personnel professionals were physically decentralized with offices located in the specific departments they served, they could be drawn from all over the Bank. Potential technographers, on the other hand, were all located in ITF; they were selected for their technical skill along with an interest in technological innovation. However, no one was "told" to work on the implementation team; team members were invited, not assigned. In this way, said one team member, "it was a volunteer effort." Further, the same individual noted, this meant there was "no formal administration.... We worked like a self-managed group." Said another member, "We became a community, did a lot of discussion of our roles.... We built knowledge as a team." A third underscored that, as members of the group, "we had a heavy dedication to self learning."

Considerable attention was given to learning and training throughout the implementation. Initial learning involved both reviewing research and trade journals and conducting sessions using borrowed facilities to get an experiential take on what the literature was reporting. Next steps included visits and discussions with other organizations that had already incorporated meeting support groupware into their business processes, to find out how the system was administered in other contexts, what their staffing requirements had been, which specific software vendor provided their systems, what the technical performance record to date had been, and what outcomes had resulted.

After the acquisition decision, these efforts were supplemented by more intensive training activities intended to yield competent in-house GroupSystems staff. As the head of the ORG department put it in a memo:

The next step ... is to run a pilot over a period of nine months. A central feature of the pilot is the need to train a sufficient number of facilitators... Without them, the facility cannot be used productively...Inevitably, this costs money. Including the costs of [a high-level] staff member, a total of just over $500,000. I realize that this is a hefty sum but I think it has to be seen in light of potential benefits.

This request illustrates the need to put the cost of such implementation activities as training and pilots in budgets for new technologies. The Bank's implementation team members unanimously cited the strength of their training as a critical factor in deploying the technology successfully. In this case, an external consultant with expertise in GroupSystems training and use was engaged. Training included three two- to three-day sessions, each involving use of successively more advanced tools; every member of the team role-played the use of each tool, with other members of the team acting as the "group." After each training session and subsequent practice using the tools, prospective facilitators led a "mentored" session in which the expert consultant served as co-facilitator for a real group meeting. During mentored sessions, the consultant might coach or trouble-shoot, as necessary; on a few occasions, according to team members, he had to "save" the situation. An intensive debriefing by the consultant followed the meeting.

Finally, the process made unusually effective use of pilot trials. Although they had "the human infrastructure" reasonably well developed by the time the pilot began, according to a team co-leader, "We kept saying we were in a learning mode. We drew no clear line between trial and real sessions because we wanted people to know it might be bumpy." A period of experimentation in which risks are accepted in order to learn what works well in user settings is another key ingredient in successful implementation [7]. Although there were few tangible differences between the pilot and the start of real use, attitudes and expectations differed in ways known to nurture a positive change orientation. One token of the difference is that, although members of the implementation team were making judgments on virtually a daily basis about what worked well and badly, the formal participant evaluation tool was not invoked until after the pilot period ended in January 1994.

CONSEQUENCES OF THE IMPLEMENTATION

During the pilot (May - December 1993), 102 GroupSystems sessions were conducted, chiefly with participants from country operations (about 50 percent) and from personnel and administrative services (39 percent). Trial users reflected three types of groups in the Bank: intact management groups; country teams drawn from across organizational boundaries but with ongoing accountability for work in a particular country; and special project teams (like the implementation team), whose members also cross organizational boundaries to work on specific time-bound tasks [13]. During the pilot, groups typically either were referred by those overseeing the implementation effort, learned about the technology from facilitators who happened to be located in their department, or heard about it from other user groups. Promotional efforts were not undertaken at that time; ORG believed that completing the pilot was necessary "before going very public" with the groupware.

Although no formal evaluation was in place, the pilot provided the implementation team an opportunity to explore approaches to assessment. The room was used at 50 percent of capacity, on average, throughout the trial. As one technographer viewed it, attaining such a high level of use throughout the trial without any internal marketing apart from word-of-mouth diffusion was a success indicator in itself. (Conversely, this technographer said, if word had spread that the system was a real failure -- or even just that it was a waste of time -- it would have been shunned.) Responding to the same evaluation question, a facilitator defined session success as "when the participants all think they got out of it what they sought as objectives," adding that "not always are both the manager and the participants satisfied."

At the beginning of 1994 an evaluation tool was activated to collect regular participant assessments after electronically supported meetings. Evaluation questions attempted to get at whether groupware helped meetings meet their objectives and also to see how GroupSystems sessions compared with other meetings of the group. Over 500 electronic assessment forms were gathered anonymously from participants. Overall, 58 percent of participants believed meeting objectives were met, and almost all the rest thought they were partly met. 64 percent of respondents believed that groupware contributed to meeting the objectives, and another 27 percent thought that it "partly contributed". This was taken as very encouraging news in view of the generally negative opinions about meetings that had stimulated the introduction of this technology. But positive outcomes are not attributed strictly to the technology; rather, the facilitator's contribution also gets high marks (an average of 3.9 on a 5-point scale). It is important to note that participants viewed themselves as relatively comfortable with the technology itself (an average of 4.2 on a 5-point scale); interviewees from user departments believe this is due to ubiquity of email in the Bank.

Because nonelectronic meetings are still the norm in the Bank, additional evaluation questions asked participants to respond to two sets of items; one set addressed GroupSystems sessions and the other the group's traditional meetings (Table 1). Participants believe they had more impact on outcomes under GroupSystems than they do in traditional meetings. Athough they report learning more about the meeting's subject matter than in traditional meetings, participants give highest marks -- both relatively and absolutely -- to knowledge exchange in groupware-supported meetings. That is, they believe they were able to share more of what they knew and that they got more from their peers.

Table 1: GroupSystems Sessions Compared with Traditional Meetings (5=maximum possible)

GroupSystems

Traditional

Learning about meeting subject

3.8

3.2

Participation in meeting

4.2

3.1

Learning about other participants

4.1

3.0

Effect on meeting outcomes

3.4

2.8

IMPLICATIONS OF THE BANK'S EXPERIENCES

The fact that the Bank "did it right" makes it reasonable to try to extract some more general lessons about the effects of this kind of technology on organizational decision shaping and making. The most interesting observations arise from a comparison of the effects on two rather different aspects of meetings: divergent vs. convergent cognitive tasks.

Divergent Tasks

Whether it is the main purpose of a meeting or subsumed under another goal, divergent thinking -- the generation of ideas, alternatives, plans, explanations, solutions, and other creative intellectual inputs -- is well supported by GroupSystems technology. Interviewees across role categories strongly agreed on this conclusion, explaining it in terms of two features of the electronic brainstorming tool. One is that participants can generate inputs concurrently. As a senior manager put it, this "releases the constraints on floor time" that characterize a traditional meeting.

A second key feature is anonymity, which has two positive consequences for divergent thinking At the outset, according to the ORG department head, it broadens participation because "people can be honest without risk." Although bank employees are not notably "shy or inarticulate," they are "not likely to show their hand"; so considerable time can be consumed by maneuvering. Further, once anonymous comments are on the screen, they can be reviewed more objectively than in a traditional meeting. As one facilitator put it, the system "removed the insignia of office, ... so that each idea could be considered on its own merits, not associated with any particular location in the organization or hierarchy." And a technographer commented, "Seemingly people don't support each other's views just for political reasons" in the anonymous mode. Interview material in general corroborated the equalizing effects of computer based interaction reported in many research studies [1,10].

Although these features provide strong support for divergent thinking, experience yielded some lessons. First, group size is a variable to take seriously not just in respect to floor time constraints but also anonymity. One senior manager whose experiences had involved groups of 7 to 14 participants said, "Seven is too small. People were concerned about identifiability," so the anonymous mode "did not produce candor." Other interviewees made similar judgments, although they could not make exact estimates of minimum viable group size. Benefits from GroupSystems technology for divergent thinking tasks are likely limited to larger groups.

Second, the kinds of benefits associated with exposure to a wider-than-usual range of ideas, freedom to consider them objectively, and the synergy of co-mingling views from different disciplines and cultures depend, in part, on time to think and reflect. In early sessions, according to one report, participants appeared to spend much more time developing and typing their own ideas than in reading and integrating others' comments. There was concern that, as a result, contributions were not additive. There was also concern that the fast pace made it difficult to think about and reflect on what was said before more thinking or deciding took place [12]. Said one facilitator, "The limiting factor is how much information you can absorb -- most people want more time to see what other people have said."

As a natural reaction, use of the electronic brainstorming tool often occurred in "waves" or bursts of simultaneous commenting, followed by lulls when participants read each other's views; lulls, in turn, were followed by new waves of commenting "during which participants began to refer to what others had written, and in which some synthesizing of ideas took place" [12]. Subsequently such waves have become planned parts of agendas involving brainstorming. A new benefit associated with GroupSystems meetings ensued: participants, "unconstrained by outside pressure and scrutiny," said they also felt "freer to 'listen'" than they do in traditional meetings; that is, they were able to consider others' opinions more thoughtfully and "to better engage in dialogue" [12].

Convergent tasks

In contrast to divergent thinking, convergent cognitive tasks -- making decisions, resolving conflicts, allocating scarce resources, and other group endeavors that require closure rather than divergence -- are much less well supported by GroupSystems technology. Interviewees all came to this same general conclusion, independently of role. Of course, not all groups are empowered to make decisions. As the head of ITF put it, decision making at the Bank "is not democratic -- the manager has to take the actual decision." In principle a manager could organize a session around a decision, get group input, make the decision, announce it on the system, and get group feedback. In fact, he said, they "don't drive through to the actual decision" on-line.

A second reason why the technology is used infrequently for actual decision making, according to the same implementation team co-leader, is that the Bank's analysis and decision making processes are "extremely thick, dense, and harder than expected to break down." Further, in interdisciplinary groups, "different experts are not sure that all participants should have an equal voice." As a consequence, tools for voting or ranking, and even tools for categorizing and outlining, are not always viable. To facilitate decision making, no matter what the technology, is "very hard to do right" in this context.

Third, there is universal agreement that decisions are made faster when GroupSystems sessions are actually used for decision making. Coupled with broadened participation, the pace of convergence creates unparalleled intensity in the process and ownership of the outcome. However, speed is not always and necessarily advantageous. Sometimes, said a facilitator, speed of convergence on decisions "can lead to decisions unraveling later on." Most facilitators reported at least one such experience but could only speculate about why. One conjectured that the speed "may violate the norms and ethics of decision making." In any case, participants appear sometimes to be at risk of buy-in regret, evidenced by convergence without follow-up.

But convergence is needed more often than divergence alone to get "the real value" out of meetings, according to the GroupSystems coordinator, whether it takes the form of a decision or output that will feed into a decision. For that reason, the "people" skills of the facilitator are regarded as extremely important. Among the lessons learned over time about facilitating convergence are the following:

bullet It is critical to have all the key players involved in a decision topic at the session(s). According to an implementation team co-leader, increased involvement in the interaction--which happens with groupware -- means increased investment in the outcome. As a corollary, "If the right people aren't involved in the process, they'll derail the outcome."
bulletClear ground rules need to be established about a group's charter so that it knows whether it is deciding or instead is recommending, coming to a consensus, giving information or performing some other kind of convergent task. For instance, it should be made clear when vote-taking is a straw poll to get the sense of the group rather than an actual decision. Attention to such ground rules has resulted in some sessions being called focus groups that earlier were viewed as making decisions.
bulletSpaced rather than massed sessions are recommended to avoid potential buy-in regret. For instance, a facilitator suggested, it is better to have four half-day sessions spaced out over time than two back-to-back full-day sessions if an important convergence objective is at stake. To keep up between-session momentum, the facilitator makes use of email discussions.
bulletBesides leaving "breathing space" in the meeting agenda, an implementation team co-leader emphasized other important aspects of session structuring. For instance, "divergent but well bounded tasks, if well run, can help in reaching convergence." Brainstorming is now often used in conjunction with categorizing or outlining for this reason. The GroupSystems coordinator said "In the beginning we were generating data -- too much data!" Now they rely more on techniques that yield "syntheses as output, not lots of individual sentences."

Summing it up, the GroupSystems coordinator remarked, "In the beginning, the technology was running the room." Facilitators tended to use the electronic tools "even when they weren't the best facilitation options," partly because of the general perception that "we shouldn't be tying up the room if we weren't using the technology." This assumption soon gave way to the belief that, especially for achieving convergent objectives, facilitation would likely outweigh the technology as a critical success factor. Now electronic tools are more often "intermixed with other [organizational development] techniques."

Socioemotional Dimensions

Although collaborative tasks are cognitive, they are more than just cognitive; and their socioemotional dimensions are likely to be inextricably woven into their outcomes. In such a context, groupware that offers the technology for broader and more open participation in collaborative tasks would have to be seen as both promising and threatening (and this duality itself might account for some of the reported intensity of interactions). Anonymous participation tools, in particular, are what permit meetings to focus openly on difficult and sensitive problems (e.g., upward feedback, business process restructuring). Interview material suggested two important consequences.

One has to do with saying the unsayable. In response to a question about the most positive effects of the technology, the head of the ORG department answered that it "overcomes the conspircy of silence" evident, for example, in face-to-face meetings when "no one will say that a bad idea is a bad idea." Allowing negative judgments to emerge, in his view, substantially improves the quality of information on which subsequent decisions are based; he gives this outcome much more weight than speed of decisionmaking. Experimental studies conducted by Connolly and his colleagues [8] confirm that provision of negative feedback objectively improves session outputs, although group members report less satisfaction with such meetings.

The GroupSystems coordinator believes the impact of breking through such silences goes even further. He argues that "if something gets to the screen, it's open for comment." No matter how sensitive, the topic has been "'legitimized'. It's socially acceptable to talk about it in this group now," and the topic's legitimacy "carries over to the real world outside the room." This finding is consistent with conclusions from research on pluralistic ignorance in social psychology, which concludes that a major inhibitor of speech and action is each individual's not knowing that a sizeable proportion of the other group members has the same general orientation. (If so, the effect of the technology in these situations is to reduce barriers to production that exist in traditional meetings not because everyone wants to speak at once but rather because no one wants to be the first to break the silence.)

A second major socioemotional dimension of meetings has to do with getting at, or making, shared meanings. According to the ORG department head, GroupSystems technology is "extremely valuable as a tool for understanding, quite apart from decisionmaking." As an illustration he cited the attitude surveys that the Bank periodically administers to tap the vitality and quality of organizational performance. The results never lend themselves to unambiguous interpretation, and the implications for future policies or actions are usually unclear. GroupSystems sessions are being used to "get at what is behind the attitude survey," at the workgroup level: participants can say candidly what they think particular findings mean; others can agree or disagree; and eventually the group arrives at an interpretation of the findings that gives much clearer input to organizational policy and decisionmaking.

While anonymous meeting participation yields important potential benefits, it is not without risks in affectively loaded situations. Negative affect can surface in ways destructive to interpersonal relationships and subsequent group performance. The following scenes, taken from facilitator interviews, are instructive.

bulletA facilitator, preparing to conduct an attitude survey feedback session with a workgroup, knew that there was "a bad manager-employee situation" and was braced for some very negative interactions in the meeting. Surprisingly, the employee chose to self-identify (although anonymous tools were in use) in making forthright comments. In spite or because of that, the resolution of issues was very positive for the employee.
bulletA groupware session was convened for program evaluation purposes. Honestly critical feedback from a sizable proportion of participants angered the program managers, who sought to have the GroupSystems software disconnected.
bulletA unit head, having initiated a meeting for work program planning, was involved in the session as a listener and resource person rather than as a participating peer. At some point in the session, the manager did not like the way the meeting was going and began trying to influence the discussion. The facilitator then had to handle matters of role clarification before the meeting could proceed constructively.
bulletAn attitude survey feedback session led to follow-up action items. The follow-up task force suggested using GroupSystems to discuss the ensuing work. In the pre-meeting planning, it became clear to the facilitator that the session would become a witch hunt with anonymous media used to discredit a particular person. The facilitator took advantage of the planning occasion to indicate that the issues to be raised at the meeting were ones better handled in person; a GroupSystems session was not scheduled.

As these scenes indicate, the same features of GroupSystems technology that can engender organizational benefits are also potentially destructive. When it works positively, according to one facilitator, "the big benefit" lies in "making overt and open a type of dialogue that has been closed and covert." To exploit the benefits and limit the risks, the Bank relies heavily on facilitators to understand and manage the socioemotional side of group processes. In this arena, experience with the groupware has yielded a number of significant lessons.

One key lesson is that not all meetings will be helped -- and some might be harmed -- by groupware. The diagnosis stage in meeting preparation is used as an opportunity for the facilitator to make this point. Further, facilitators now routinely let groups interested in the technology know that candid sessions are likely to surface existing tensions; meeting initiators are urged not to surface them if they are not prepared to deal with them.

Next, managing the socioemotional dimensions of collaboration while keeping the task agenda moving throughout a session is full time work. Even before the pilot, the implementation team realized that the cognitive and affective aspects of meetings would dominate one person's attention. For this reason, the implementors initially assumed that GroupSystems sessions should be conducted by a two-person team, with one attending to group dynamics and the other to the tools themselves. Their experiences have fully corroborated this judgment. Moreover, coping with socioemotional characteristics of convergent tasks requires considerable innovativeness on the part of facilitators-- especially in deploying old skills in the new electronic environment. A telling example was provided by one member of the implementation team, describing a session led by another individual:

At first we were stunned, then we had an "aha" experience, when [a session facilitator] coped with an impasse by dividing the participants into in-person break-out groups. It had never been done before!

But its logic and effectiveness soon became apparent, and subsequently facilitators began importing many standard organizational development techniques into the electronic meeting room. In this interviewee's judgment, the "best sessions" are "about half and half verbal versus technology-based." As the GroupSystems coordinator sees it, the "group dynamics dimension" of the technology "has yet to be fully explored and extended with electronic tools." There is "lots of room for innovation" here, and so far it is "mainly progressing by client, technographer and especially facilitator reinvention."

CONCLUDING OBSERVATIONS: THE SOCIOTECHNICAL FRAME REVISITED

As we suggested at the outset, the key ideas of sociotechnical systems theory as it applies to technology implementation are continuous mutual adaptation of tool and context, task emphasis, the priority of process, and changes in evaluative criteria over time. The Bank case clearly illustrates how these theoretical themes play out in the world.

First, it is not possible to say when the process of "adoption" of GroupSystems technology by the Bank began, or when it will be concluded. This is characteristic of almost all interestingly complex innovations [9]. Commitment to the change took the form of a series of limited-scope decisions of varying degrees of significance to the outcomes; there are few "big-D" Decisions in this sequence of events. The tools and the ways in which they are used have evolved together from vague concepts to operational reality, which in turn continues to evolve; in fact, the last data collection day for this study happened to coincide with the first instance of a new and different use for the groupware (portable deployment).

Sociotechnical theory argues that since the outcomes of technological innovation in organizations are inherently uncertain, the best predictor of positive results is the nature of the implementation process itself. Moreover, if beginning and end points are not well punctuated, there are regular "passages" and "cycles" [20] by which the extent of incorporation of a new technology into an organization may be gauged -- actions that confer formal or institutional status on a new technology (e.g., founding the decision room, creating the position of GroupSystems coordinator), surviving turnover in implementation team leadership or membership, moving from special project funding to line-item budget status, persisting over several fiscal years, and so on. From both perspectives, the introduction of GroupSystems technology into The World Bank should count as a success.

What, then, is to be made of the fact that while this technology is classed as a group decision support system it is rarely used for decision making purposes at the Bank? Or that many key outcomes of GroupSystems use at the Bank (e.g., development of shared meanings, overcoming the conspiracy of silence, predominance of focus group tasks) were not particularly anticipated? Or that achieving participants' objectives depends so crucially on session planning and facilitation-- factors believed by many to outweigh the role of the technology itself? Actually, much of this is predictable. Organizations exist to pursue tasks, not to use technology. Successful technologies are usually those that can achieve reciprocal adaptation with the social organization. Successful implementation is rarely a faithful reproduction of a system fully specified in advance. When successful implementation is conceived in terms of joint optimization of social and technical systems, then positive results should be visible in progress toward organizational missions even when there is no blueprint for innovation.

Finally, even as the system itself changes, so do the expectations held for it and the criteria by which its performance is judged. Studies of other information technologies have suggested that during the first six months or so, while users are learning, experimenting, changing their work routines, modifying the technology, and the like, performance losses are at least as likely as performance gains [6]. It is entirely appropriate that we should find different criteria applied to a fully functioning system than might be applied to vaporware. And there is nothing wrong with creating new criteria as the capabilities of the system are more fully unfolded.

In fact, what the World Bank case shows most clearly is the positive value of reinvention -- the process of users working through for themselves the nature of their tools and how they are to be used [17]. Tool inventors play an essential and irreplacable function. However, tool reinventors are the ones who define what the tools do in practice and the effects that they have in context. Without invention, there are no tools. Without reinvention, there are no uses.

At The World Bank, the generic goals set for groupware are well served, although in ways quite different from those originally envisioned. In the implementation process, the Bank arrived at new ways of understanding and doing collaborative knowledge work. The process goes on. And we can all learn some useful lessons from this cautionary tale.

 

REFERENCES

1. Bikson, T. K. and J. D. Eveland, "The Interplay of Work Group Structures and Computer Support," in R. Kraut, J. Galegher and C. Egido, eds., Intellectual Teamwork, Erlbaum Associates, Hillsdale NJ, pp. 245-290, 1990.

2. Bikson, T. K. and S. A. Law. "Electronic Mail Use at the World Bank: Messages from Users," The Information Society, Vol. 9(2), pp. 89-124, 1993.

3. Bikson, T. K., S. A. Law, M. Markovich, and B. T. Harder, "On the Implementation of Research Findings in Surface Transportation," Research Results Digest, 207, June 1995.

4. Bikson, T. K., "Understanding the Implementation of Office Technology," in Technology and the Transformation of White Collar Work, Robert Kraut, ed., Hillsdale, NJ: Erlbaum Associates, 1986, pp. 155-176.

5. Bikson, T. K, "Organizational Trends and Electronic Media," American Archivist, Vol. 57, No. 1, 1994, pp. 48-68.

6. Bikson, T. K., B. A. Gutek, and D. Mankin. Implementing Computerized Procedures in Office Settings: Influences and Outcomes, RAND, R-3077-NSF, 1987.

7. Bikson, T. K., C. Stasz, and D. Mankin. Computer-Mediated Work:Individual and Organizational Impacts in a Corporate Headquarters, RAND,R-3308-OTA, 1985. Prepared for the Congressional Office of Technology Assessment's report on the automation of America's offices.

8. Connolly, T. "Electronic Brainstorming: Science Meets Technology in the Group Meeting Room" in S. Kiesler (ed.), Research Milestones on the Information Superhighway, New York: Social Science Research Council Press, 1996 (in press)

9. Eveland, JD "Issues in Using the Concept of 'Adoption' of Innova-tions". Journal of Tech-nology Transfer. Vol. 4, No. 1: 1-14, 1979.

10. Finholt, T., L. Sproull, and S. Kiesler, "Communication and performance in ad hoc task groups," in R. Kraut, J. Galegher, and C. Egido, eds., Intellectual teamwork: Social and technological foundations of cooperative work, Hillsdale, NJ: Erlbaum Associates, 1990, pp. 291-325.

11. Johanson, R. Groupware: Computer Support for Business Teams. New York: Free Press, 1990

12. Mankin, D., S. Cohen, and T. K.Bikson. Technology and Teams: Fulfilling the Promise of the New Organization, Cambridge MA: Harvard Business Press, 1996

13. Minahan, M. The Impact of Group Decision Support Systems on Groups: An Ethnographic Study, Unpublished doctoral dissertation, University of Maryland, 1994

14. Pinsonneault, A. and Kraemer, K, "Impact of Technological Support on Groups" in Decision Support Systems, Amsterdam:North Holland Publishers, 1989

15. Shneier, L. "Implementing New Technology: People Issues in Migrating from Office Systems to Groupware" Proceedings of the GroupWare Europe Conference, March 1995

16. Taylor, J. Performance By Design. Englewood NJ: Prentice-Hall, 1994

17. Tornatzky, L. and Fleischer, M. The Processes of Technological Innovation. Lexington MA: Lexington Books, 1992

18. Ventana Systems, Inc. Demonstrations available at <http://www2.ventana.com/ventana/WHATSGS.HTM>, 1996

19. Yin, R. Changing Urban Bureaucracies. Lexington MA: Lexington Books. 1982

20. Yin, R. Case Study Methods. Beverly Hills: Sage Publications, 1990