• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Best Practices   How To Make Collaboration Work
 

Best Practices How To Make Collaboration Work

on

  • 10,025 views

 

Statistics

Views

Total Views
10,025
Views on SlideShare
10,006
Embed Views
19

Actions

Likes
4
Downloads
301
Comments
0

3 Embeds 19

http://www.slideshare.net 17
http://us-w1.rockmelt.com 1
https://davenport.blackboard.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Best Practices   How To Make Collaboration Work Best Practices How To Make Collaboration Work Presentation Transcript

    • © 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 © 2003 Giga Information Group, Inc. Page 2 of 11
    • Best Practices: How to Make Collaboration Work ♦ Daniel W. Rasmus 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. Planning Assumption ♦ RPA-032003-00011 ♦ www.gigaweb.com © 2003 Giga Information Group, Inc. Page 3 of 11
    • Best Practices: How to Make Collaboration Work ♦ Daniel W. Rasmus 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. Source: Giga Information Group 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), Planning Assumption ♦ RPA-032003-00011 ♦ www.gigaweb.com © 2003 Giga Information Group, Inc. Page 4 of 11
    • Best Practices: How to Make Collaboration Work ♦ Daniel W. Rasmus 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. Planning Assumption ♦ RPA-032003-00011 ♦ www.gigaweb.com © 2003 Giga Information Group, Inc. Page 5 of 11
    • Best Practices: How to Make Collaboration Work ♦ Daniel W. Rasmus 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 Source: Giga Information Group 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. Planning Assumption ♦ RPA-032003-00011 ♦ www.gigaweb.com © 2003 Giga Information Group, Inc. Page 6 of 11
    • Best Practices: How to Make Collaboration Work ♦ Daniel W. Rasmus 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. Source: Giga Information Group 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. Planning Assumption ♦ RPA-032003-00011 ♦ www.gigaweb.com © 2003 Giga Information Group, Inc. Page 7 of 11
    • Best Practices: How to Make Collaboration Work ♦ Daniel W. Rasmus 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. Planning Assumption ♦ RPA-032003-00011 ♦ www.gigaweb.com © 2003 Giga Information Group, Inc. Page 8 of 11
    • Best Practices: How to Make Collaboration Work ♦ Daniel W. Rasmus 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. Planning Assumption ♦ RPA-032003-00011 ♦ www.gigaweb.com © 2003 Giga Information Group, Inc. Page 9 of 11
    • Best Practices: How to Make Collaboration Work ♦ Daniel W. Rasmus 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 Source: Giga Information Group (Back to text) Planning Assumption ♦ RPA-032003-00011 ♦ www.gigaweb.com © 2003 Giga Information Group, Inc. Page 10 of 11
    • Best Practices: How to Make Collaboration Work ♦ Daniel W. Rasmus 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? Source: Giga Information Group (Back to text) Planning Assumption ♦ RPA-032003-00011 ♦ www.gigaweb.com © 2003 Giga Information Group, Inc. Page 11 of 11