3.0 Elements of Successful Collaboration

Review of the academic research on collaboration in combination with industry's experiences leads to the identification of 10 key elements that influence the effectiveness of collaboration efforts (Figure 2). In general, the basic elements of effective teamwork and collaboration are the same regardless of whether team members are working in a face-to-face meeting or working in a virtual environment that connects team members separated by either time or space. The following sections of this report address each of the elements of successful collaboration in detail. The discussion begins with an overview of industry experiences as well as academic research on the topic. The next section discusses challenges currently facing the IC related to each element of effective collaboration. The final section identifies strategies for success to enhance the effectiveness of IC collaboration efforts.

3.1 Culture of Sharing

3.1.1 Lessons From Industry and Academia

Numerous studies on the effectiveness of groupware have found that the fundamental determinant of groupware success is whether the underlying culture and structure of an organization is supportive of collaboration. For groupware to be successful, the expectations and practice of collaboration must exist prior to the introduction of the technology (Pattison-Gordon, 1998). Therefore, if an organization is currently collaborating, either internally or with outside organizations, the introduction of groupware will likely enhance the effectiveness of those collaborations. On the other hand, if organizations are not currently collaborating, then the introduction of groupware systems alone will not be sufficient to change the way people interact or the way business is conducted (Vandenbosch & Ginzberg, 1996).

Unfortunately, organizations that have an inherently collaborative culture are rare in both government and industry. A 1997 survey of 431 business executives conducted by Ernst and Young found that an inappropriate corporate culture was the greatest impediment to the effective transfer of knowledge within their organizations. Executives characterized their cultures as rewarding knowledge hoarding rather than knowledge sharing.

The impact that culture can have on the effectiveness of groupware is illustrated in a study of the implementation of Lotus Notes groupware into a large service firm. The study found that Lotus Notes tools did not live up to management's expectations to increase corporate collaboration. In fact, the tool was primarily used by employees to enhance their personal productivity rather than to distribute and share information for the corporate good. The failure of Notes to enhance collaboration was attributed to a corporate culture that encouraged competition rather than cooperation among employees. The research concluded that, "where the premises underlying the groupware technology (shared effort, cooperation, collaboration, etc.) are countercultural to an organization's structural properties (competitive and individualistic culture, rigid hierarchy, etc.), the technology will be unlikely to facilitate collective use and value" (Orlikowski, 1992).

Some of the most highly recognized collaboration success stories have been with the Big Six management consulting firms (e.g., Anderson Consulting, Coopers & Lybrand, Ernst & Young, and KPMG). These organizations' effective use of groupware has been attributed to their corporate history of internal information sharing. Rather than trying to totally revamp existing business practices, groupware was an extension of the way these firms already conducted business. Senior management from Ernst & Young emphasized the importance of culture and warned that organizations that do not have a culture that supports information sharing are unlikely to reap the benefits offered by groupware. At Ernst & Young, the priority for information sharing was set at the highest levels of management (Clark et al., 1997).

3.1.2 IC Issues

IC senior managers agree that the community has a long history of not sharing information. Even though the community is seen as making recent strides toward increased interagency collaboration, there is widespread acknowledgment that the community has significant cultural, policy, and procedural barriers to overcome for collaboration to become an integral component of the intelligence process.

Currently, a strong competitive culture exists among the Agencies. A key factor driving competition is the budget process in which Agencies vie for resources. IC Agencies more typically publish intelligence reports in competition with each other as opposed to collaborating on joint efforts. It is also difficult for Agencies to accept that they do not have to be self-sufficient but rather can depend on the expertise and data from other organizations to meet their mission. The IC's standard practice of compartmentation and intelligence stovepipes also minimizes information sharing.

3.1.3 Strategies for Success

Given the prevailing culture within the IC does not inherently support interagency collaboration, specific steps must be taken at the community, organizational, and individual team level to support collaboration efforts. The remainder of this paper will examine each of the key issues identified in Figure 2 to begin building an IC culture supportive of collaboration.

3.2 Common Goal for Collaboration

3.2.1 Lessons From Industry and Academia

As with any team effort, virtual teams need to have a clearly defined, common goal to provide focus and motivation for participation. Industry experiences have shown that successful collaborations are driven by a specific business need. Teams with ill-defined goals for groupware are less successful than those with clearly defined goals (Dennis et al., 1998).

The definition of metrics to gage progress toward goal achievement helps clarify goals. If a team cannot specify how they will determine whether a goal has been reached, then the goal is probably not clearly articulated. It is also important to define goals that are best achieved through collaboration. Not all tasks require collaboration. Documenting the anticipated value added of collaboration will help ensure that defined goals are suitable for collaboration.

Not only should the goal be clearly defined, but users also need to buy in to the importance of the goal. This does not mean just management buy-in, but buy-in from all users. Reaching consensus on goals is complicated by the fact that workers' perspectives on collaboration often vary depending on their position and role in an organization. Experiences implementing groupware at Silicon Graphics International (SGI) found that senior managers, middle managers, and staff workers are likely to have different perspectives on what is best achieved through collaboration and what the barriers are to those goals (SGI, 1996). Ernst & Young's 1997 survey of business executives found that the lack of a shared understanding of the business strategy was a significant impediment to information sharing within organizations. The challenge for an organization is to ensure that these varying perspectives can be supported in a hierarchy of goals in which the objectives and concerns of all users are accommodated. Achieving a shared vision for collaboration requires the early involvement of all levels of users in the planning and deployment of groupware systems.

It is also important for collaboration goals to be consistent with the organizational or community culture in which team members must operate (Pattison-Gordon, 1998). If virtual team members are asked to work toward a goal where significant cultural forces are working in opposition, it is unlikely that the team will be successful. If the culture is not supportive of collaboration activities, then small steps toward cultural evolution are most effective. Many organizations, such as the Big Six consulting firms, have made progress by starting with small, clearly defined collaboration activities where the likelihood of success is high (Clark et al., 1997). These small successes plant a seed for the larger scale cultural changes needed to support more aggressive collaboration.

3.2.2 IC Issues

During the interviews for this study, NIPB members defined what they believe should be the general goal of IC collaboration on a scale that ranged from: (1) simple awareness of each others' activities, (2) coordination of activities ensuring comprehensive coverage and reduction of duplication, (3) active sharing of information, and (4) participation in joint efforts. Figure 3 illustrates the NIPB members' responses. The National Intelligence Council (NIC) and DOD organizations (i.e., DIA, NIMA, and service intelligence centers) believed that the predominate goal of IC collaboration should be joint efforts. CIA Directorate of Intelligence (DI) was on the opposite end of the scale reporting that in most cases simple awareness of each others' activities is adequate with a few activities requiring coordination across the community. NSA fell between joint efforts and information sharing. State/INR, FBI, and DOE reported that in most cases widespread information sharing should be the goal of IC collaboration.

