Best Practices How To Make Collaboration Work

© 2003 Giga Information Group, Inc.
Copyright and Material Usage Guidelines
March 14, 2003

Best Practices: How to Make Collaboration Work
Daniel W. Rasmus

Giga Position
The success of collaboration requires three primary elements. The first and most important is a collaborative
culture that recognizes the value of collaboration and rewards those who model collaborative behavior. The
second is the establishment of a solid collaboration technology foundation that minimizes choices among
similar products but provides the widest range of channels to accommodate varying communication needs
within and between business processes. The third is the presence of processes for aligning investments with
the business, discovering collaborative opportunities, methodologies for modeling collaborative behavior, and
integration with planning, to provide perspectives and priorities for investments in collaborative work.

Recommendations
Organizations should undergo a collaborative discovery exercise for key strategic initiatives to understand the
collaborative opportunities and existing collaborative behaviors, including collaboration failures and
challenges. Investments in collaboration should be focused on the most highly valued and strategic
collaboration opportunities. Invest in trust. It does not matter if the collaboration is targeted at internal work,
or designed to increase value between trading partners — collaboration requires trust between the parties.
Trust is built over time through investment in relationships. Organizations that want to evolve from
collaboration as a tactic, to collaboration and knowledge transfer and retention as a strategic asset do so by
nurturing trusted relationships.

Collaboration requires recognition of the time required to collaborate and the need for appropriate motivation.
Successful collaboration efforts include incentives that reflect the value of collaboration to an organization.
Do not assume that any existing form of interaction is correct and cannot be improved. Examine the
opportunities available through enhanced processes, practice and technology to improve the value and
outcome of the interaction.

A modeling methodology should be used to maximize the opportunities in mission-critical collaborations. It
would be overkill to model all ad hoc collaborative behavior, but mission-critical collaborations can be more
effective when their tools, processes and outcomes are more highly orchestrated (a methodology for modeling
collaboration is illustrated below).

Organizations should create a rational technology environment that includes calendaring, messaging, single
collaboration directory supplemented, real-time collaboration, threaded discussions/forums,
workflow/process automation and mark-up and annotation. All technology choices must be made to support
clear business goals. The creation of a collaboration environment or the selection of tools without a clear
business need is an almost certain failure point for the technology related to collaboration.

Organizations must provide education and mentoring in core skills related to collaboration such as
facilitation, team building, mediation, conflict resolution, brainstorming, technology, internal policies and
ethics. During the next 18 months, collaboration will be an increasingly important element to watch within
the infrastructure, and a more prominent element of architectures, as it moves into components and services
and becomes ubiquitous as a feature/service within traditional applications and as a feature associated with
portals.

Planning Assumption ♦ Best Practices: How to Make Collaboration Work
RPA-032003-00011
© 2003 Giga Information Group, Inc. All rights reserved. Reproduction or redistribution in any form without the prior permission of Giga Information
Group is expressly prohibited. This information is provided on an “as is” basis and without express or implied warranties. Although this information is
believed to be accurate at the time of publication, Giga Information Group cannot and does not warrant the accuracy, completeness or suitability of this
information or that the information is correct. Giga research is provided as general background and is not intended as legal or financial advice. Giga
Information Group, Inc. cannot and does not provide legal or financial advice. Readers are advised to consult their attorney or qualified financial
advisor for legal and/or financial advice related to this information.

Best Practices: How to Make Collaboration Work ♦ Daniel W. Rasmus

Proof/Notes
Collaboration happens. Any time two or more people engage in a task, collaboration takes place.
Collaboration does not require technology. It can be entirely verbal and contain no record. But most
collaborative work is more sophisticated, including the exchange of ideas, comments on documents,
brainstorming on paper, whiteboards and computer screens and verbal interchanges facilitated by telephones
and videoconferencing systems. Collaboration requires technology for two reasons: to facilitate collaborative
interactions between individuals challenged by geographical distance and the associated issue of time zone
differences. The second reason for technology is the desire for artifacts that reflect not only the output of
collaboration but also to document the processes involved in the collaboration, the trade-offs considered and
the negotiating positions that influenced the final consensus.

To succeed at collaboration, organizations must first define collaboration and its success criteria, in terms that
represent the value of the organization. This is typically accomplished by aligning collaboration efforts with
business objectives. In this way, the metrics surrounding the effort are not artificial, but remain business
metrics, and therefore tie directly to the perceived value of the organization. People may collaborate on a
wide variety of areas outside of those aligned with strategic imperatives, and may produce results and returns,
but it is only when collaboration furthers the strategic goals of a business is its value seen as success from the
organizational perspective.

