acm-header
Sign In

Communications of the ACM

Global Applications of Collaborative Technology

Groupware and the Social Infrastructure of Communication


Groupware1 has been widely promoted as a technology that can facilitate the global integration of geographically distributed organizations by overcoming time-space barriers to communication and hence promoting knowledge sharing. Despite huge investments in groupware technologies, however, results have often failed to live up to expectations. While various technical, managerial, and cultural explanations have been proposed, limited consideration has been given to the importance of the social relations that underpin effective communication.

Here, we draw on an in-depth longitudinal study of groupware use in a global professional services organization to explore some key difficulties associated with using such technology to facilitate communication and knowledge sharing within geographically distributed groups. It is argued that management needs to cultivate communities that share a social context within which they can interpret the contributions of others; norms of behavior that reduce feelings of vulnerability and promote trust; and, a sense of mutual solidarity as a motivation for participation. In other words, managers must pay as much, if not more, attention to the development and maintenance of the social infrastructure underlying communication as they do the technological infrastructure.

Blue Corp. is a large global professional services organization in the financial sector that made a significant investment in the Lotus Notes groupware product in the early 1990s. Blue's Software Application Services (SAS) division, which specialized in small-scale software implementation projects, had groups in many of the firm's U.S. offices, but these operated independently of one another and showed wide variation in their product specialties and available skills. Due to competitive pressures, the Central SAS organization decided the local groups needed to work more closely to leverage their collective strength. Thus, Central developed a Notes-based application called "TrackApp" used by each office to store details of all interactions with clients, project descriptions and documentation, and staff skill profiles.

Prior to the introduction of TrackApp, communication and knowledge sharing between offices was informal. If expert advice was unavailable locally, personal contacts in other offices would be used to solicit help. This tended to work best for more senior people, as they had the most extensive global networks of contacts and more regular interaction with other offices. Junior staff usually depended on the contacts of their senior colleagues.


Managers must pay as much, if not more, attention to the development and maintenance of the social infrastructure underlying communication as they do the technological infrastructure.


TrackApp was designed to overcome the limitations of such seemingly inefficient communication mechanisms by making information about the activities, practices, and experiences of different groups publicly available. It also provided shared electronic fora for discussion and interaction. Interestingly, however, the initiative enjoyed limited success as some critical difficulties soon became apparent.

Without a shared frame of reference or context of understanding (developed through ongoing social interaction and negotiation), people had problems interpreting information contributed by others. Consultants, for example, found it difficult to judge the extent of an unknown colleague's expertise from their TrackApp profile. This was compounded by the fact that, in the competitive and individualistic environment of a consulting organization, there could be a temptation to use the system as a vehicle for self-promotion. Indeed, one manager described how his trust in TrackApp was destroyed when he came across the profile of a recognized colleague at a neighboring office who presented herself, misleadingly in his judgement, as an expert in a particular area. After this experience he reverted to phoning trusted contacts to obtain reliable information.

Anxiety was also expressed about the possible consequences of making information about work activities publicly available in TrackApp for fear this might be interpreted and used by colleagues in other offices. In particular, there were concerns about attracting public criticism that could damage one's reputation and prospects for advancement. Consequently, consultants took great care about how they represented their activities in TrackApp and tended to publish uncontroversial, sanitized accounts of their work. Again, the importance of established relationships appears to be critical, as people were much less concerned about the information being used by known colleagues, who would generally be familiar with the circumstances under which such activities were carried out and had a broader basis to evaluate them. For example, if a project proposal was put together hastily to meet tight deadlines, local people would be aware of this and make suitable allowance. Moreover, established personal bonds and behavioral norms meant it was unlikely that known colleagues would make criticisms in a damaging public manner.