The hierarchical depiction of the collaboration levels in Figure 3 is not intended to imply an ideal level of IC collaboration. Rather, the purpose of the chart is to illustrate the lack of a shared vision among senior IC officials regarding how the community should be collaborating. The chart is also not intended to indicate that organizations believe that one mode of collaboration fits all circumstances. The NIPB members acknowledged that the appropriate level of collaboration is highly dependent on each specific task. Therefore, all organizations believed that there are instances when each of the levels of collaboration may be appropriate. The difference among the organizations is what they perceived should be the goal for the majority of IC collaborations. The challenge facing the IC is to find those instances of overlap where community buy-in can be obtained on an appropriate level of collaboration.

NIPB members indicated that there are several reasons why components of the IC have differing perspectives on collaboration goals. First, the IC is not a community but a collection of Agencies with varying missions, customer sets (i.e., policymaker, warfighter, law enforcement), priorities, and management processes. The conflicts between missions and priorities occur not only between but also within Agencies. NSA and NIMA leadership reported being pulled between their roles as members of the IC and their roles as combat support agencies.

3.2.3 Strategies for Success

The first step toward successful IC collaboration is the community's decision to share. This decision needs to be driven by a compelling and clearly defined need. Four fundamental questions should be addressed by the IC: (1) Why should organizations share information (articulate the expected value added of collaboration to specific activities); (2) What specific information should be shared to achieve these goals; (3) Who needs to participate in the collaboration; and (4) How will the information be shared? Success is unlikely to be found in one overarching goal to meet the DCI's vision for community collaboration, but rather in small, well-defined problem sets that provide a seed for broader collaboration activities in the future.

Once the decision has been made to share and specific goals for collaboration activities have been defined, the next step is to obtain buy-in. A hierarchy of supporting goals should be defined to address the needs and expectations of all levels of participants. Buy-in to all levels of the goal hierarchy should be documented ranging from high-level mission statements to specific team assignments. This documentation helps ensure commitment to the goals, helps the team stay focused on their original assignment, and provides a valuable reference for new team members. A key component of obtaining buy-in to collaboration goals, especially at the working team level, is for management to communicate the priority of collaboration to all levels of the organization.

Measuring the impact of collaboration and reporting successes is a valuable tool for encouraging participation in groupware systems. Metrics for gauging progress toward goals is important for any program. If a team does not know where they are going, then any road will take them there; and if they do not have a method for assessing their progress, how does the team know when they have arrived (Cunningham, 1999)? Understanding the current position is also critical to any evaluation program. If the team does not know where they are, it does not matter where they are going. Organizations who do not baseline their current processes frequently do not understand the strengths and weaknesses of their existing practices and, therefore, do not know what can be gained through the use of groupware.

A final note with regard to collaboration goals is that they are likely to change over time. The role of collaboration should evolve to meet the changing requirements in process, task, and organizational structure. Collaboration initiatives should include a mechanism and schedule to revisit and realign collaboration goals with inevitable changes in requirements.

 

Collaboration Goals Define specific goals and document the anticipated value-added of collaboration to those goals. Ensure alignment of goals with organizational culture. Obtain buy-in to goals from all participants. Define metrics to gauge progress toward goals. Define schedule or ongoing mechanism to realign goals based on system evolution.

3.3 Business Process and Workflow

3.3.1 Lessons From Industry and Academia

Most organizations approach collaboration issues from a technology rather than a process approach, allowing specific groupware systems, rather than a business need, to drive the initiative. However, organizations that start out with a technology solution and then look for a problem to solve are destined to fail (Clark et al., 1997). While managers often assume that the installation of groupware alone will create change, experience has shown that, unless the culture, processes, and structure of an organization support information sharing, groupware alone is unlikely to change existing practices or jump-start collaboration activities.

Addressing the process aspects of collaboration is a painstaking and time-consuming task. For most organizations, collaboration means change. Significant debate surrounding collaboration efforts should be expected as the merits of existing practices and alternatives for future solutions are examined. Whether groupware is successful is likely to be dependent on an organization's commitment to address significant cultural, procedural, and policy issues associated with collaboration (Bowers, 1994). If organizations are serious about collaboration activities, then they must dedicate the resources necessary to address process issues (Davenport, 1996).

The process of collaboration is not an issue simply addressed in preparation for the deployment of groupware, but should receive continual attention to support organizational and tool evolution. In fact, the success of groupware initiatives may be dependent on the change model adopted by the organization. Traditionally, the introduction of new technology is managed as a series of predefined steps, bounded by time, and targeted to support a static objective. This approach assumes that the organizational impact of the technology is fairly predictable, which is probably not the case for collaboration tasks (Orlikowski & Hofman, 1997). Researchers have suggested that groupware is more effectively managed as a continuous, evolutionary process "with organizational change as a central factor rather than a problem to overcome" (Jennings, 1993).

Effective support for the evolution of groupware use involves adaptation of both the organization and the tools. This means deploying tailored tools to tackle initial collaboration goals, monitoring tool use over time, and modifying the tool to meet the changing demands of its users as the process of collaboration changes organizational procedures and structures (Hepso et al., 1996; Orlikowski & Hofman, 1997). Evolutionary change, however, may be problematic for rigidly controlled, bureaucratic organizations (Orlikowski & Hofman, 1997). Organizations such as British Petroleum have learned that groupware initiatives are best managed as business change projects rather than traditional information technology IT projects (Greenes, 1996).

One of the key process issues that should be addressed is the integration of tools into existing business processes and workers' normal workflow (Jones, 1995). Isolation of groupware from either the flow of control (i.e., process of accessing the tool's functions) or flow of data (e.g., requirement to transfer data between systems or applications) hinders the productive use of these tools. In a survey of 25 organizations that had deployed groupware systems, lack of integration into existing workflow was found to be a significant barrier to tool use (Bullen & Bennett, 1990).

3.3.2 IC Issues

Many community collaboration systems are not fully integrated with the analysts' basic tool set on their primary workstations. This lack of integration is due to the varying security levels of the systems and policies that require the separation of organizational and community networks. Content management becomes a more significant task when systems are not fully integrated, requiring management of data that resides across multiple, separate domains.