Executives and other leaders must actively engage in collaborative behaviors and collaboration-enabled
processes with which their roles interact. They should not, however, force themselves or collaborative
behavior on areas that are not ready, not targeted or not pursuing collaborative efforts.

Technology Planning and Architecture Policy Recommendations
Collaborative architectures should not be separate from enterprise architectures, but completely integrated
with them. As collaboration moves toward becoming a service (see Planning Assumption, Navigating the
Contextual Collaboration Market, Daniel W. Rasmus), the value of context will come from integrating
collaboration services with traditional transaction and line-of-business applications through clients, Web sites
and portals.

The basic collaboration architecture should include:

•= Calendaring
•= Messaging (e-mail, instant messaging, mail-based voting and surveys)
•= Directory supplemented presence/awareness
•= Real-time collaboration (application sharing, screen sharing, co-browsing, shared whiteboard,
brainstorming, voting, videoconferencing)
•= Threaded discussions/forums
•= Workflow/process automation
•= Mark-up and annotation
•= A core repository (document management, collaboration store, relational database, etc.)

Successful organizations should create a rational collaboration environment that minimizes the number of
instances of collaboration tools.

It should be noted that peer-to-peer and team environments are not listed because they both represent
alternative ways of packaging and delivering the features listed above. If at all possible, they should be

Planning Assumption ♦ RPA-032003-00011 ♦ www.gigaweb.com
Page 2 of 11


implemented as representations of core capabilities and exposed as services into a shared environment, rather
than as a stand-alone application with its own repository and functionality.

In order to leverage the artifacts of collaboration, organizations should also consider investing in the
following service components:

•= Search
•= Communication channel management
•= Semantic analysis
•= Statistical analysis
•= Feature extraction
•= Profiling
•= Tagging
•= Visualization
•= Alerts and notification
•= Competency discovery
•= Collaborative opportunity discovery

Figure 1: A Basic Architecture Overview

Functional Content
services and Real-Time analysis
client Markup/
Collaboration Services
Threaded Annotation
services
Discussions Search
Visualization Summarization Collaborative
Indexing Categorization/
Msging & Workflow
Competency Tagging Pattern
Channel Discovery
Alerts/ Recognition Calendar
Mgmt.
Notification Linguistic/ Shared
Meeting Semantic
Statistical Directory Repository
Support Analysis Analysis

Collaboration Profiles State
Meaning Cases
Store (Presence)

Competency Category
ECM E-learning
Context CM
Processes Digital
Assessment
Code Business RDBMS Management
Rules

Source: Giga Information Group

Figure 1, above, illustrates the layers of a collaboration architecture. Collaboration services, at the top, are
delivered through portals and clients, with information being filtered through a set of content analysis
services that create metadata to abstract and describe content available in a variety of repositories. Figure 2,
below, illustrates a more functional view of the relationship and flows between services in a collaboration
environment.

Page 3 of 11


Figure 2: Collaboration Architecture

External
Content Learning Business DW
Management Intelligence
Synchronous Services Services
Collaboration ETL
ETL
Services
Business
Portal Services Intelligent Applications
External Ext. Real- Content
IM Time Services Other
Repositories

Directory Services Content
Management
Document
Document Authoring,
Services
Collab.
Collab. Editing and
Asynchronous Assembly
Collaboration Services
Services Life-Cycle
Life-Cycle
Tasks &
Tasks & Management
Management
Process
Process
Collab.
Collab. Creativity
Ext. E-Mail External Process Services Services
Gateway Collab.


A detailed description of the architecture services described in Figure 2 can be seen in Table 1: Collaboration
Architecture Elements, at the end of this document and in a downloadable expanded PDF chart on GigaWeb
at http://www.gigaweb.com/lm.asp?p=/Content/Media/AdHoc/CollabArchitecture.pdf&t=1.

The components of a collaboration environment need not consist of stand-alone applications, but may be
implemented as services.

Create a solid set of collaborative services that fit within the existing technology architecture. The services
may add additional features, but they should minimize the introduction of repositories, protocols and other
items that may conflict with the enterprise architecture.

Collaboration technology selection should be highly constrained by the ability of any given solution to work
with existing repositories.

Exceptions to the use of horizontal collaboration tools (such as Domino, Microsoft Exchange, Novell
GroupWise and Oracle Collaboration Suite) must be made only when the vertical or niche area (such as
collaborative scheduling and collaborative product design) cannot adequately be supported by horizontal
tools. Specialized tools should not mean discarding all applications in favor of a new collaborative
environment, but should supplement horizontal tools as necessary to effectively find the value in the
collaborative relationship.

