Resource Center

Collaboration Software: A Buyer's Guide

By Daniel W. Rasmus, Industry Analyst and Strategist

Buyer’s Guide Intent

Collaboration Software: A Buyer’s Guide is intended to help those seeking to acquire all or part of a small business or enterprise collaboration solution to understand how to define their expectations, specify requirements, evaluate products and services, and work effectively with vendors.

Although this Buyer’s Guide mentions adoption and deployment, it does so only in light of evaluation experiences, or preparation for those evaluation experiences. No guidance is provided about adoption or deployment.

The Buying Process: An Overview

Collaboration Design

How valuable collaboration investments become depends on the individual organization and its perspective toward technology. Those organizations that acquire collaboration software in order to facilitate existing processes will not realize as much value from their collaboration technology as those who rethink existing practice in light of new capabilities.

A good collaboration design begins with determining the scope of collaboration. Some evaluation criteria suggest a purpose be the starting point, but collaboration is highly distributed, and the tools, techniques and expected outcomes vary greatly among individuals, teams and functions. This means it is more important to understand the scope, for example, how many functions and variations in expectations exist, than it is to hone in on particular use cases and their outcomes.

Processes, by contrast, no matter how complex, can be thought of as a vertical slice of the organization, focused on managing a single action, like on-boarding an employee or approving an expense report. Transactions systems designed and implemented for one function or process cannot be reassigned or redirected to another.

By contrast, collaboration software is usually horizontal, meaning that it cuts across functions, departments and geographies. Even if a few specific functional goals initiate the search for a solution, collaboration technology is rarely so tied to a specific function that it cannot be applied to work that falls well outside its initial requirements.

Buyers need to understand the horizontal and vertical aspects of collaboration. In call centers, for instance, messaging software used to communicate between operators and engineers can help increase first-time call resolution dramatically. That same software, without modification, when deployed across the enterprise, will facilitate a wide range of other collaborative interactions that go beyond functional point communications, and in fact, will be impossible to anticipate or model at the detail level.

This means that buyers also need to understand the scope of their potential implementations, not just point collaborations. In many cases, the acquisition of point solutions will yield licenses that permit wider distribution. If those licenses are used, they need to be deployed purposefully so that the recipients of the new capabilities understand what it is they are receiving, and how it might be of value to them. In addition, buyers need to facilitate feedback not only to help manage issues related to intended use, but to help people attempting to use collaboration software in ways that go beyond departmental or functional requirements.

In organizations that begin at with a horizontal perspective, it is important for them to reach as deeply into the organization as possible to understand all the types of collaborations that currently take place, and the approach to, or even types of work people imagine they could conduct if the right tools were in place.

This effort begins with an inventory of collaborative activity that includes the following information for each activity:

Specifying Requirements

Once an organization understands generally how it could use collaboration technology, it then needs to develop requirements that are used to determine if particular software services and products can meet the organization’s needs.

Business Requirements

The business requirements for collaboration technology will vary from business-to-business for a number of reasons including:

-Vertical-orientation of the business
-Existing collaboration tools in place
-Local and national regulatory environments
-Scope of collaboration participants (inside organization, verified partners, ad hoc collaboration)

Each business must orient itself within this list to determine how industry and business-specific its collaboration approach will be. Vertical industries, like healthcare or energy, may need to include regulatory requirements that restrict information flow or specify information retention.

In the case where an organization must comply with a court order, the details of that order must be included in the evaluation (such as an order to retain specific records related to a product, service or employee for a set period of time).

Lesson Learned 1: Future Use

When speculating about future use of collaboration technology, organizations may design a collaborative activity that can’t be performed by existing software, or would require significant custom coding in order for standard software to meet the need. Those activities should be identified and put to the side during initial requirements specification because they can easily become distractions to the acquisition of a generally acceptable solution. Those more unique or complex cases should be readdressed after general deployment is successful, because only after people understand the capabilities of a tool, and are able to integrate it effectively into their work, will they be ready for new approaches that may not align with their current practice.

Another key business requirement is budget. The organization should determine its budget for the following areas:

Technical requirements

Regardless of how well a collaboration solution fits the needs of the business, its employees and its partners, it is important that it also not introduce technical complexities beyond those already associated with the deployment of a new application.

The following technical requirements should be spelled out prior to conducting an evaluation of any collaboration solution:

- Standards with which the collaboration technology must comply.
- Approach to account management, including access control.
- Desired application development environment and programming language.
- Security and encryption requirements.
- Target server environment.
- Hardware requirements (client and server).
- Type and brand of databases being used within the collaboration environment.
- The applications the collaboration platform or tools must integrate with in order to realize value.
- Target clients on which the collaboration capabilities must execute.

Lesson Learned 2: The Cloud and techinical requirements

While certain technical requirements, like those related to application integration, remain important regardless of the target server platform, the choice of using a cloud service rather than deploying on enterprise servers negates certain questions, like database compliance. If the service uses a database that differs from the enterprise standard, but that database is never managed or in any other way becomes an interface point for other software, then the database used by the cloud service supplier should likely be removed from the requirements (though thorough evaluations may still ask about it for completeness and as a data point related to reliability, and scalability).

Evaluation Criteria

The evaluation criteria is developed from a combination of technical and business requirements, which become a lens for evaluation and procurement examinations that determine the stability and professionalism of the supplying organization.

User Experience

The user experience needs to be divided into three evaluation areas:


Capabilities is perhaps the most difficult category for which to maintain evaluation criteria because it is the most evolutionary. Enterprise social media, currently a widely desired capability, was all but non-existent just a few years ago. Capabilities are also one of the most difficult to evaluate since simulations must be used as a proxy for actual use. Even small pilots do not get to the scale and diversity of use that a product will experience during an actual implementation.

In order to evaluate capabilities, organizations need to:

- Understand the capability categories (see below).
- Prioritize the capabilities against internal requirements to identify which capabilities are required and which are not (or which are optional).
- Test as many capabilities during the evaluation phases as deeply as possible in the time allotted.
- Seek input from existing customers about their experience with capabilities.

Capabilities are divided into several categories:

Continue reading Collaboration Software: A Buyer's Guide...