Another area of concern is the compatibility of collaboration systems and the new work paradigms they support with the existing paper-based, hierarchical workflows typically found in the IC. Detailed examination of how collaborative processes will supplant or coexist with current procedures is critical to success. Absent specific guidance, workers are likely to continue with known, approved procedures, suppressing efficiencies that may be gained through collaborative networks.

 

Lack of integration of groupware into the main flow of data and flow of control significantly limits the effectiveness of collaboration.

3.3.3 Strategies for Success

The challenge for the community is to clearly define how new collaboration mechanisms fit into existing processes. Detailed mapping of collaborative work processes will help facilitate resolution of duplication, omissions, or conflicts with exiting procedures. Process mapping should include identification of resources required to support the proposed effort. Commitment to the resources should be considered a requisite to system deployment. Introduction of systems that do not have appropriate resource backing will create frustration among users. This will likely lead to system failure as well as difficulty gaining user support for future systems.

Mapping of the collaboration process and its relation to existing workflows should begin with the goals defined for the collaboration effort. The next step is to define who needs to be online to achieve those goals. Identification of required users should specify the criteria for system access, including the need for restricted access areas based on either need-to-know or varying clearance levels. Once the personnel requirements are defined, then the data required to achieve the goals should be specified. This includes the specific types and classification of data that should be accessible through the system. The last step is to define the process in which people interact with each other and the data. Processes associated with data included mechanisms for feeding, monitoring, accessing, updating, and archiving data. It is at this point that integration with existing data sources should be defined. Procedures and responsibility for content management are specified and, in turn, fed into the personnel requirements necessary to support the system.

Effective content management is a key determinant of the success of groupware systems. Information that resides within groupware systems must be accurate, reliable, and up-to-date to draw users. Successful groupware systems provide easy access to a unique data source. Failure to maintain the integrity of data can quickly erode users' support for the system. However, creating and maintaining rich content is rarely an easy task. Industry and government experiences show that content management is frequently the most costly aspect of groupware, outweighing the costs associated with system development, deployment, and training (Tristram, 1998). Mediation or facilitation of groupware use can greatly assist content management, maintaining the quality and focus of online communications and data postings (Kaye, 1992). Designated facilitators are recommended to help keep discussions on track and ensure that users are working toward designated collaboration goals.

Another aspect of groupware facilitation is assisting users in the application of tools. While initial process maps are a starting point for collaboration efforts, the most effective systems are those that evolve with the changing requirements of users and organizations. A comprehensive support plan for collaboration systems should include the mechanisms and responsibility for supporting timely system evolution.

Researchers at Massachusetts Institute of Technology (MIT) who have studied the implementation of groupware into large businesses recommend the use of what they term technology-use mediation to support the evolution of groupware systems (Orlikowski et al., 1994). The role of these technology mediators is to monitor and rapidly adapt the technology to evolving needs of users. Anderson Consulting employs knowledge exchange champions to provide continuing facilitation to workers in how best to employ the capabilities offered by groupware. These champions provide support through regularly published newsletters, monitoring and contributing discussions in the electronic discussion forums, and one-on-one training (Clark et al., 1997).

 

Integration of Collaboration Processes Deconflict collaborative processes with existing work paradigms. Define who needs to be online to achieve collaboration goals. Specify criteria for system access. Define types and classification level of data to be on the system. Integrate groupware into existing systems and data flow. Define and document roles and responsibilities. Designate responsibility and process for content management. Define and document the role of facilitators within the system. Support evolving needs of users and organizations. Ensure availability of data and personnel resources.

3.4 Trust Among Virtual Team Members

3.4.1 Lessons From Industry and Academia

Trust is central to effective virtual teams (Cutkosky et al., 1996; Handy, 1995; Rocco, 1998; Warkentin, 1997). Case studies of collaboration within industry giants such as Lotus Development Corporation, Eastman Kodak, Hewlett-Packard, and Whirlpool have shown that the effectiveness of virtual teams is dependent on an underlying network of social relationships of which trust is the most important ingredient (Geber, 1995). Virtual teams need to trust that the information they receive from each other is accurate and reliable. In addition, team members need to trust that the information they pass on to their colleagues will be handled in the agreed upon manner (e.g., rules regulating further distribution).

Most organizations are structured on the assumption that people cannot be trusted. Command and control processes are generally applied at all levels and for all processes within an organization to ensure compliance with established regulations and to reduce errors whether intentional or accidental in origin. However, the potential benefits of groupware will be more readily achieved if organizations migrate to a structure and culture based on trust rather control (Handy, 1995).

Industry and academia agree that face-to-face interaction is an essential element for establishing trusting relationships in virtual teams (Geber, 1995; Handy, 1995; Rocco, 1998). While teams often believe that groupware will eliminate the time and travel needed for face-to-face meetings, experience shows that virtual communications are most effective when viewed as a supplement to, not a substitute for, face-to-face interaction. In virtual teams, face-to-face and remote communications assume different roles. Face-to-face interactions deal more with process than task, focusing on personal relationships rather than completing a specific objective (Handy, 1995). Even technologies such as video teleconferencing (VTC) may not provide a viable alternative to face-to-face interactions. Computer-mediated communication is believed to significantly degrade the paraverbal and nonverbal cues used to convey and establish trust (Warkentin et al., 1997).

Initial face-to-face meetings are especially critical to kick off team activities (Warkentin et al., 1997). The personal interaction that occurs during face-to-face meetings provides the opportunity for team members to become familiar with the subtleties of personality and work style that may be difficult to convey through electronic communication. Personal interactions in informal settings are also seen as advantageous to establishing trusting relationships. Organizations such as Chevron have learned that valuable team-building can occur outside normal business hours and settings (Allee, 1998).

Face-to-face meetings among team members are not always possible. In reaction to a crisis event, teams may be formed and required to react very quickly. Time for face-to-face meetings to build personal relationships may be an unaffordable luxury. However, there is evidence that trust can be established and maintained solely through virtual interactions. Trust that is formed through computer-mediated communications is termed swift trust (Jarvenpaa et al., 1998). Swift trust is based primarily on professional reputation. This assumption of trust is very fragile and can erode quickly if not reinforced by action during the initial communication among virtual team members. Communication behaviors important for sustaining this initial trust include predictable communication, substantive and timely responses to requests for information, leadership, transition from focus on procedural issues to task execution, and effective strategies for handling team conflict and crisis operations.

The foundation for swift trust may not be present for all teams. Existing conflict among organizations or individuals creates challenges to establishing trust for any team, but it likely prohibits the ability to establish trust solely through computer-mediated communications. Organizations such as SGI have learned that installation of technology to support virtual team communications will not repair bad relationships (SGI, 1996). If trust issues exist among potential team members, these issues must be openly addressed before collaboration tools can be used effectively.

As groupware systems continue to mature, especially the quality of VTC systems, they may provide enhanced resolution of the subtle communication cues that are so important for establishing trusting relationships. Researchers have also hypothesized that, as the general population becomes more familiar with computer-mediated communication, users may learn to better articulate the cues important for establishing trust (McMahan, 1998).

3.4.2 IC Issues

This study identified a number of issues that contribute to a widespread lack of trust across the IC. First, there is concern that users of community networks do not comply with the security regulations defined for those networks. Each violation of security regulations significantly erodes trust among community members. Another factor impacting trust within the IC is the differing personnel clearance processes implemented across the organizations. A perception held within CIA is that personnel who do not undergo a full polygraph cannot be trusted to the same degree as those who receive a less stringent security screening, even though these individuals are issued the same clearance level. There is also a general attitude in CIA that human intelligence (HUMINT) secret data requires a higher level of protection than other secret data.

A lack of understanding of each others' organizational mission, structure, and operating restrictions also contributes to the lack of trust across the community. In some cases, the issue really is not a fundamental lack of trust but a failure to understand regulations that limit the exchange of information. For example, many in the community described the FBI as more of a taker than a giver of information. However, restrictions on the release of case-sensitive information and rules of discovery significantly limit the amount of information exchange that can occur between FBI and the rest of the community.

Rules of discovery refers to the use of information in legal proceedings. This is an issue for interagency collaboration because information accessible to law enforcement personnel (e.g., FBI, Drug Enforcement Agency) on IC networks may be subject to rules of discovery and, therefore, allowable for use in legal proceedings. There is no single definition of rules of discovery within the IC. Because of the issues of data classification and national security interests, the definition is usually established via a memorandum of understanding (MOU) or memorandum of agreement (MOA). The lack of understanding on this issue creates a tendency among some to be wary of sharing intelligence data with law enforcement entities.

There also is a lack of trust in the collaboration networks themselves. Agencies tend to distrust networks that are not administered by their own organization, preferring to maintain control over data and user access. Many also perceive electronic data as more vulnerable to espionage than hardcopy information. The compromise of a network or even an individual database is perceived as providing easier and quicker access to a much greater volume of information.

A fundamental issue impacting the trust associated with IC collaboration networks is the disparate perspectives and implementation of need-to-know principles. DOD organizations that have a mission to support the warfighter generally interpret need-to-know more liberally than national Agencies whose primary customers are policymakers. DIA, NIMA, and the service intelligence centers call for broad data access and argue that forces in the field have an overriding need-to-know. These organizations also believe it is difficult to establish true need-to-know and that quick response to fast-moving crises requires DOD analysts and warfighters to have timely access to a wide range of information. DIA suggests the community move to a concept of "OK-to-know" vice the current paradigm that burdens the information source and consumer to validate need-to-know. On the other end of the need-to-know spectrum, CIA, State/INR, NSA, and FBI all emphasized the importance of strictly controlling sensitive information. There is also concern among these Agencies that the move to information pull vice push capabilities acquired through web-based systems such as Intelink puts too much information in too many hands. Web technology is seen as changing need-to-know judgments from a case-by-case bases to a broad access decision.

All organizations agreed that over-classification of data and too many security levels unnecessarily complicate need-to-know determinations. DIA, DOE, and the service intelligence centers suggested that tear-line or multilevel security reporting be used as a method for stripping out sensitive information to allow broader distribution of intelligence. However, some study participants expressed concern that personnel resources are not available to produce tear-line reports.

The IC perceives CIA/DO as the most rigid in their interpretation of need-to-know. However, all organizations strictly control their most sensitive data. There is also a perception within the community that organizations apply stricter criteria for handling their own data than they follow when handling others' data. This perception has a significant impact on the level of trust across organizations.

The extent to which trust is a significant impediment to IC collaboration is perhaps best summarized by DIA's characterization of the lack of trust within the community as widespread paranoia that is a direct assault to DIA's mission.

 

Impact of the lack of trust across the IC is that sensitive data holders may hesitate or refuse to place their data on community networks.

3.4.3 Strategies for Success

Trust begins with the formation of personal working relationships. Senior IC managers and analysts agreed that expanding the knowledge of each other's organizational mission, structure, and processes will greatly enhance the community's ability to draw from its widespread capabilities and expertise. Many senior managers interviewed for the study recommended expansion of rotational assignments and community-level training as mechanisms for extending an informal network of personal contacts throughout the community. These activities also allow analysts to gain a better appreciation of what each organization can bring to the table, as well as the constraints under which each organization must operate.

Whenever possible, the time and resource investment to bring virtual team members together for at least an initial kick-off meeting is recommended. As discussed in more detail in a later section of this report, training sessions provide an ideal opportunity for a face-to-face kick-off meeting. Face-to-face meetings also should be scheduled periodically throughout the life of the team to sustain trusting relationships.

Effective use of groupware in an IC culture dominated by need-to-know accesses requires a balance between information security and the need to rapidly acquire and disseminate time-sensitive information. For many, the spirit of collaboration involves the free flow of information that draws input from nontraditional sources that, in turn, sparks innovative thinking and produces more comprehensive products. This philosophy, however, is in direct opposition to the IC's need-to-know culture that limits information to as small a group as absolutely necessary.

One solution to the need-to-know issues surrounding collaboration is the introduction of secure communities of interest (COIs) under the CIA's XLink program. XLink supports interagency collaboration within a TS/SI/TK environment among designated members with confirmed need-to-know. There is also the capability to have sub-COIs within the system to further restrict data access. Proponents of secure COIs cite the protection they provide in terms of counterintelligence and operational security. However, many in the community express concern over the proliferation of COIs. DOD organizations who seek broader information access perceived secure COIs as a rigid, exclusive concept that results in the automation of existing stovepipes. These automated stovepipes are viewed as negating the potential benefits of rapid and wide dissemination offered through collaboration networks. NSA and NIMA expressed concern that their participation in COIs was specifically problematic for their role as combat support agencies. There was also concern that, as COIs increase in number, the resources required to monitor and feed multiple, separate systems may become overwhelming. Any single analyst may be a member of multiple COIs and may be required to duplicate and update data across these COIs.