Personal bonds also seemed to facilitate richer forms of cooperation. A consultant who expressed reservations about contributing to TrackApp, stated this was not because he lacked collegiality, citing in evidence a recent request by an unknown colleague from a remote office. He invited her to fly in to meet him and, after some discussion, gave her full access to his filing cabinet. He argued, however, that he would never consider making this same information available in TrackApp. Equally, if the colleague had obtained the information from TrackApp without any contact with its author, she might have found it harder to understand. Indeed, if the information had been put in the database as a matter of course, rather than being volunteered, she might feel less obliged to the author. Thus, TrackApp significantly altered both the incentives to provide information and the risks associated with so doing.

These difficulties lead TrackApp to be ignored by most of the offices (although many developed similar applications for local usage). The one notable exception was the Washington, D.C. office where, despite initial reservations, the staff gradually became enthusiastic users. A significant factor in achieving this turnaround was the persuasion and reassurance of the head of the Washington practice. He addressed people's fears about criticism by promoting collective responsibility for TrackApp entries and assuring them their work was of a high standard and any criticism would be more a reflection on his judgement, not the individual. He also encouraged them to interpret criticism in a positive light, as an invaluable opportunity for learning.

The widespread usage of groupware also seemed to facilitate new forms of cooperative interaction among the Washington staff, most of whom rarely met face-to-face since they usually worked at client sites. With the introduction of TrackApp, the consultants' occasional meetings were transformed from normal social pleasantries to interesting conversations with awareness of each other's work and expertise. Thus TrackApp did not replace existing modes of communication but, rather, supplemented them. The manager further capitalized on this by organizing more regular office social gatherings. As a result, the staff described feeling much closer as a group and this newly developed mutual solidarity was manifested in further increases in cooperative interaction.

Back to Top

Implications and Recommendations

The experiences described here provide significant insight into the difficulties associated with using groupware technology to facilitate better communication and knowledge sharing within and between geographically distributed groups. In particular, we have drawn attention to the social and situated nature of communication and the importance of underlying relationships and mutual knowledge among the parties involved. Even within what might seem to be a unitary organization operating in a single cultural context, it appears there may be significant social barriers to communication that technology alone is unable to overcome.

To address such issues, we suggest organizations pay more attention to cultivating and maintaining the social infrastructure that underpins communication, especially a shared language to overcome problems of interpretation and a secure and trustful environment to alleviate feelings of vulnerability to the critical scrutiny of others. The concept of "community," with its implication of shared language, values, and identity, would seem useful in characterizing such an infrastructure and would suggest the cultivation of community (as in Washington) is necessary if rich forms of interaction are to be facilitated through the use of such technologies. The mutual solidarity promoted by a sense of community may also provide a richer explanation of incentives for participation beyond simple economic cost-benefit calculus.

Of course, the cultivation of such communities may present significant difficulties in itself, especially when their prospective membership is large and heterogeneous. Attention must be given to identifying appropriate community boundaries since it may be necessary to limit access. The development of local, private versions of TrackApp by many SAS groups may be seen as a response to concerns about its openness to a large number of anonymous colleagues. Such boundaries will critically depend on the sensitivity and complexity of the envisaged information exchanges.

Finally, the case of the Washington SAS group also illuminates important aspects of the manner in which groupware can facilitate novel forms of social interaction and promote the development of a more coherent group identity. In particular, we noted that groupware seemed to provide just one part of an overall communications environment, that includes the watercooler, telephone, video conference, among others. Managers must consider how groupware can coexist with and supplement these other important components of an organization's communications infrastructure.

Back to Top

Authors

Séamas Kelly (Seamas.Kelly@ucd.ie) is a lecturer in MIS at University College Dublin, Ireland.

Matthew Jones (m.jones@jims.cam.ac.uk) is as lecturer in information management at Judge Institute of Management Studies, University of Cambridge, England, U.K.

Back to Top

Footnotes

1In this article, we focus specifically on asynchronous groupware, although much of what we say might also apply to technologies that support synchronous interaction.


©2001 ACM  0002-0782/01/1200  $5.00

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.

The Digital Library is published by the Association for Computing Machinery. Copyright © 2001 ACM, Inc.


 

No entries found

Sign In for Full Access
» Forgot Password? » Create an ACM Web Account
Article Contents: