Supporting Virtual Team Collaboration: The TeamSCOPE System

Charles Steinfield
Chyng-Yang Jang
Michigan State University
Department of Telecommunication
East Lansing, MI 48824, USA

Ben Pfaff
Michigan State University
Department of Electronic Engineering
East Lansing, MI 48824, USA

This paper will be published in the Proceedings of GROUP'99: International ACM SIGGROUP Conference on Supporting Group Work.

Copyright Notice:
Permission to make digital or hard copies of part or all 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. Copyrights for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.

Paper URL: http://www.cscw.msu.edu/reports/scope.htm

ABSTRACT

In this paper, we describe a collaborative system specifically designed to address problems faced by distributed (or virtual) teams. TeamSCOPE (Team Software for a Collaborative Project Environment) is a web-based work environment that has emerged from a research project studying the communication needs of internationally distributed engineering design teams. The paper begins by outlining some of the needs of virtual teams. An integrative framework that focuses on facilitation of group members' awareness of group activities, communications and resources is proposed. These needs and awareness requirements are then translated into a set of collaborative system design goals which have guided the implementation of TeamSCOPE. The features of TeamSCOPE are briefly reviewed, and some preliminary observations from early users are provided. We conclude by noting some of the new features planned for TeamSCOPE based on our early trials.

Keywords
Virtual team, CSCW, distributed group, groupware, collaborative systems.

INTRODUCTION
NEEDS OF VIRTUAL GROUPS
          Implications for Collaborative System Design
AWARENESS AS AN INTERGRATING FRAMEWORK
          Types of awareness data
          Delivering awareness data
          Gathering awareness data
          Responses to awareness data
          Summary
DESIGN GOALS
TeamSCOPE IMPLEMENTATION
          Shared file space and file management
          Tracking awareness information
          Facilitating group communication
          Schedule and resource management
          Security
          Open Source architecture
RELATED WORKS
EARLY TeamSCOPE TRIALS
          Group Size
          Shared files in the early stages of group activity
          Group maturity and anticipated future interaction
          The limited number of total groups
          Cost of access
          Importance of training and support
CONCLUSION AND FUTURE DEVELOPMENT
ACKNOWLEDGMENT
REFERENCE

INTRODUCTION

Improvements in communications tools have encouraged many organizations to allocate tasks to groups of employees that are distributed rather than co-located [25]. Such virtual teams enable organizations to take advantage of the particular skills and expertise of workers without incurring substantial travel or relocation costs, and have thus become an important focus of researcher and managerial attention [10, 22, 29]. However, achieving coordinated activity in group work, already difficult for co-located teams [26], is even more challenging for physically distributed groups [9, 11]. When group members are located at great distances from each other, the opportunities for face-to-face collaboration are infrequent, if not nonexistent. As a result, team members are dependent on mediated interactions for coordination, and are likely to face important deficits in the information they have about the day-to-day activities of their teammates. Although many new forms of mediated communications exist to support distributed groups, simple access to communication media alone is insufficient to promote the intense collaborative activity that co-located teams often have. Scheduling problems, lack of communication discipline, cognitive overload, high communications costs, and delayed responses are just a few of the obstacles that limit the effectiveness of various communications media [9, 18]. The danger is that physically dispersed groups will resort to a coordination strategy that essentially minimizes their needs for interaction, primarily by dividing up tasks in such a way that frequent collaboration is not needed [9]. As Fussell and colleagues note, this is a particularly poor strategy for groups operating in changing environments.

In this paper, we describe a collaborative system specifically designed to address problems faced by distributed (or virtual) teams. TeamSCOPE (Software for a Collaborative Project Environment) is a web-based work environment that has emerged from a research project studying the communication needs of internationally distributed engineering design teams [27]. The paper begins by outlining some of the needs of virtual teams. An integrative framework that focuses on facilitation of group members' awareness of group activities, communications and resources is then reviewed. These needs and awareness requirements are then translated into a set of collaborative system design goals which have guided the implementation of TeamSCOPE. The features of TeamSCOPE are briefly reviewed, and some preliminary observations from early users are provided. We conclude by noting some of the new features planned for TeamSCOPE based on our early trials.

NEEDS OF VIRTUAL GROUPS

At the most basic level, we can consider any group characterized by having members in different locations to be virtual. Palmer and Speier [22] defined "virtualness" as the degree of proximity in terms of locations, work cycles, and cultures and suggested that virtualness will introduce potential coordination costs. Today, globally distributed teams in multinational organizations operate across time zones, have differential access to communications infrastructure and services, and work in very different organizational and cultural contexts. All of these factors influence the kinds of coordination and communication needs encountered by the virtual teams. Below, we briefly highlight five types of needs that arise.

Implications for Collaborative System Design
Clearly, distributed and virtual teams face significant challenges to achieving coordinated activity, resulting from their fragmented work environment. Each of the needs above suggests specific implications for collaborative system design. The need to recognize information in a variety of forms suggests that collaborative systems that only emphasize a single application are unlikely to address all the needs of distributed groups. Not only must systems facilitate the transfer of multiple types of information, but they also must be capable of storage and retrieval of multiple types of group artifacts.

The need to arrange for real-time interaction under difficult scheduling situations also suggests some of the needed capabilities for collaborative systems in very dispersed groups. Scheduling support, with recognition of conflicts in schedules is likely to be an essential feature.

To achieve spontaneous and informal interactions, collaborative systems must essentially know about the availabilities of group members and alert members to potential interaction opportunities. The Bellcore Cruiser system[6], ICQ, and AOL Instant Messenger are all examples of this type of functionality.

A collaborative system that helps group members maintain awareness of each other's activities requires the capability to monitor actions of interest and alert users when they occur. The Awareness Monitor [9] is an example of a system that accomplishes this.

Coping with heterogeneous networks, software, and terminal devices requires a collaborative system that is not dependent on specialized hardware and software, and runs over all common network types. Highly distributed, and mobile groups require collaborative tools that have ubiquitous accessibility.

Collectively, these implications suggest that it would be difficult to consolidate all the alternative tools and applications into a single collaboration system. Yet, as pointed out by Olson and Teasley [21], the CSCW research literature is rich in single application studies, such as studies about email, video conferencing, and co-authoring tools. The advantage of this approach is to reduce users' efforts in managing several tools. However, individual communication applications are treated independently, and any potential synergies that might result from systems that explicitly recognize alternative communications are lost. A collaborative system might, for example, recognize alternative communications media to which multiple groups have access, and ensure that scheduling conflicts are avoided.

Collaborative systems include people, tasks, shared objects, communication media, collaborative software tools, and the work environments of the group. We explicitly recognize that collaborative tools are only parts of the collaborative system. The relationship between a collaborative tool and the other components of the system should be considered. Our approach regarding the design of a collaborative tool thus emphasizes supplementing an existing system of alternative media and tools rather than creating a new all-encompassing system of its own.
In essence, these design implications all focus on the need for a network of collaborative tools, held together by a multi-function application that monitors a variety of information relevant to the group's ability to act in a coordinated fashion. Such a central application would help the groups maintain awareness of file-related activities, group communication attempts, schedules, and availabilities of people and resources. The concept of awareness in this context thus becomes very central for coordinated activity.

AWARENESS AS AN INTERGRATING FRAMEWORK

In the context of group work, awareness usually refers to the information about the activities of other group members [7, 13, 19]. Researchers in the CSCW community have long recognized the importance of awareness in facilitating collaborative work [7, 9, 11, 14, 28]. Emphasizing the interdependent nature of collaboration, awareness was thought to be required for coordination of group work [7]. As Gutwin, Roseman and Greenberg [13] pointed out, "workspace awareness reduces the effort needed to coordinate tasks and resources, helps people move between individual and shared activities, provides a context in which to interpret utterances, and allows anticipation of others' actions."

Awareness is thus a useful integrating framework to link different components of a collaborative system. We consider awareness as occurring when group members possess knowledge about the current status and actions of the various components (including people) in a collaborative system. At a basic level, an awareness mechanism focuses on the gathering and delivering of awareness information. It also may go a bit further and provide possible suggested actions for group members based on particular conditions that are sensed, such as the availability of individuals for a real-time interaction. In this section, we introduce some of the types of information that an awareness mechanism might gather and deliver, the alternative ways in which it might be delivered to group members, the approaches a system might use to gather awareness data, and the responses a group member might take when provided with awareness data.

Types of awareness data
Activity awareness
Knowledge about the projected related activities of other group members is a basic type of awareness information. During real-time collaboration, this may simply mean knowing what actions others are taking at any given moment. Most synchronous collaboration tools thus focus on the on-going activities (e.g. [13]). However, much group-related activity, such as editing documents, occurs outside synchronous meetings. Asynchronous groupware, such as BSCW [3] and most software development tools, often provide awareness of past events by making the log files available. It is especially helpful for group members to be cognizant of any modifications to shared objects such as documents or designs.

Availability awareness
Many groupware applications monitor availability of people in order to facilitate informal encounters or social interaction including Cruiser [6], Portholes [8], VENUS [19], @Work [28] and ICQ. Researchers have learned from system trials that in order for social interaction to take off, people need to decide what kind of interaction is appropriate to involve the target party. Therefore, knowing the physical availability of your colleagues is necessary but not sufficient. People also need to know what Tollmar, Sandor and Schomer [28] call 'social awareness', such as whether they are busy at the moment, or otherwise unwilling to accept an interaction request despite their presence on the system. In the case of @Work and ICQ, users indicate their physical availability and willingness to interact by selecting from a preset list or inputting text, which also provides information about future availability.

Process awareness
Process awareness is often found in workflow management systems (e.g. [20]), where the tasks are usually well-defined and represented by a series of sub-tasks. Workflow systems generally assert more control in information flow and the order in which tasks are completed [23]. In order to follow preset procedures, it is useful to provide process awareness which gives people a sense of where their pieces fit into the whole picture, what the next step is, and what needs to be done to move the process along.

Perspective awareness
Anticipation of others' action is important in coordination of collaborative work[5, 13]. In order to better predict others' actions, people not only need information about others' past actions, but also information on how particular actions emerged. More specifically, this implies giving group members information helpful for making sense of others' actions, such as background on team member beliefs and knowledge. This is why Boland et al. [5] suggested that sharing perspective is required for distributed decision makers.

Environmental awareness
Environmental awareness focuses on events occurring outside of the immediate workspace that may have implications for group activity. Fussell and colleagues[9], for example, describe a system that tracks important environmental indicators that a business team might use to make decisions.

Delivering awareness data
Passive or active delivery
These various forms of information can be provided to group members passively or actively. In the passive situation, the collaborative system monitors particular information and delivers it without requiring any specific actions on the part of group members. For example, the system might keep track of who uploads or downloads files, and forwards this to all group members automatically. A potential problem for passive systems suggested by Fussell and colleagues [9] is that when large numbers of actions occur, the group can be overwhelmed with alerts and messages, resulting in cognitive overload. They note that such passive delivery can be intrusive, causing distraction. In addition, when members receive such information out of context, they may fail to appreciate its meaning or significance, and may thus not take appropriate actions in response [7]. However for time-sensitive awareness information, passive delivery has the best chance to get a message across before the meaningful context goes away. Active systems, on the other hand, require group members to take specific actions to request awareness data, and are therefore less intrusive. However, this can result in the underutilization of awareness data, as well as being an added burden on group members.

Differentiated or undifferentiated
Group members may each play a different role based upon their particular expertise or allocated tasks. In scheduling meetings, it may be that one person is responsible for organizing access to resources, such as a video conferencing facility. If there is a conflict due to another group's request for access to the same facilities, perhaps only the organizers need to be made aware of this, rather than all potential meeting participants. A collaborative system may be able to direct particular information to particular people based on these roles. It can also further facilitate coordination by explicitly noting the particular person who needs to respond, avoiding situations where inaction occurs because members leave a response up to someone else. Moreover, an undifferentiated delivery of awareness would overload all group members with potentially irrelevant information.

Customized or fixed
Customization concerns the degree of configurability the users have in determining the awareness information they receive. Choosing to receive awareness updates passively or actively might be one basic type of customization. Additionally, group members may also choose the types of awareness information and the frequency of awareness delivery. The Awareness Monitor [9] is an example of a highly configurable awareness mechanism, which allows users to select the pace and style of in which awareness information is presented and to adjust the sensitivity of the monitoring function.

Awareness Information as Focal versus Peripheral
A peripheral approach would provide awareness data without requiring a group member to take his or her attention away from other work. This would be similar to the way in which we use our peripheral vision or hearing to keep abreast of others' activities in a common physical environment [2]. A focal approach directs the group member's attention to the specific awareness data. For example, in research on air traffic control by Hughes et al. [15], controllers took stock of all awareness information by looking at the spatial arrangement of a flight strip. Benford et al. [2] characterizes this means of providing awareness as the "seeing at a glance" approach. The idea is to benefit from a well-structured arrangement of inter-related information to reduce the necessary cognitive efforts of users as they get updated.

Within a single application or across application
Group members may receive awareness updates by accessing a single application, or the collaborative system may be capable of providing updates to members in a number of separate applications. An example of the former case is when users obtain their updates by going to a specific website or logging into a specific application [9]. In the latter case, an example would be a system that not only stores data for review in a particular application, but is also able to notify members' of important updates via email.

Access anywhere or a particular place
Accessibility of awareness information is an important issue, especially to globally distributed teams. To maintain high accessibility, the requirements of hardware and software to access awareness should be kept at a minimum. Because of its simple client-server architecture and low infrastructure requirement, the World Wide Web represents an increasingly attractive platform for developing collaborative tools for widely-dispersed groups [4]. True mobility of access also means avoiding applications that require members to be at a specific workstation, such as ICQ or AOL Instant Messenger. These require users to have specific software installed that identifies them, which makes it difficult for someone to access awareness data from another person's workstation.

Gathering awareness data
Explicit versus embedded
A collaborative tool can gather awareness information explicitly, such as asking the user to provide the information, or implicitly, such as automatically logging users' actions. One advantage of explicitly gathering desired information is that it can be used to generate awareness of information that would ordinarily be difficult to collect automatically. Social awareness in @Work [28] is one example, where users can select their social situation and type in any additional comments. However, it is also a much more obtrusive method that can cause distraction. Moreover, because users are required to supply this information, the extra work may cause resistance and lead to an undersupply of awareness data. On the other hand, the embedded gathering approach is relatively unobtrusive, and reduces user effort. However, it also limits the possible information to that which has been prespecified by system designers. A mixed approach that combines embedded system logging with explicit but optional provision of information may be a useful compromise, and has been integrated into some systems (e.g. BSCW [3]).

Responses to awareness data
Median-Mora [20] points out that "information is only useful because someone can do something with it." This implies that awareness should be linked to action. Matsuura et al. [19] explicitly expressed this point by defining awareness as a mechanism not only to "provide information about other's activities", but also to "support interactions among them". An example can be found in Portholes system [8], where users will be prompted with a set of action buttons (email, glance and listen) when they click on an image that was used to make them aware of someone's presence.

Summary
This overview is by no means an exhaustive listing of potential design options. It does illustrate, however, the richness of the awareness concept for understanding the potential services that a collaborative system might offer to groups.

DESIGN GOALS

Based on this review, we attempted to design an integrated collaborative tool which takes into account the varieties of awareness information. We also wanted a tool that worked in concert with the many other communication systems and applications that groups might use. Our general goals can best be summarized by the following specific design parameters.

TeamSCOPE IMPLEMENTATION

The above design goals were translated into the following features of SCOPE.

Shared file space and file management
TeamSCOPE equips each team with a team shared file repository, which make it easy to users to store and exchange group related files. The most prominent user interface to access this file space is web-based. An example of the TeamSCOPE web interface is shown in Figure 1, which illustrates the file manager, reminiscent of the Mac Finder or Windows Explorer. Users can easily perform the usual file management tasks via the Web, such as to upload, download, rename, copy, delete, move and change access privileges of a file or folder. A great deal of effort has been invested in making the web interface equally accessible to all web browsers, from text-only browsers up through the latest versions of Netscape and Internet Explorer.


Figure 1. File management in TeamSCOPE

The web interface is layered on an underlying standard GNU/Linux system. Other interface layers parallel the web interface, such as ftp, telnet, ssh, and scp. All these are cross-platform network protocols, so most network computers already support them, whether they are based on PC, Mac, Unix, or other platform. This means that most users need not install additional software to use TeamSCOPE.
TeamSCOPE users are grouped into teams of users working together. Each team has a ``shared folder'' used to share files among teammates. In addition, each user has a ``personal folder'' that can be used to store files of more interest to the user than the team. (Personal folders correspond to and are implemented as Unix user home directories.)

Version control
Teams often want to keep several versions of documents, such as multiple revisions of reports. For the general case, where many files in nested subfolders exist in a tree of branching versions, TeamSCOPE can be integrated into an existing version-control system such as CVS. For simpler cases, TeamSCOPE allows users to specify that older versions of a file be retained, rather than replace, at file upload time. Old versions are renamed with a numeric extension.

Tracking awareness information
The TeamSCOPE system records information on accesses to each team's shared folder and each user's personal directory in a database. This information is used to provide team members awareness of their teammates' activities. Activities tracked by TeamSCOPE include all file-related activities, plus a number of activities related to message boards and calendar events (discussed later in this paper). TeamSCOPE as currently implemented tracks only changes made through web and ftp interfaces; tracking changes made through other interfaces is under consideration.

Awareness information is presented to the user in a number of ways, as described in the sections below.

Opening team page as focal point for all awareness data
Each team can create a website describing their project. By default, TeamSCOPE creates a website for each team which displays a summary of the contents of the TeamSCOPE system, including message board contents, upcoming calendar events, recent file activities, and links to useful information about TeamSCOPE. When users log in to their Team site, they are first presented with this summary page of awareness data (see Figure 2). Normally, viewing of team websites is restricted to team members through login and password, but team members can change or remove this restriction.

Teams can customize the appearance of this page for their own use, using a text editor or an HTML editor with support for server-parsed HTML. Teams can also replace the team page with one of their own design.


Figure 2. Opening team page

Activities screen
TeamSCOPE tracks which activities have been reported to each user. When a user logs in, by default the initial page displays the activities that have occurred most recently. Users can select to have only events matching a set of criteria to be reported on the Activity screen. The criteria can be both content-sensitive, choosing the type of events interested, and object-sensitive, choosing the specific objects interested. For instance, users can request that only activities regarding files in a particular folder be reported. When finished viewing the list of new activities, users may click on a "reset'' link to tell the system not to show these activities again.

Daily emails
Some users may not log in to the web-based system often, but still want to receive awareness information. For their benefit, TeamSCOPE provides the option to receive daily email summaries of activity. Days on which emails are sent are configurable.

Criteria for events to be reported by email can be selected by users in the same way as the web interface. The web and email awareness systems can be set up to interact, so that events already reported by email are not displayed by default via the web interface.

Search
TeamSCOPE maintains an activity history. This history can be searched on the web interface. Multiple search criteria are allowed, and results can be sorted by user, file, activity and date.

Facilitating group communication
Per-file message boards and an overall project message forum
Team members often want to exchange opinions on their files or on the project as a whole. Email is one way to do this. As an additional method, TeamSCOPE provides a threaded message board for each file in a team's shared folder as well as an overall project message board. To help users be aware of the communication on the message board, all related activities are logged, including posting, editing and deletion. Users will see them appearing on the Activity screen as well.

TeamSCOPE also keeps track of who has requested each article. This allows posters to get a rough idea of who is paying attention to their articles and if any other means of
communication is needed.

Synchronous interaction support
Even though TeamSCOPE is mainly a tool for asynchronous communication, it provides some support for synchronous communication. When multiple users on the same team are logged in at once, TeamSCOPE notifies them. It also provides a simple Java applet for real-time text-based chat, accessible by simply clicking on the button on any TeamSCOPE page.

Team email lists
In TeamSCOPE, each distributed team has an email list. Mail sent to the list mailing address is automatically re-sent to all the members of the team. With the help of TeamSCOPE administrator, teams can also create additional email lists with configurable members to suit different communication needs. For example, a team's faculty advisor or corporate sponsor can be included for the discussion of certain issues.

Schedule and resource management
Calendar
Scheduling team meetings and keeping track of deadlines can be difficult, especially when teams are distributed across multiple time zones. TeamSCOPE's calendar features are intended to ease such difficulties by giving team members a clear look at calendar events. A typical TeamSCOPE calendar is shown in Figure 3.


Figure 3. Calendar

Any team member can add an event to the calendar. The event is then visible to all of the members of the team. Each event has a number of properties, the most important being its start date and time and end date and time and its title. Events can also have a more detailed description associated with them, which could be used, for instance, to describe a meeting agenda. Events can also have a team member designated as coordinator for that event.

Events can be displayed in a traditional format or as a Gantt chart. In the traditional format, the intervals and titles of events scheduled for the selected range of dates are displayed alongside a calendar for the month or months associated with those dates. When Gantt representation is selected, TeamSCOPE draws a Gantt-style chart that graphically represents the date or time interval associated with each event.

Shared resource reservation
Sometimes a number of teams must share limited resources. TeamSCOPE has calendar features to ease reservation of these shared resources. For each calendar event, one or more shared resources can be selected for use. This effectively reserves those resources for use by the team within the event's duration.

Conflict resolution is also supported. When a second team attempts to reserve a resource for a period that overlaps another team's already reserved period, TeamSCOPE reports the conflict and allows the user to change the event time or resources. In case more careful coordination is required, the teams are provided contact information for the coordinator of the conflicting event.

Security
TeamSCOPE's web interface security is implemented through a login model. At the beginning of a session, the user supplies his or her username and password, which are transmitted in cleartext to the TeamSCOPE server. The server responds with a 120-bit session ID chosen using a cryptographically secure random number generator. The session ID is then used for authentication for the remainder of the session, transmitted by the user's web client to the server on each page load. The session ID expires either upon an explicit "log out'' action by the user, or after a user-defined idle timeout interval.

Security could be improved by using encrypted connections between the TeamSCOPE client and server. This can easily be implemented by using an SSL-aware web server, such as Apache-SSL. The TeamSCOPE distribution does not include instructions for setting up encrypted connections because of U.S. regulations prohibiting export of software containing encryption code.

Open Source architecture
All the software used in the construction of the TeamSCOPE system is Open Source. This allows the full source code of software necessary for development to be leveraged, greatly speeding development of some parts of the system. For instance, it was necessary to modify the ftp daemon to output logs in the format needed by TeamSCOPE. Since the full sources of the ftp daemon used (proftpd 1.0) were available, the development of an entirely new ftp daemon was avoided.

TeamSCOPE itself, when released, will be under the GNU General Public License, an Open Source-compliant license.

RELATED WORKS

There has been an increasing number of research projects and commercial products aimed at facilitating collaborative works via the Web. Several systems offer a file repository to help team members to share group objects. They include BSCW (bscw.gmd.de), Teamspace (www.involv.com), WebEX (www.webex.com), eRoom, (www.eRoom.com), Lotus's Instant!TEAMROOM (www.lotus.com/teamroom), and HotOffice (www.hotoffice.com). These systems also provide one or more collaborative utilities, such as a threaded message board, calendar, file annotation, active user monitoring and real-time chat. Systems for software development, such as CVS and Visual SourceSafe, specialize in file locking and version control.

TeamSCOPE does not depart far from these systems in terms of functionality. The major difference resides on what awareness information is gathered and how it is presented. Not all systems track information on events in the shared workspace. If they do, the scope of awareness information is often limited, either focusing on file- related activities or calendar entry. Also the awareness information is often scattered in the team workspace. Users have to look into each file or object to get an idea on what happened. TeamSCOPE, on the other hand, provides a central location as well as search capability for event history on files, calendars, message boards and users' usage. In fact, TeamSCOPE greets users with all the new activities once they log in. It is easy for TeamSCOPE users to keep their team in scope.

However, TeamSCOPE is limited in terms of providing synchronous awareness. Although applications such as ICQ offer such a capability, the stand-alone solution doesn't tie into the shared workspace and thus reduces its utility in a teamwork context. Two recent research projects, Awareness Monitor [9] and Orbit project [17] are both helpful in terms of providing real-time awareness information on changes in the shared folder and other users' action in a shared workspace.

EARLY TeamSCOPE TRIALS

The development of TeamSCOPE started in 1998. In the beginning of the spring semester, 1999, we introduced TeamSCOPE to two international student design teams as well as the research administrative team for the INTEnD project [27]. Student teams were composed of five engineering students with two from the Netherlands and three from the U.S. The research administrative team includes researchers from six universities in three continents with a total of 20 members. At the time of writing this paper, these teams had access to TeamSCOPE for about 15 weeks, with the student teams in the final phases of their projects.

In this early trial, we found that the usage of TeamSCOPE differs sharply between the research team and student teams. TeamSCOPE was heavily used by the research administration team from the beginning and throughout this trial period. But the usage of TeamSCOPE has been very limited among the student teams. We found the following factors contributed to this difference.

Group Size
The large group size of the research team made it difficult to keep track of all group activities and thus group members relied more on TeamSCOPE. Also since it was more difficult to arrange synchronous meetings for a large group, the message board in TeamSCOPE was an important outlet for group discussion in the research team. On the other hand, the small size of the student groups made it relatively easy to coordinate through email or video conferencing.

Shared files in the early stages of group activity
The research team created a lot of shared files from the very beginning, which contributed greatly to their early adoption of the tool. However, the number of shared documents was very limited in the early stage of student teams. As a result, they became accustomed to interacting without TeamSCOPE. Although in the final stage of the project, student teams did have more files to exchange among themselves, their established patterns of coordination were hard to overcome. Although they thought TeamSCOPE could be a useful tool, they were reluctant to make any changes to their now familiar exchange patterns so close to the end of their anticipated interaction.

Group maturity and anticipated future interaction
Another related factor is the group maturity in terms of group development. Most members of the research team had been working together for more than one year before TeamSCOPE was introduced and expected to continuously collaborate with each other in the future. However, the student teams were zero-history groups and had no expectation that they would work together after these projects. The combination of a higher interest in the collaborative tools, maturity, and expectation of continued group work made the research team more willing to experiment with TeamSCOPE. Student teams, on the other hand, as a new group with no expectation of continued interaction, were more likely to stick with anything that worked, rather than try anything new or better.