Most study participants acknowledged that there will always be a need to restrict access to highly sensitive data. However, those who expressed reservations about secure COIs believe that this approach is automating the IC's 1950s management philosophy and does not address the need for an underlying change in the way the community conducts business. The challenge in the community is to define the appropriate role of COIs vice system-high networks to meet the community's collaboration goals. Clear rules of engagement should be defined to facilitate trust among collaboration partners. The following section addresses areas where rules of engagement pose specific challenges for the IC.

 

Trusting Working Relationships Expand cross-organizational knowledge of mission, structure, and processes through rotational assignments and community-level training. Invest in face-to-face interactions among team members, when possible, especially during the initial stages of team formation. Define clear rules of engagement for collaboration.

3.5 Rules of Engagement

3.5.1 Lessons From Industry and Academia

Rules of engagement refer to the procedures and regulations by which team members are expected to abide in their use of groupware tools. These rules can encompass a wide range of activities, including the type and frequency of communications expected among team members, command and control procedures, and classification level of data approved for the system. Clearly specifying these rules prior to system deployment defines initial ground rules for system use that can significantly enhance the level of trust among users, as well as the comfort level with the system itself. Lack of clearly defined rules of engagement often leads to confusion that can inhibit effective application of the tools. Rules of engagement are especially critical for teams that have not previously worked together or when issues related to trust have been identified. (Harrington-Mackin, 1994).

Rules of engagement should include user protocols for logging in, checking information, and responding to requests for information. Research has shown that response times to online communications is a critical element affecting trust among virtual teams (Jarvenpaa & Leidner, 1998). In face-to-face interactions, individuals generally receive immediate feedback that their communication has at least been heard, if not responded to. Long delays between communications in a virtual environment can significantly erode trust among team members.

Documenting team rules of engagement is important, especially when team membership is fluid. The cohesion and momentum of a team can be significantly disrupted with the addition of new members. Companies such as Hewlett Packard and Lotus have found that documentation of team goals and rules of engagement, along with an historical record of team decisions and accomplishments, can help ease the transition of new members into team activities (Geber, 1995).

3.5.2 IC Issues

IC issues related to rules of engagement identified during this study include risk management policy, command and control procedures, and data ownership and attribution.

3.5.2.1 Risk Management Policy

The need for the community to move from the traditional practice of risk avoidance to one of risk management is a critical step to reap the benefits of interagency collaboration. Other studies, such as the Intelligence Community Task Force on Improved Collateral Support Final Report (June, 1998), cited the importance of a community-wide risk management plan. Currently, risk management is not consistently defined or implemented across the IC. While users may wish to work under a risk management paradigm, the lack of clear guidelines on what risk management means often results in users taking the cautious approach and reverting to risk avoidance procedures.

 

Risk management without clear guidelines quickly reverts to risk avoidance behaviors.                          (IC Task Force on Improved Collateral Support, 1998)

3.5.2.2 Command and Control Procedures

Electronic collaboration tools flatten communication channels. Many managers perceive these flattened communication channels as undermining command and control procedures. Although the telephone currently provides a mechanism for direct communication, electronic media is viewed as democratizing communication. Individuals may be more likely to send an e-mail or post an item to a discussion database than they are to pick up the phone and call an individual that is several steps removed from them through hierarchical or organizational lines. Posting information in public domains also provides the ability to reach a large number of people quickly, easily crossing organizational and hierarchical boundaries.

Many IC managers are concerned that informal collaboration that occurs over community networks will be used to circumvent formal tasking and dissemination mechanisms. IC managers also expressed concern over the appropriateness of informal communications that may occur across organizational and hierarchical lines. There is also a concern that informal communication between analysts and decisionmakers may result in action being taken on preliminary, unvetted intelligence.

Another command and control issue associated with collaboration systems is resource management. In a collaborative environment where customers, analysts, and collectors participate in interactive information exchanges, managers' abilities to monitor and control task assignments and priorities may become more difficult. In addition, the ease with which the community can be tasked may significantly affect the volume of requests, resulting in a change in analysts' and collectors' workloads. While the goal of collaboration in many cases is to identify available resources quickly, thus reducing workload, requirements for incorporating input from varied sources can also serve to increase workload. The resource expenditure associated with soliciting input, incorporating varied sources of data, and resolving disparate analysis can be extensive.

In addition to managerial command and control pressures, individual analysts may be resistant to relinquish control over their work by posting draft products for community access, review, and input. While the goal of a collaboration system may be for analysts to post a draft product to receive input prior to its formal release, analysts expressed concern that they will receive criticism on the quality of draft work. Analysts, therefore, may wait until they feel that the document is complete prior to posting.

What constitutes a product in a collaborative environment may also pose problems for traditional command and control structures. Traditional IC products include papers, briefings, and cables. However, many believe that a culture oriented toward the production of such stylized documents is incompatible with the future goals of the IC. These individuals believe that the focus of the IC should be on the rapid movement of information that can be easily tailored to individual customer requirements.

In a collaborative environment, mechanisms for communicating information can become less structured than traditional stylized products. For example, information from e-mail and interactive discussions may become policymakers' primary source of information. While this promises more timely and responsive information, these informal information exchanges are not compatible with the formal review processes in place in many organizations where information is reviewed up the chain of command before it is released. Currently, the community appears to have a greater comfort level with the use of collaboration networks to disseminate approved, vetted intelligence rather than support the exchange of tacit knowledge to assist in the creation of formal documents.

 

Restrictive command and control procedures affect the timely release of highly perishable information.

3.5.2.3 Data and Product Ownership

Ownership of data and products may become a significant issue in collaborative systems. Knowledge is frequently perceived as power, and turf battles can easily arise between and within organizations. As information is more freely exchanged in collaborative systems, traditional practices governing data ownership and attribution may not apply. Guidelines for establishing ownership of collaborative products and rules governing data ownership may need to be clarified. In general, ownership issues were perceived as more of an issue at the analyst, rather than organizational, level. Mechanisms are needed to ensure analysts receive recognition for their contributions to collaborative efforts.

3.5.3 Strategies for Success

All levels of users should be involved in the process of defining rules of engagement. Often this process involves negotiation, but buy-in from all users on the final set of rules is critical. Most rules of engagement are defined at the individual team level. These rules should include the process for initiating and sustaining collaboration to meet agreed upon goals. User protocols for logging in, checking e-mail, and responding to requests for information are important for establishing the level of user commitment to the system.