Interfaces to collaborative applications and services should be clearly defined so the features of the services
and the content they expose/create can be integrated with line-of-business and horizontal applications.

Focus protocols as much as possible on standards like Service Interaction Protocol (SIP), Simple Object
Access Protocol (SOAP), SIP for Instant Messaging and Presence Leveraging Extensions (SIMPLE),

Page 4 of 11


Extensible Markup Language (XML), etc. (see IdeaByte, Collaboration Standards and Why We Need Them,
Daniel W. Rasmus and IdeaByte, Standards Used by Team Collaboration Vendors Are Not Specific Enough,
Daniel W. Rasmus).

Use portals to bring information and tools together so those involved in collaborative work can focus on
adding value rather than mediating between content sources and collaborative tools.

Bring collaborative tools into processes as much as possible, away from stand-alone clients. This provides
context for the exchanges and directly relates the value of the interaction to the business process it supports.

Minimize collaboration product environments to maintain a highly effective workspace that does not confuse
employees and partners navigating though collaborative spaces. The answer to “where do I work for what”
should be clear. In the best case, views by context will be exposed as necessary, using the same set of basic
services and products. Requests for exceptions to this rule may come from small groups that request products
offering redundant features in a packages solutions (product life cycle management (PLM) and team
environments are two examples). This should be resisted in favor of designing environments that expose
basic core functionality through a portal. If the primary reason for introducing a new tool is packaging, cost
should be incurred to build a similar environment using standard services as much as possible, since the cost
of silo-ed information, navigation confusion and missed collaboration opportunities will likely outweigh the
costs of building a similar environment. This will become easier to accomplish as collaboration moves from a
client/server model to a services-based model during the next 24 months (see [PA/GIB], Evolving toward
Contextual Collaboration, Daniel W. Rasmus). As core products mature, environments will evolve from these
tools as is already evident in offerings like Lotus Team Workspaces (QuickPlace).

Understand culture and use tools that match the existing culture if possible. This does not imply multiple
products to fit all local needs, but an overriding understanding of culture that will be applied to tool selection.
(Hill & Knowlton, for instance, selected Intraspect for asynchronous collaboration and as its primary
collaboration store because it is a highly e-mail centric organization. Intraspect allows it to retain its culture
while adding advanced indexing, profiling, discussion threads and other features, including the ability to use
e-mail to query the collaboration store.)

All collaborative services should include the ability to enable appropriate security methods that fit the
particular form of interchange. At minimum, include logging, virus protection and authentication. Other
security facilities may include monitoring, real-time analysis and various forms of reporting and data mining
of logs.

A Methodology for Modeling Collaboration
No standard methodology exists for modeling collaborative interactions. The following section outlines a
basic methodology for depicting collaborative interactions, both ad hoc and those associated with
processes/work flows. The methodology endeavors to capture all critical elements necessary to inform those
designing and optimizing collaborations within an organization, so decisions can be made about items like
tool selection, architecture components and interaction redundancy. Figure 3 provides an example of a
collaborative interaction.

Page 5 of 11


Figure 3: Collaboration Modeling Methodology Graphics

The diagonal arrow
indicates the possibility
of an ad hoc
collaboration to support
this process step.
A rendering of the collaborative relationship. This image,
and the accompanying documentation, can be stand alone
to represent collaborations not associated with a process,
or used to document the decomposition of the collaborative
indicator arrow shown in the diagram above.

Supply Chain
Exception


For each collaborative interaction, specific items should be documented (as illustrated in Table 2:
Collaboration Documentation Elements, located at the end of this document). This should be done so the
diagram and the documentation are either on the same page, or closely related via a database or other method
of association.

It is important to use this type of methodology not only to define the interaction and supporting technology,
but also to create a document that works as a trigger for a collaborative dialog around the meaning, value and
content associated with the area being modeled.

Page 6 of 11


Figure 4: Collaboration Modeling Methodology and Follow-on

Consolidate
processes
Consolidate

Review Inventory Document Categorize Measure

Invest
Review strategic Document each Measure
goals and objectives collaboration using performance
and identify strategic the collaboration and improve
processes. metadata. collaboration
interactions
Create inventory of Categorize collaborations over time.
collaborations that (by type, business
support strategic purpose, relationships,
processes and those that roles, etc.) Look for Identify weaknesses
may support strategic synergies that will make and invest in the
goals and objectives individual collaboration collaborations that
without association with a more successful, or for require triage.
documented process. features that will allow for
consolidation at the
process level.


