This is the month for Enterprise Collaboration here at CMSWire -- the topic that has been dear to the hearts and minds of the Content Management world for quite some time.

Every few years, there are waves of exciting new products that offer to enhance collaboration for the average worker, but adoption always seems slow. Why? For the answer to the question, let’s turn to the market leader -- email.

The Rise of the Email Leader

Collaboration in the enterprise isn’t new. Since the shared drive was introduced decades ago, people have been collaborating electronically.

After wanting more than the simple shared document storage of the shared drive, the world switched to email. Since then, email has taken the lead in the collaboration space. There have been many challengers, but no takers. Why is that?

Let’s take a quick look at the features in my email client:

  • I can share documents with anyone, anywhere.
  • There is an integrated calendar that can store documents within meetings and invite anyone that needs to attend.
  • As a bonus, I have the ability to issue tasks, record actions, and store/share contacts.
  • Those are some pretty basic, yet important, collaboration features.

We all know the faults: poorly managed content, out-of-control storage and a silo of information in everyone’s mailbox. Email archiving is solving some problems, but not all of them. The questions remain. Why aren’t people rushing to use other solutions? Why are we having to develop adoption strategies and focusing so heavily on ease of use?

The Single Interface Rule

Generally speaking, people like to use one tool per task. They’ll use multiple tools if each one solves a distinct problem or adds unique value. One thing people don’t want to do is to use multiple tools depending on who they are working with on a given task. For a tool to be successful, it doesn’t need to be universal, but it needs to involve the working world of the user.

Editor's Note: Also read The Tools and Technology That Enable Enterprise Collaboration

For many employees in an organization, their work world is encompassed within the organization. They don’t work with people outside their organization’s world except on an exception basis. As you move up within the organization, this changes. Executives and managers interact with outside people frequently. They live within their email as their primary communication tool. It is their only option when working with outside parties, and they tend to want to use the same tool when they switch to working within their organization.

This trickles down the food chain. If someone has to work with a superior using email, they will tend to use email for similar tasks with others. This trickle-down effect continues until you hit a “stopper” that tries to force everything into the tool of choice.

The characteristics of the “stopper” are simple. They see the benefits of collaborating outside of email and try to educate everyone else about the benefits. They’ll take documents and store them into the system, sending alerts and links to the content. They’ll start wikis and discussions and try and bring people into the environment. This usually works with subordinates, but success up the food chain has varying degree of success, primarily due to the single interface rule.

People use this example to explain why executive buy-in is important for projects. You need to have that stopper role high up the food chain for success. The dirty little secret is that even with executive buy-in, there are issues. When a crisis hits or the excitement over the new tool fades, the tool that everyone slowly returns to is email.

Why the resistance?

Getting Past the Limit

Andrew McAfee talked about this adoption problem four years ago and later in his Enterprise 2.0 book calling it the 9x Email Problem. He discussed how a solution needs to be 9x better than the email solution that it is replacing.

Building upon the work by Gourville1, the average user will judge a new technology as three times as ineffective as it really is and their current system (e.g., email) as three times more effective as it actually is. Multiply that together and you are hitting a really high bar.

This is the bar that everyone focuses upon. Surpassing this bar has led to a lot of success. It has also proved to not always be enough. Many point to the culture, which is a factor, but sometimes it is simpler. For a tool to be adopted, it needs to do more than just provide new or better functionality. Users have to perceive it as adding new value and accomplishing a task that either was difficult to achieve or could be done at all.

Looking at my life, I collaborate in a few places. I’ve added Twitter, because it has new functionality and allows dialog with people that I can’t randomly find at the coffee machine.

Facebook is great for sharing news and pictures with friends and family. Each of these tools are have been added to my arsenal the past few years. Why? Both bring easy to use capabilities that add value to my life that was not there before.

Editor's Note: Also read When Should Management Push Enterprise 2.0 Adoption?

Looking Below the Surface

The problems facing the adoption of Enterprise 2.0 tools are not just about culture or usability. It needs about centralizing the collaborative working environment. The end game won’t be one solution that rules them all, but a collection of solutions that can work together without forcing users to switch between them. Like SMTP does for email, there needs to be a way for collaboration solutions to share artifacts with each other.

Until that happens, we are going to be fighting and working to get greater adoption of collaboration. Individual tools will continue to shine, but the adoption of collaboration platforms will continue to take large amounts of effort to start and sustain. It is something worth fighting for, but maybe we can win if we can just get them all to talk to each other and allow users to collaborate in one native habitat.

1Gourville, J. T. (2004). "Why consumers don’t buy: The psychology of new product adoption." Harvard Business School Note #504-056