It is important to balance guidance with the flexibility to allow users to evolve usage of the system. Overly restrictive rules can significantly inhibit the potential benefits of collaboration systems. Rules of engagement for groupware system also should be compatible with existing work protocols. Trade-offs between the benefits of introducing new work paradigms and the difficulties that users will face trying to accommodate conflicting modes of operations should be examined closely (Jones, 1995).

At a community level, IC management needs to define clear policies governing risk management practices on collaboration systems. The sensitivity and handling matrix that defines security requirements for six levels of IC data provides a strong basis for such a mitigation strategy. However, this matrix addresses only report dissemination issues. The next step should be policies addressing the more free-flowing exchange of tacit knowledge that can occur within collaboration systems.

 

Clear Rules of Engagement Define community-wide security and risk mitigation policies. Define the process for initiating and sustaining collaboration to meet goals. Outline user protocols for logging in, checking e-mail, responding to requests, etc. Establish guidelines for data/product ownership and attribution. Ensure user guidelines allow flexibility to evolve with system use.

3.6 Mutual Benefit

3.6.1 Lessons From Industry and Academia

The disparity between the perceived benefits of participating in collaboration systems and the burden placed on users to effectively support the system has been found to be a leading cause of groupware failure (Bullen & Bennett, 1990; Grudin, 1988). Feeding, updating, and monitoring information that resides on collaborative networks can be very labor intensive. If users do not perceive a direct benefit to themselves or their organization for this resource expenditure, they probably will not make the investment. Therefore, it is critical to understand whether all users buy in to the value of their participation on the system.

The early failure of group calendaring tools is a good example of tools that require more effort than perceived benefit. A 1991 survey found that electronic calendars were believed to be the most readily available groupware tool but the least likely to have a significant impact in the workplace (Butterfield et al., 1993). Managers are generally seen as receiving the greatest benefit from group calendars, while staff are encumbered to diligently maintain their schedules on these calendars (Grudin, 1988). Additional problems cited with group calendars are hesitance to record personal time commitments and the reluctance of users to allow the tool to automatically schedule their free time. Difficulty transporting information from electronic calendars is also a barrier to their adoption.

Recent success in the use of group calendaring tools has been observed in organizational settings that originally rejected the technology. Increased use of electronic calendars at Microsoft and Sun has been attributed to improved tool functionality and user interface designs. Peer pressure has also been noted as a significant factor influencing increased usage (Grudin & Palen, 1995).

In comparison to group calendaring, e-mail and electronic bulletin boards have quickly gained widespread acceptance due to the equitable division of workload and benefit offered by these tools (Grudin, 1988). With minimal effort, users can reach a large number of individuals and receive a quick return on their effort.

Perceived mutual benefit is especially important to the success of groupware since the effectiveness of these tools is generally dependent on the participation of all users. One person's use and acquired benefit of the system requires that others use the system in a designated manner. Often the users whose participation is the most critical for success are the least likely to participate. This interdependence is especially problematic for systems that are intended to help novices get information from experts. Experts are likely to perceive little benefit to themselves for participating in such systems (Markus & Connolly, 1990).

3.6.2 IC Issues

Several issues related to perceived mutual benefit for participating in community collaboration systems were identified in this study. Some senior analysts perceived limited benefit to themselves for participating in community collaborations. Due to their senior status in the community, these analysts expressed concern that they would be overburdened by requests for information from junior analysts in other organizations. Therefore, some senior analysts are hesitant to participate in community networks.

There was also a perception that not all IC organizations are perceived as equal partners. NIMA perceived a reluctance of other IC organizations to accept them as a full partner in analysis and production efforts. FBI was viewed as more of a taker of information rather than a giver of information. As discussed earlier, this perception of FBI is rooted in the reality of restrictions on the release of case-sensitive information.

Intelligence organizations vary significantly in the degree to which they are dependent on others' data to meet their mission. Larger organizations with easy access to intelligence data, such as CIA/DI, are more self-sufficient than the small service intelligence centers who are highly dependent on the information from other organizations. Therefore, it was generally agreed that the smaller organizations could benefit the most from community collaboration systems.

 

Lack of perceived mutual benefit results in varying degrees of user buy-in and, thus, limits participation in collaboration systems.

3.6.3 Strategies for Success

A key strategy for the successful implementation of groupware is to provide a direct benefit to all users. This may involve building in additional features to reduce the workload associated with particular tasks or increasing the value-added provided by the tool (Grudin, 1988). Equality of benefit and workload across all users may not be possible to achieve. In these cases, it is important for management to recognize and reward those individuals who contribute extra work for the benefit of others. It is also important to periodically reassess the burden/benefit ratio associated with the use of groupware. Unexpected inequities in effort expended vice benefit received may be manifested after system deployment or evolve over time with system use (Roger, 1994).

 

Ensuring Mutual Benefit Strive for balance between perceived effort and benefit. Identify inequities in workload vice benefit. Eliminate/minimize unequal workloads. Build in extra features to accommodate user needs. Reward users who contribute extra work for collective benefit. Periodically reassess burden/benefit ratio.

3.7 Management Support

3.7.1 Lessons From Industry and Academia