This methodology provides way of capturing the fundamental descriptors of a collaborative interaction.
Figure 4 describes a basic sequence of steps helpful in documenting and evaluating a collaborative
interaction. The success of a collaboration, however, cannot be determined solely through this
documentation. The intent should be to document as a way of understanding the scope of collaborations that
take place, and through the inventory, the number and types of collaborations that take place both internally
and between companies. As with all documentation efforts, this effort will be severely constrained by time,
and therefore the highest valued and most visible strategic collaboration should be targeted for the
documentation effort. In that way, efforts can be put into place to better clarify the collaborations and
agreements betweens two companies, and to reconcile behavioral styles between the parties and educate the
parties so these collaborations will have an increased likelihood of generating value to the process they intend
to support.

B2B Best Practices
Business-to-business (B2B) collaboration is becoming increasingly common. Simply applying tools to
connect enterprises is not sufficient. In terms of general collaboration, the following recommendations should
be adhered to:

•= Negotiate shared-risk clauses into partner and supplier contracts related to collaboration, along with
clear understandings of expectation and deliverables.
•= If B2B collaboration is expected to be part of a relationship, technology, security and process
alignment must be part of the negotiations and should be clearly understood by all parties.
•= If the collaboration uses specialized tools, such as collaborative supply chain planning, the tool
should not be considered broad enough to encompass all types of collaboration. The desire to
maintain the smallest portfolio of tools should continue to drive the architecture. Whenever
possible, use the same tool between firms that is used internally. This minimizes confusion and
enhances the potential value of not introducing an alternative infrastructure to maintain, and new
tools for end users to learn.

Page 7 of 11


Building Trust Across Organizations
Trust is a major barrier to successful collaboration. Mistrust is easier to foster than trust. Trust requires
investment in time and energy to be realized. The following five steps are a starting point for building trust
between individuals and organizations:

1. Make sure you have your own collaboration house in order: Collaboration takes time, and skills are
involved that are best brought to a new relationship rather than learned during the establishment
phase. Make sure that internal collaboration works and that the pipeline of communication is not
filled with tension because people on the inside are not getting along.
2. Hold a meeting: It may sound archaic to get people together, but trusted relationships are hard to
build online. People need to see each other, exchange stories and come to an agreement about
behavior. If it is not possible to get people together, the collaboration plan must include formal and
informal relationship-building time. For the formal portion, a professional facilitator can help get
people to explore/confront issues that might be trust-busters down the road. Better to get them out in
the open early and deal with them, than have them break the deal later.
3. Set clear policies during negotiations for what can and cannot be shared: Make it clear to both sides
so individuals know the other party is not just “holding something back.” Formal definitions protect
not only the trust relationship, but they also protect the individual by not forcing him or her to decide
in multiple circumstances if a piece of information should be shared or not.
4. Start collaborating: Set up a pilot, have people meet and start exchanging information and making
decisions through the collaboration environment. These early efforts will iron out issues with
technology, process and policy and pave the way for more expansive collaboration efforts in the
future. Make sure the business owners and information technology teams are in a state where they
can listen to and react to the pilot, or risk that the learning will not take hold.

Preparing People for Collaboration
The people involved in collaborative work must be educated in a number of skills and behavior areas in order
to succeed at collaboration. These areas include:

•= Facilitation
•= Team building
•= Mediation and conflict resolution
•= Brainstorming
•= Technology
•= Internal policies
•= Ethics

Create incentive programs that reward collaborative and team behavior. These incentive programs can be
simple recognition or awards based on team achievements, including monetary rewards. Each organization
must create programs that fit its culture and are proven motivators for the staff involved in the program.

Establish an environment that recognizers the upfront investments and allows teams and individuals involved
in collaborative interactions time or support to “storm-form-norm.”

Assign collaboration coaches to assist the introduction of new employee into mission-critical collaboration
situations.

Page 8 of 11


Create clear guidelines and set expectations for the role of technology, such as e-mail use and etiquette, and
best practices for video conferencing (see IdeaByte, Videoconferencing Best Practices, Daniel W. Rasmus
and IdeaByte, Develop an E-Mail Etiquette, Daniel W. Rasmus as examples).

One of the problems with the literature of collaboration is its insistence on being self referential.
Collaboration literature often points to improved collaboration as a desired outcome of investments in
collaboration. This same reasoning led to the demise of interest in knowledge management. Success
measurements associated with collaboration should all be stated in terms of tangible business results.

References
Related Giga Research
Planning Assumptions
Adaptive Workspaces: Preparing for the Future of Work, Daniel W. Rasmus
Evaluation Criteria: Competency Discovery, Daniel W. Rasmus
Managing the Document Life Cycle Starts with Collaboration, Robert Markham, Connie Moore and Erica
Rugullies
Navigating the Contextual Collaboration Market, Daniel W. Rasmus