The limited number of total groups
The limited number of total groups reduced the possible needs for inter-group coordination. As a result, the utility of some features of TeamSCOPE, such as resource conflict notification, is not as high as it would be.

Cost of access
Although the Internet is the best candidate for ubiquitous accessibility, it is not free in all places, and suffers from congestion delays. In our trial situations, students in China not only had to pay to access websites in foreign countries, but also not every computer can connect to websites outside of China. It severely reduced their motivation to use the web-based TeamSCOPE. The congestion on the Internet, particularly for international connections, slowed response times for TeamSCOPE, discouraging students in other countries from relying on it.

Importance of training and support
Although teams were shown briefly how to use the various features of TeamSCOPE, they were not provided with extensive training that illustrated the use of TeamSCOPE to solve coordination needs directly relevant to the group. There also was no mechanism for in-person support when groups experienced difficulties using TeamSCOPE..

CONCLUSION AND FUTURE DEVELOPMENT

So far, TeamSCOPE is still under development. We expect to add a number of new features, including a more user friendly interface. We will also continue testing TeamSCOPE on a larger number of virtual teams. The trial version provided us with an initial opportunity to assess utility in supporting highly distributed virtual teams. Based on this beta test experience, several of our assumptions regarding the requirements for collaboration systems appear warranted. Group members generally do work in collaborative systems rather than with single applications. People, shared objects, communication media and software tools are all parts of the collaborative system. Designers of collaborative tools should consider the relationship between the specific tools and the whole system. It is especially important in designing tools for virtual teams because of the fragmented work environment they face.

Moreover, awareness can be a useful concept for groupware design in terms of linking different pieces of the collaborative system. The various types of awareness information provide channels for collaborative applications to relate to each other and integrate with other aspects of team work.

Finally, several factors appear to influence group usage of the TeamSCOPE collaborative tool. They include the size of group, the form of shared object, the level of group maturity and the real accessibility of the tool.

ACKNOWLEDGMENT
The authors are grateful to the National Science Foundation for the grant (IIS-9811568) which funded this research. We would also like to acknowledge the helpful comments of the many colleagues in the INTEnD consortium, as well as Robert Kraut and J.J. Cadiz.

REFERENCE