Studies have shown that collaboration efforts are more successful in organizations when management is actively involved in the decision to invest in groupware (D'Souza, 1997; Essler, 1995). Not only must management support collaboration efforts but they also must communicate that support to all ranks of the organization. A 1997 Ernst & Young survey of corporate executives cited management's failure to communicate the importance of information sharing as a major impediment to the effective use of groupware systems.

Some argue that the success of groupware is dependent on management mandating the use of these tools (Markus & Connolly, 1990). Companies such as Buckman Labs (Buckman, 1997) have achieved widespread use of groupware by establishing usage guidelines and regularly monitoring employee participation. Others have seen success without mandated use from management. These collaborations have grown through grassroot support and peer pressure (Grudin & Palen, 1995; Orlikowski, 1992). Chevron management believes that the true benefits of collaboration cannot be pushed but rather needs to be nurtured (Allee, 1998). Users have to perceive real value to initiate and sustain quality collaboration efforts.

3.7.2 IC Issues

Middle management is generally perceived as the greatest barrier in the management chain to IC collaboration. Middle managers are seen as the most resistant to change and the most likely to feel threatened by flattening communication hierarchies that can be achieved through electronic collaboration. There is also concern over the lack of communication down through the management chain to the analyst level. Analysts report being uninformed of the goals for community collaboration systems and how these systems fit into their existing work processes and priorities.

3.7.3 Strategies for Success

Garnering management support for collaboration tasks and the groupware systems to support those tasks should occur early in the planning phase when the initial goals of the collaboration efforts are being defined. Support should be obtained from all levels of management. It is also important to identify a management champion for the project. This individual can broker support from their colleagues.

As previously discussed, it is not enough to simply acquire management support. Managers must communicate this support to all levels of the organization. Managers should communicate the goals for the collaboration effort, the level of organizational commitment to ensure success of the project, and the priority of the project within the context of the day-to-day responsibilities of the analysts participating in the collaboration. Managers can best communicate their support for a project through involvement. Training provides an excellent opportunity for managers to communicate organizational commitment and priorities to collaboration. It is recommended that representatives from management kick off each training session to communicate their support for the project. Managers can also communicate support through their use of the groupware systems. Finally, one of the strongest tools that managers can use to declare their support is recognition of collaboration successes.

Management support includes a commitment to resources, both personnel and financial. Project planning most always includes a resource plan for system development and deployment, including training. However, the success of groupware requires a continuing resources commitment for operational support, specifically content management and system evolution.

 

Management Support for Collaboration Communicate goals, commitment, and priorities. Commit resources. Demonstrate involvement. Acknowledge successes.

3.8 Recognition and Rewards

3.8.1 Lessons From Industry and Academia

A key component of an organization's culture is the behavior that it values and rewards in its workers. Many of the difficulties associated with effective groupware implementation are rooted in corporate reward structures that do not reinforce collaboration. If existing organizational reward structures focus on individual performance, specialized expertise, or information access, it may be difficult for workers to justify their participation in collaboration systems. The incongruence between reward structures and collaboration goals creates a tug of war that frequently contributes to the failure of groupware (Figure 4).

In a study of the implementation of groupware into several large organizations, a key reason why the systems were not used extensively was the perceived incompatibility between the collaborative nature of the tools and the competitive nature of the organizations. In these competitive corporate environments, collaborative behaviors were perceived as a threat to individual power, status, and distinctive competence (Orlikowski & Hofman, 1997). The organizations failed to adjust their reward systems to match new collaborative goals. In another study of the implementation of Lotus Notes groupware into a large consulting firm, senior staff and partners who had seniority and job security were more willing to use groupware to share information than junior staff members trying to establish their individual reputations in the company (Orlikowski, 1992).

Organizations who have successfully implemented groupware have established reward programs that promote knowledge sharing. For example, the Big Six consulting firms have supported groupware use by emphasizing the importance of employees contributing knowledge to a shared environment. Sun Microsystems has also achieved success in its collaboration initiatives by providing recognition and financial incentives for teamwork (Lipnack & Stamps, 1997). One such incentive was in the form of a contest sponsored by management that rewarded the best-formed and functioning teams. After evaluation, winning teams were rewarded with leisure travel at the company's expense. Chevron believes that the power of rewards is much stronger than the draw of the technology on its own. They have found that the proper emphasis on teams and information sharing will lead groups to collaborate, regardless of the tools available to those teams (Allee, 1998).

3.8.2 IC Issues

Traditionally, IC analysts have been recognized and rewarded for possessing unique and specialized expertise in their field. This status is generally achieved through outstanding individual performance and is often based on the ability to access, filter, and interpret data. This reward culture may be in opposition to the goals of collaboration that encourage teamwork and information sharing.

3.8.3 Strategies for Success

The process of aligning organizational recognition and reward systems with collaboration goals begins with a detailed understanding of the existing corporate reward culture. This understanding goes beyond specific items on a performance review form and should be considered the core values of an organization. Both formal and informal recognition and reward systems influence organizational behaviors. As with other aspects of organizational change, small steps may be required to reach the final objective. Instituting a reward system that is a radical change from the existing culture and practice may create more conflict than evolution.

It is important for evaluation and reward systems to be aligned within an organization. The priority of behaviors and outcomes against which workers will be evaluated needs to be clearly communicated. Evaluation of collaborative behaviors in a performance review will not carry much weight unless the individual is rewarded for those behaviors. Individuals will work hardest on the tasks for which they receive the greatest reward.

Reward systems supporting collaborative behaviors should focus on team, rather than individual, performance. Team rewards, however, are not without their challenges. Even within a team, there will be varying degrees of participation and value-added on the part of individuals to the collective goal. Timing of rewards is also important. It is best to provide rewards concurrent with team accomplishments rather than on an annual basis. This does not mean rescheduling formal annual reviews but rather supplementing these reviews with more timely acknowledgment of collaboration successes (Harrington-Mackin, 1994).

 

Team Rewards Ensure congruence with organizational culture. Align evaluation and reward systems. Focus on team, rather than individual, accomplishments. Distribute concurrent with accomplishments.

3.9 Training

3.9.1 Lessons From Industry and Academia

Training is one of the easiest ways to bolster the success of groupware. An organization's approach to groupware training can have a significant impact on the extent to which groupware is used to support collaboration activities. The most successful programs are those that address business process issues as well as tool functionality (Dennis et al., 1998). A survey of 25 organizations implementing groupware tools found that training programs focusing exclusively on the mechanical operation of the tools were insufficient to support collaboration behaviors (Bullen & Bennett, 1990).

Groupware is successful only when users understand how the technology can support collaboration (Vandenbosch & Ginzberg, 1996). This means providing users a context for the use of the tools. Training programs should begin with the targeted goals for the system as well as the specific process, roles, and responsibilities required to meet those goals. It is during this initial introduction to a system that users form lasting impressions. Training is, in fact, a mechanism to market the tool to users. Without users' buy-in to the potential value of the tools, their participation—which is the very essence of groupware—is unlikely.

In the absence of specific guidance on the purpose of groupware, users are left on their own to discover productive applications for the technology (Orlikowski, 1992). Unfortunately, in organizations where the culture and practice of collaboration is not the norm, users often apply groupware tools to increase their own productivity rather than engage in collaborative activities. A case study of a large US insurance company found that, after implementing Lotus Notes and providing minimal training on system operations, little change was observed in the amount of collaboration among workers. Employees who collaborated prior to introduction of the tool continued to do so, but the simple introduction of the tool did not change the behaviors of those who did not collaborate as a matter of course. The company falsely assumed that workers would independently learn how to use the tools to enhance collaboration (Vandenbosch & Ginzberg, 1996).

Organizational support for groupware and collaboration goals is best communicated directly by management during training. While contractor or vendor trainers may be able to address system functionality, organizations such as Ernst & Young have learned that company outsiders do not effectively communicate business objectives or integration of new tools into existing work practices (Clark et al., 1997).

Training for groupware tools may also need to include instruction on effective collaboration skills. This is especially critical for users who do not typically work in teams. Training on communication and team skills is cited as a major contributor to the success of groupware at the Big Six consulting firms (Clark et al., 1997). Generally, the same skills for effective team membership and leadership apply regardless of whether the team is meeting face-to-face or virtually. However, there are some unique skills and user protocols associated with efficient online communications. Often these protocols are driven by the specific groupware tools in use.

A significant challenge associated with groupware training is the instruction of remote users. Groupware is typically employed to facilitate communication among users separated by location. The logistics and costs associated with bringing the team together for face-to-face training can be significant. However, it is highly recommended that the investment be made for face-to-face training. Computer-based training or use of the collaborative tools themselves to conduct training is not as effective as face-to-face training. Another potential challenge is the varying degree of computer sophistication that may exist among users. Lack of computer experience can significantly hinder the effectiveness of groupware and requires special attention during training efforts (D'Souza et al., 1997).

Finally, training needs to be considered a larger activity than instruction received during a single session. Companies such as SGI have learned that training support should be extended into the workers' environment (SGI, 1996). This includes online aids such as user guides and tutorials. It is also important that workers are allotted time to explore the use of the system. If tool "play time" is not available to increase users' comfort level with a new system, then the pressures associated with day-to-day work requirements will frequently lead workers back to the traditional methods with which they are familiar.

3.9.2 IC Issues

Managers and analysts interviewed for this study reported that in most cases they receive minimal, if any, training on newly deployed systems and software applications. When training is provided, it almost always focuses exclusively on system functionality. Rarely does the training address the overall goals of the system and how it should be integrated into existing workflows and priorities.

An example from the recent deployment of a community collaboration system illustrates a much too frequently observed scenario within the IC. Many of the analysts who attended training for this system reported that they had no idea why they were there except that management had told them to report. They had received little to no information on the purpose of the system from their management or elsewhere. The training focused solely on the technical operation of the software and failed to provide any guidance to users on integrating the tools into their work. Not surprisingly, usage of this system almost a year after its initial deployment has remained very low.

3.9.3 Strategies for Success

Effective training to accompany groupware deployment requires a well-planned, comprehensive approach that includes attention to the content, participants, and timing of the program. Training content issues include presentation of collaboration goals, outlining rules of engagement, and addressing effective team processes and skills. These elements provide a context for the use of groupware tools. Only after this foundation has been laid for collaboration should the training address the operation of specific groupware tools. Instruction on how to operate groupware should occur within the context of realistic scenarios. Scenarios provide a mechanism to demonstrate the potential business value of groupware in a context that is meaningful to the user group.

Managers or team leads are key participants in training. An active role in the conduct of training is an excellent way for management to communicate support for collaboration. The other key issue related to training participants is that groupware should be presented to functional teams. Presenting training to teams is essential for running realistic scenarios and allows the members to discuss teams goals and rules of engagement. Training as teams also provides an opportunity for the face-to-face contact so important to establishing trusting relationships.

A long delay between training and account activation can significantly erode the effectiveness of training. Ideally, users should have access to the system immediately following completion of training. It is also highly recommended that training be made a requirement for system access. Because online collaborations are group activities, collaboration will proceed as fast and effectively as the least proficient user of the system. Therefore, untrained users can have a devastating effect on the productivity of all users.

A comprehensive training program should define a strategy for supporting users' exploration of the system after deployment. Training should not be considered an isolated event that occurs within a formal classroom session. Rather, training should be an ongoing process. Procedures should be put in place to assist users in their exploration of the system when they leave the formal training session and return to their offices. Support for continuous training may take the form of online training documents or canned scenarios that users can walk through on their own or in conjunction with other users on the system. To avoid disruption of operational system use, it is highly recommended that a separate area be set up in the system for online training and system exploration.

 

Effective Groupware Training Outline specific goals for groupware. Communicate buy-in from all level of management. Address effective team processes and skills. Discuss rules of engagement for system use. Train functionality in the context of realistic scenarios. Train as a team. Closely couple training with system access. Support users' exploration of the system after deployment.

3.10 Critical Mass Usage

3.10.1 Lessons From Industry and Academia

Lack of critical mass is a major cause of groupware failure (D'Souza et al., 1997; Dennis et al., 1998; Orlikowski, 1995). Critical mass refers to the assemblage of a group of active users large enough for the system to be useful. As depicted in Figure 5, lack of critical mass is a cyclical problem. Low system use results in insufficient data and communication problems because the right people are not online. Incomplete data and communication links create frustration on the part of active users who often choose not to use the system further, thus, creating even lower system use and further data and communication problems (Hummel et al., 1996).

3.10.2 IC Issues

Many IC collaboration systems have been plagued by a lack of critical mass. If users log onto a system a couple of times and do not see any information of interest, they are unlikely to log on again. In many cases, individuals are hesitant to be the first participants in a system.

Deployment strategies for IC groupware systems often do not support critical mass usage. There is a tendency to deploy systems by organization rather than to support defined teams with a specific collaboration need. Therefore, in the initial stages of deployment, all the users may be from the same organization with little need to use the system for collaboration. Yet it is during these initial stages that users form impressions of the system that will be hard to overcome.

3.10.3 Strategies for Success

The best method for achieving critical mass is to deploy the system to a core set of users with a defined task. Management and designated facilitators with an active presence on the system can provide the leadership to encourage others' use of groupware tools. Preparation of data content can also help support critical mass usage. If the system has been preloaded with data that has been defined by users as relevant to their task rather than logging on to a clean slate waiting for their input, it may be easier for users to realize the potential value of the system. System training should also establish protocols for users logging on to check communication tools such as e-mail and discussion databases. For synchronous tools, this may require logging on at the beginning of the day and then staying logged on so that other users can initiate contact if desired.

It is also important to monitor system usage after the system has been deployed. Detailed usage statistics provide valuable information on who is using what aspects of the system. This information helps identify both strengths and weaknesses of the system. Efforts can then be targeted to provide additional incentives or facilitation for particular user groups or system functions.

 

Achieving Critical Mass Deploy to core community of users with defined task. Ensure active online presence by managers and facilitators. Define strategy for ensuring system use. Define process for monitoring system use.