|
Designing to Support Distributed CollaborationNetwork Communities ReportFebruary 1999 John C. Tang & Nicole Yankelovich AbstractThis paper describes a study of the collaboration work practices of an organization that is distributed among different sites. We identify how people's geographic separation, organizational boundaries, level of trust, and motivation to work together shape their collaborative activities. We outline implications that these factors have for the design of new technologies to support remote collaboration.KeywordsCSCW, work analysis, use-centered design.INTRODUCTIONWe conducted a three-month study of a technical support organization that is distributed among three different sites. Building on earlier research identifying constraints on the effectiveness of groupware [1], our goal was to understand the real-world needs of a distributed organization before designing technology to support their work. We expected that their main collaboration need would be finding the appropriate expertise [2] among the three sites to help them solve problems. Our qualitative observational approach, however, revealed several other factors that play an important role in shaping collaborative behavior:
We describe four examples that illustrate these factors and their design implications for collaboration technology. STUDY DESCRIPTIONWe studied Sun's North American Customer Care Centers (CCCs) which provide technical support over the telephone for our customers. We focused on the organization of approximately 500 engineers distributed among three centers (in California, Colorado, and Massachusetts) that deal with software-related issues. These support engineers are organized into technical topic groups of expertise.Most calls are resolved by the first engineer who takes the call within about 20 minutes. Longer, more complex calls almost always involve collaborating with other engineers with more specific expertise, sometimes at other sites or organizations within the company. During the study, we listened in on 26 sessions of engineers handling service calls (about equal numbers at each of the three sites), conducted 25 interviews of engineers, managers, and individuals who interact with the CCCs, attended four topic group troubleshooting sessions, and logged 35 chat sessions in the two different chat tools that they use. Partnering with CustomersFour to five hours of a support engineer's day is spent working with customers on the telephone. Typically the support engineer must do remote detective work to diagnose the problem. The engineer must often dictate arcane UNIX commands to the customer (e.g., "Do a nisshowcache -v in /usr/lib/nis") and then ask the customer to read back the results. Noisy computer rooms, language accents, and technical jargon all contribute to communication breakdowns.The telephone connects the support engineer with the customer across the geographic distance. While customers are clearly motivated to work with the support engineers to solve their problems, working for different companies also means that there is limited trust between the collaborators and constraints on what they can share. Protective firewalls underscore their technical and organizational separateness. Several technically feasible solutions exist to solve what one engineer described as her "desire to see through the telephone." In designing any technology to address this problem, however, we must consider issues of trust and security. The customer must be in control of what a support engineer can see and do on the customer's workstation. The technology must also work without any extensive installation or download, as customers expect a quick resolution with a minimum of additional effort on their part. Teaming Across SitesThe CCC topic groups typically have engineers at all three sites, creating smaller, physically co-located teams within the larger, distributed topic group. Since the team members at the same site have offices located near each other, do not have to worry about time zone differences among them, and have many more ways of encountering and communicating with each other, most of their collaboration occurs within a site. As one engineer said, most of his collaboration "happens in the chair" (indicating the visitor chair in his office).We discovered that expertise in the topic groups is not evenly distributed among the three sites. Yet, those who do not have access to expertise at their site, often do not take advantage of the remote expertise that is available to them. Instead, we found they would wait until their local guru was free or make do with what local resources were available. Thus, although the topic groups provide a common organizational unit, the geographic groupings afford a stronger sense of trust within the team. Only the participants who have an urgent need for information and cannot find a local expert are motivated enough to make the extra effort needed to collaborate across site boundaries. We were especially interested in the use of text chat as a technology that could bridge across the three sites. The existence of two chat tools, however, fractures the user community (each individual decides independently what chat tool to use, usually choosing whatever their preferred guru uses). Users' touch-typing skill also affects their facility in using text chat. Some groups do make heavy use of the chat tools, but our analysis shows that most of the participants chat with others at their own site, cementing their already close relationships. It was interesting to note the intermixing of work-related and social chat in the tools. Thus, we believe that technology to promote the use of remote resources must do more than just enable collaboration; it must make the remote collaboration feel as comfortable as local interaction. The tool has to support informal, social interactions that help to build up trust and understanding, as well as purely work-related communication. Forming Ad Hoc TeamsComplex customer problems tend to cross group boundaries. For example, a customer's problem with a storage device may also uncover a networking problem, which turns out to be a bug. This problem requires an engineer in the storage group to diagnose the storage problem, a field support engineer to go on site to replace the faulty storage hardware, a networking engineer to diagnose the networking problem, and then a development engineer to create a patch for the bug that was identified in the process.These ad hoc teams typically involve people at different sites and in different organizations. Crossing organizational boundaries can reduce the motivation to work together and give rise to some finger pointing. It also introduces differences in work style. For example, support engineers mostly communicate using the phone, due to the urgency of solving problems, and one support engineer observed that when he transferred to a development engineer position, "the phone stopped ringing" as development engineers mostly use e-mail for greater convenience. Ad hoc teams form dynamically (adding more people as the problem gets more complex and gathering people who have perhaps never worked together before) and disband as soon as the problem is resolved. Technologies to support ad hoc collaboration must account for these attributes. Managing Group KnowledgeAn example of asynchronous collaboration is the CCC's use of a knowledge base that includes the text of previous service orders, how-to documents, patches, and bug reports. Many support engineers, however, find it ineffective and difficult to use. Ironically, previous initiatives intended to improve the database ended up contributing to making it less useful in practice. For example, they wanted to motivate more engineers to contribute to the database by rewarding them for every ten articles they wrote, but that led to engineers submitting duplicate or low quality articles that actually made it harder to find the good information that was there. Also, without any incentive to maintain the knowledge base, little effort is invested in weeding out duplicate or outdated information.Even though the contributors to and the consumers of the knowledge base share common organizational goals, they have not been properly motivated to maintain a useful database. The challenge in this area is to create a system that rewards both the creation of quality information and the use of that information. ConclusionsWe are now poised to design technologies to support the CCCs' collaboration that are substantially different than what we initially anticipated. We thought we would focus on improving the collaboration among the three CCC sites. We now realize that collaboration with the customer is a more pressing need. Even in supporting the collaboration among the CCC engineers, we have a richer appreciation for how and why to increase cross-site, and cross-organizational collaboration. We have also learned the importance of asynchronous collaboration in the form of reusing group knowledge over time.References1. Grudin, Jonathan, "Why CSCW Applications Fail: Problems in the Design and Evaluation of Organizational Interfaces", Proc. of CSCW `88, Portland, OR, September 1988, pp. 85-93.2. McDonald, David W. and Mark S. Ackerman, "Just Talk to Me: A Field Study of Expertise Location", Proc. of CSCW `98, Seattle, WA, November 1998, pp. 315-324. | ||||||||||||||||||||||