1. Abel, M. Experiences in an exploratory distributed organization. In Intellectual Teamwork: Social and Technological Foundations of Cooperative Work, eds. J. Galegher, R.E. Kraut, and C. Egido Lawrence Erlbaum Associates, Hillsdale, NJ, 1990.
2. Benford, S., Bowers, J., Fahlen, L.T., Mariani, J., and Rodden, T. Supporting cooperative work in virtual environments. The Computer Journal 37, 8, 1994, 653-668.
3. Bentley, R., Appelt, W., Busbash, U., Hinrichs, E., Kerr, D., Sikkel, K., Trevor, J., and Woetzel, G. Basic support for cooperative work on the World Wide Web. International Journal of Human-Computer Studies 46, 1997, 827-846.
4. Bentley, R., Horstmann, T., and Trevor, J. The World Wide Web as enabling technology for CSCW: The case of BSCW. In Groupware and the World Wide Web, eds. R. Bentley, et al. Kluwer Academic Publishers, Dordrecht, the Netherlands, 1997.
5. Boland, R.J., Schwartz, D.G., and Tenkasi, R.V. Sharing perspectives in distributed decision making, in Proceedings of CSCW '92 (Toronto Canada, November 1992), ACM Press, 306-313.
6. Cool, C., Fish, R.S., Kraut, R.E., and Lowery, C.M. Iterative design of video communication systems, in Proceedings of CSCW '92 (Toronto Canada, November 1992), ACM Press, 25-32.
7. Dourish, P. and Bellotti, V. Awareness and coordination in shared workspace, in Proceedings of CSCW '92 (Toronto Canada, November 1992), ACM Press, 107-114.
8. Dourish, P. and Bly, S. Portholes: Supporting awareness in a distributed work group, in Proceedings of CSCW '92 (Toronto Canada, November 1992), ACM Press, 541-547.
9. Fussell, S.R., Kraut, R.E., Lerch, F.J., Scherlis, W.L., McNally, M.M., and Cadiz, J.J. Coordination, overload and team performance: Effects of team communication strategies, in Proceedings of CSCW '98 (Seattle WA, November 1998), ACM Press, 275-284.
10. Galbraith, J.R., Designing Organizations: An Executive Briefing on Strategy, Structure, and Process. Josse-Bass, San Francisco, 1995.
11. Galegher, J. and Kraut, R. Computer-mediated communication for intellectual teamwork: A field experiment in group writing, in Proceedings of CSCW '90 (Los Angeles, October 1990), ACM Press, 65-78.
12. Goodman, G.O. and Abel, M.J., Communication and collaboration: Facilitating cooperative work through communization. Office: Technology and People 3, 1987, 129-146.
13. Gutwin, C., Roseman, M., and Greenberg, S. A usability study of awareness widgets in a shared workspace groupware system, in Proceedings of CSCW '96 (Cambridge MA, November 1996), ACM Press, 258-267.
14. Heath, C., Luff, P., and Sellen, A. Reconsidering the Virtual Workplace: Flexible support for Collaborative Activity, in Proceedings of ECSCW '95 (Stockholm , September 1995), Kluwer Academic Publishers, 83-99 .
15. Hughes, J.A., Randall, D., and Shapiro, D. Faltering from ethnography to design, in Proceedings of CSCW '92 (Toronto Canada, November 1992), ACM Press, 115-122.
16. Kraut, R.E., Galegher, J., and Egido, C. Relationships and tasks in scientific collaboration. Human-Computer Interaction 3, 1987-1988, 31-58.
17. Mansfield, T., Kaplan, S., Fitzpatrick, G., Phelps, T., Fitzpatrick, M., and Taylor, R. Evolving Orbit: a progress report on building locales, in Proceedings of Group'97 (Phoenix AZ, 1997), ACM Press, 241-250 .
18. Markus, M.L. Toward a "critical mass" theory of interactive media. In Organizations and Communication Technology, eds. Fulk J. and Steinfield C. Sage Publications, Newbury Park, CA, 1990.
19. Matsuura, N., Fujino, G., Okada, K.-I., and Matsushita, Y. Venus: A tele-communication environment to support awareness for informal interaction. In The Design of Computer Supported Cooperative Work and Groupware Systems, eds. Shapiro D., Tauber M., and Traunmuller R. Elsevier Science B. V., Amsterdam, 1996.
20. Medina-Mora, R., Winograd, T., Flores, R., and Flores, F. The action workflow approach to workflow management technology, in Proceedings of CSCW '92 (Toronto Canada, November 1992), ACM Press, 281-288.
21. Olson, J.S. and Teasley, S. Groupware in the wild: Lessons learned from a year of virtual collocation, in Proceedings of CSCW '96 (Cambridge MA, November 1996), ACM Press, 419-427.
22. Palmer, J.W. and Speier, C., Teams: Virtualness and media choice. International Journal of Electronic Commerce. 3, 1, 1998, 27-48.
23. Prinz, W., Rodden, T., Syri, A., and Trevor, J. Modeling cooperative work settings with active workspaces. In The Design of Computer Supported Cooperative Work and Groupware System, eds. Shapiro D., Tauber M., and Traunmuller R. Elsevier Science B. V. Amsterdam, the Netherlands, 1996.
24. Root, R.W. Design of a multi-media system for social browsing., in Proceedings of CSCW'88 (Portland OR, 1988), ACM Press, 25-38 .
25. Sengupta, K. and Zhao, J.L. Improving the communicational effectiveness of virtual organizations through workflow automation. International Journal of Electronic Commerce 3, 1, 1998, 49-69.
26. Steiner, I.D., Group Process and Productivity Academic Press, New York, 1972.
27. Steinfield, C., Goodman, E., Lloyd, J., David, K., and Hinds, T., Globally distributed engineering design teams: Cultural, social, and technological factors influencing group process and performance. 1998, NSF proposal.
28. Tollmar, K., Sandor, O., and Schomer, A. Supporting social awareness @Work: Design and experience, in Proceedings of CSCW '96 (Cambridge MA, November 1996), ACM Press, 298-307.
29. Townsend, A.M., DeMarie, S.M., and Hendrickson, A.R., Virtual teams: Technology and the workplace of the future. Academy of Management Executive 12, 3, 1998, 17-29.
30. Trevino, L.K., Daft, R.L., and Lengel, R.H. Understanding managers' media choices: A symbolic interactionist perspective. In Organizations and Communication Technology, eds. Fulk J. and Steinfield C. Sage Publications, Newbury Park, CA, 1990.

| INTEnD Reports |