By Timothy Butler and David Coleman

In this guest editorial we examine five models for collaboration that vary from barely interactive to intensely interactive. Granted the CS definition for collaboration requires some level of interaction by two or more people, and in the past we have said that reciprocal data access (such as you would find in a library or repository) is not collaboration, we have also said that technology, content and process are critical for any type of collaboration. This being the case we are expanding our definition of collaboration (slightly) to include content libraries as most of the vendors in this area have added collaborative functionality. In addition, content is often critical for  a collaborate interaction to occur…David Coleman

 Introduction:

Based on the experience of working with many different organizations we have been able to categorize the majority of collaborative environments to fit into one or more of five primary collaboration models:

• Library
• Solicitation
• Team
• Community
• Process Support

The goal of this article is to help you determine which model(s) of collaboration are important to your organization. Figure 1 (below) shows how each of these models relates to each other based on the size of the population that uses them and the level of interactivity. As you can see we go from the Library model, which is really reciprocal data/content that can be accessed by a large number of people and not really inter-active, to the Team and Process Support Models, which usually are used by smaller and more interactive groups of people. Each of the model types is explained in greater detail below.

Definitions and Use Examples:

Library : The simplest and perhaps most common model is Library. The Library model is characterized by:

• Provides reciprocal access to common content or data
• Content that typically lasts for a long time,
• Having many more consumers of content than there are writers,
• The content is managed by a small set of people, and
• There is little or no feedback to the content creators.
• The content is often used in asynchronous collaboration (but can be used in real time collaboration also)
• There is a sophisticated indexing and retrieval mechanism based on keywords, context or even metadata.
• Support version control and sorting based on author, date, or topic

This model is often called a “Repository,” but Library has a more active sense, a place where materials are being used frequently, whereas a Repository has implications of a warehouse, where items are held but are not directly nor frequently accessed. It can also be thought of as a “Broadcast” model since it shares the many of the characteristics of broadcast mediums such as radio. However, “Broadcast” connotes a more synchronous model, where information must be consumed in real time or be lost. Nonetheless, these alternate terms can be useful in describing this model to users.

Figure 2: The Evolution of Interaction

A common use of a Library is to distribute product material to a sales staff. Such a Library would contain brochures, data sheets, and other materials that are used as reference material by sales professionals. Data sheets typically last for months if not years, they are written by a small group and consumed by many more sales professionals, a few people control the content that is available, and it is a one-way distribution system. In Figure 2 (below) that shows the evolution of interaction, we see that the first figure is just interacting with the content that exemplifies the Library model.

 Solicitation : involves requests from a small set of requestors and multiple (it is hoped) responses from respondents. It is characterized by:

• More respondents than requestors, often a small number of requestors
• Responses are often hidden from other respondents,
• Respondents can ask questions of requestors, and
• Requests and responses are often moderated.
• Collaborative interaction is almost always asynchronous and through e-mail and/or web site
• Automatic notification to participants of new requests and responses is also common

All of the Request processes (e.g., Request For Proposal, Request For Quote) are examples of Solicitation. Requestors post requirements descriptions and respondents reply with their proposals, quotes, etc. In many such processes, the responses are hidden from other respondents but visible by the requestor. Standards associations use this model to solicit review comments on proposed standards. Surveys, where many people are asked to respond to a set of questions, are yet another example. In Figure 2 (above) this is the second model, where there is some interaction, but usually it is through the content, i.e. I post an RFP, you fill out the fields, if I have a question of a specific field I can e-mail you about it.

The Team model : is used to facilitate the activities of a team. Its characteristics (many of which are shared by teams in general) are:

• Members share a few common objectives
• Members have a shared stake in their success
• Members are often bound by the parameters of a project
• Members are interdependent
• Membership is tightly controlled
• Membership is relatively small (2-20)
• Most members both read and write content.
• There is a higher level of interactivity
• This model has many of the characteristics of an e-meeting (see the Guru's Corner in this issue of Inside Collaboration).
• Access and security are tight and often based on roles, groups, or projects
• New members can get up to speed by reading the group “history.”
• Content/document management and project management features such as: check-in/check-out, version control, task and issue management, and escalation are common.
• Co-editing, project dashboards and/or executive overviews are also common

A space for a product development team provides a common area for members to share ideas, ask questions, and post important team documents, such as specifications. Threaded discussions allow team members to work through problems and issues. Because teams work in both real-time and asynchronously, team tools support both types of interactions. This is the third part of the diagram in Figure 2 where team members are directly interacting with the content and with each other. In the first two models (Library and Solicitation) security is focused on the content and access to it. In team interactions this is also true, but security also needs to be focused on the interactions them selves as they can be as significant as the content.

 Community : A less common, but extremely powerful, model is Community. It is used to facilitate the activities of a community, such as a Community of Practice (CoP) or a Community of Interest (CoI). Its characteristics (many of which are shared by Communities of Practice/Interest) are:

• Members have common interest, affinity, or goal
• Members of the community are often self-grouping,
• Members seek to share information,
• Members seek to further their understanding of the practice or area of interest,
• Membership is loosely controlled,
• Membership must be relatively large to be self-sustaining (new content is always needed)
• Large communities are often moderated, facilitated or edited
• All members are encouraged to both read and write content, and
• Most members find value in just reading.
• Contributors are usually around 10% of the community population
• Most of the interactions are asynchronous, but over the last few years “chat” communities have sprung up that utilize IM as the interaction media instead of threaded discussions.
• Rules of engagement, or appropriate behaviors for the community are often well defined

A Community of Practice is organized around people who share a common discipline, such as Project Management. It is likely that many of the members also belong to Teams, but, in the Community, they are brought together by their shared interest in Project Management as a discipline, not as it pertains to a particular project.

Figure 3 illustrates the interplay between Team membership and Community membership. Yasmeen and Matt are both members of Team A. Yasmeen, as a Project Manager, is also a member of the Community for Project Managers, a place where she can share and learn with other Project Managers from other Teams. Matt, as a Developer, is also a member of the Community of Developers. Yasmeen, Heidi, and Dave come together in the Project Manager Community to discuss Project Management.

Figure 3. Team and Community Membership

Early online Communities were built with e-mail distribution lists. More current implementations draw on the added capabilities of threaded discussion systems. In addition, features such as search, unseen maps, moderation, and notification can be used to build a more robust and usable system, particularly as the Community grows in terms of members and content. Search allows for the retrieval of information that may be old and would be lost otherwise. Unseen maps allow members to quickly see what has been added (or changed) since their last visit. In active Communities, moderators monitor postings for quality, removing redundant entries, moving inappropriate (e.g., off topic, offensive, trivial) material offline from the community, and facilitating responses from known experts. E-mail notification has been shown to be a powerful tool in driving members to the Community, acting as a balance against pressing task-oriented activities. Communities are also a good example of the third type of interaction shown in Figure 2. For more on on-line or virtual communities see Inside Collaboration, August 2002: http://www.collaborate.com/publication/newsletter/publications_newsletter_august02.html .

Process Support : is the use of collaboration technologies in a process or workflow. Characteristics are:

• Frequently performed processes,
• Processes involve complexity or exceptions,
• Self-service status monitoring, and
• Is frequently used in conjunction with other models.
• Critical organizational processes that require collaboration include: new product development, sales/marketing, customer service and support, training, supply chain management
• The ability to generate customized forms that support the process is common. Issue resolution through these forms (in context) is also useful as the context is sharable.
• Often offers an overview of process progress to the process manager
• There is often an underlying workflow system that supports, in addition to manual state transitions, automated transitions based on activity or time, which is very valuable.
• Access control over transitions, viewing, and modifying allow for the creation of complex automated systems that address a wide range of applications.

The second bullet is what often makes this a ‘collaborative' model – the need to interact around a given process to handle complications. This follows Pareto's law or the 80/20 rule: 20% of resources go to support 80% of the (standard) interactions, while the other 80% of the resources go to support the 20% of the non-standard interactions (exceptions) which are more complex processes, where there is the need for clarification, rules arbitration, exception handling, etc, are well suited to this model.

Forms submission to Human Resources or Accounting use this model. Once a form, such as a vacation request, is submitted to the system, the submitter can track the state of the request without having to ask anyone in the processing organization for status updates.

A better example is that of a customer service representative faced with an irate customer that did not get their product shipment when promised or got the wrong product. The customer service representative can often look at a database or online form to see if/when and what was shipped. But the customer can often do that also, and it does not give any answers to why the customer got the wrong or late product. This is an exception to a standard support process and requires that the customer support representative talk to someone in shipping to find out what happened. If the person responsible for the shipment has initialed the online form and in available online, they can be contacted through IM by the customer service rep, who can find out where the mistake occurred, and work out a solution/resolution immediately with the irate customer.

The Value of Models

 We have defined some of the elementary building blocks of collaboration. Many of these models can be aggregated (used simultaneously, yet separately) or combined into hybrid models. For example, by combining the Library and Solicitation models an association can create a “best practices” library by soliciting feedback on each practice; as a result, those using the practices can make them that much more valuable (to others).

A framework for analyzing and designing collaborative systems can be built based on an understanding of the pure models and how they may be combined. For a given situation, an analysis of the requirements can produce a mapping to the available models, pure or combined. Then, by iterating through the models, additional opportunities for added value within the system can be found. Once a thorough understanding of the require-ments emerges, a design can piece together the components into a complete collaborative system.

Timothy Butler is the President/CEO of SiteScape, Inc. and founded SiteScape, Inc. in August of 1995 as a value-added reseller of Internet solutions. In 1999, he successfully negotiated the acquisition from Compaq Computer, Inc. of the award-winning AltaVista Forum collaboration software, as well as the engineering team that designed, developed and supported the product. Today the company focuses on providing collaboration software, customization and hosting services, and support to government agencies andGlobal 2000 and Fortune 500 companies. Timothy can be reached at: timothy.butler@sitescape.com

David Coleman is the Founder and Managing Director of Collaborative Strategies LLC (CS) and the editor of " Inside Collaboration ". CS is the leading analyst firm covering collaboration technologies and its use. Serving both vendors and end-users of these technologies, CS provides a variety of publications and services that help these populations in being more successful in selling or using collaboration technologies. Collaborative Strategies can be reached by e-mail at davidc@collaborate.com , or by telephone at 415/282-9197.

Collaborative Strategies makes every effort to bring you timely, accurate information on collaboration and knowledge management. However, we are part of a rapidly evolving market ourselves and events occur during the publication of this newsletter every month that we do not become aware of or that happen post-production. If you know of such events please contact us at davidc@collaborate.com so we can note these key events in the next edition of this newsletter.