IdeaBytes
Best Practices for Virtual Teams: More About Teams Than Technology, Daniel W. Rasmus
Building Effective Communities, Daniel W. Rasmus
Develop an E-Mail Etiquette, Daniel W. Rasmus
How to Tune a Virtual Organization, Daniel W. Rasmus
Is Your Organization Ready for Collaboration? Daniel W. Rasmus
Videoconferencing Best Practices, Daniel W. Rasmus

Glossary
Peer-to-peer collaboration: A collaboration tool or environment built on a distributed computing model
rather than a client/server model. Most peer-to-peer collaboration environments are not pure, but to those
involved, they offer a much more lightweight model of interaction (in terms of IT involvement and
administration) than traditional horizontal tools like Domino and Exchange, especially when interactions
involve parties across two or more companies.

Team environment: A collection of collaboration features, including a document repository, threaded
discussions, task assignment and other items built into a stand-alone environment used to facilitate the
asynchronous work of teams. Examples include IBM’s Lotus Team Workspaces (QuickPlace),
Documentum’s eRoom and Microsoft’s Team Services.

Page 9 of 11


Table 1: Collaboration Architecture Elements
Architecture Element Components
Synchronous
Whiteboard, chat, VoIP, application sharing, IM, meeting support
collaboration services
Directory services Authentication, user admin, awareness, profiling, authorization, competency
Asynchronous Discussion threads, communities, tasks, messaging, calendaring, content
collaboration services management
Learning management Course administration, student administration, testing, multimedia delivery, course
services catalog, performance tracking metrics
Portal services Customization navigation, visualization, interfaces/portlets

Document services Check-in, check-out, versioning, summarization, categorization, Web logs (blogs)

Process services Process modeling, workflow management, reporting
Alerts/notification, categorization/tagging, indexing, pattern recognition, profiling,
Intelligent content
summarization, competency discovery, linguistic/semantic analysis, statistical
services
analysis
Authoring, editing and Word processing, presentation, courseware, graphics, spreadsheets, Web sites, case
assembly services editor, audio, video, process modeling
Creativity services Idea prompting, questions bank, outlining, idea synthesis, voting

Business applications Customer relationship management (CRM), enterprise resource planning (ERP), etc.
Collab store, enterprise content management (ECM), processes, cases, e-learning
Other repositories content management (CM), digital asset management (DAM), business rules, other
RDBMS, code
(Back to text)

Page 10 of 11


Table 2: Collaboration Documentation Elements
Element Description

Name Give the collaboration a unique name.

Role Describe the players, their roles and their organizational placement.

Organization

Relationship Identify the type of collaborative relationships: Customer, partner, internal or supplier.
Describe the reason(s) the collaboration takes place: Communications, learning,
Reason
coordination, decision-making (business purpose).
Data Describe what data initiates the collaboration or supports its outcomes.
Identify documents affected by or integrated with the collaboration. Include any notes
Documents about content organization, life cycle or format that would affect the ability to facilitate
the collaboration or generate a desired outcome.
Content Organization
Process and
Describe process and exceptions affected by or integrated with the collaboration.
exceptions
Repositories List repositories involved in the collaboration (sources and destinations).
Detail the extent of the reach of the collaboration (process, physical sites, other
Extent
organizations, participants, mobility, etc.).
Applications List applications used in the creation or review of the original content.
List devices involved (build a library of device capabilities as new devices are
Devices
discovered).
Integration points Recognize integration points with line-of-business and other transaction systems.
Identify business metrics that might be effected by an increase in frequency or quality
Business metrics of collaboration, including casual relationships that will link the performance of the
collaboration to the business metrics.
Create incentives to support and encourage collaborative behavior in relationship to
Incentives
this collaboration.
Arrive at formal agreements directly related to this collaboration and the parties
Formal agreements
involved in the collaboration.
Agree on social norms and other social elements related to the collaborations. Include
Social norms
items like meeting practices and management style.
Describe how long this collaboration (or similar collaborations) will be (for instance,
Maturity the same type of relationship, but with another company — tools use in different
circumstances do not count).
Document how lessons learned should be captured from the collaboration interaction
Lessons learned — what are the process feedback loops that support improving this collaborative
interaction?
(Back to text)

Page 11 of 11

Best Practices How To Make Collaboration Work

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Best Practices How To Make Collaboration Work

Ähnlich wie Best Practices How To Make Collaboration Work (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Best Practices How To Make Collaboration Work