James Robertson from Step Two Designs proposes that Collaboration Tools Are Anti-Knowledge Sharing. (Given that his blog, even though powered by MovableType, doesn’t accept comments and trackbacks, perhaps it’s true).

He writes:

“There is a clear need for collaboration within organisations, and the rollout of collaboration tools will bring many benefits.

What is not widely recognised, however, is that the unmanaged spread of collaboration tools can work against knowledge sharing.

While collaboration tools work extremely well for the staff using them, they can lead to hundreds (or thousands) of information ‘silos’, making it harder for other staff to find required information.“

It reads to me that he is looking at collaboration tools from the perspective of enterprise knowledge management, and seeing little but badness.

I think he’s wrong. And here’s why …

Collaboration Tools Are For Teams
Collaboration tools facilitate the sharing of knowledge among the team members who are using the site / space. As the work of the team progresses from start to completion, everything that is related to task at hand is there.

Everything in the Space Isn’t “Knowledge”
If the team has done a proper job of collecting and collating all of their discussions, all of the document editions, all of their meeting notes and so forth, that is not a collection of “knowledge” … it’s a set of data points and information items on the route to a final destination. James writes that the inability for merely anyone to understand the context of each item (“What is this file, is it a final or a draft? How does it relate to this other document? Where is the main project plan?“) is a failing of the tool.

I don’t buy that.

I think that it’s a great safeguard so that only people with an overall understanding of what’s going on within a project can adequately weigh in with an answer.

And if, as some KM theorists say, knowledge is socially constructed, then knowledge is equally socially interpreted. The grouping, then, of knowledge-under-development into socially recognizable buckets is a huge leap forward to the single, meta-data driven black hole, I mean, repository.

(Having said that, there is a great case to be made for a level of standardization across the enterprise for common project related items, both in where to find them, and for the purposes of roll up and consolidation to give a programme or portfolio level view.)

It’s a Quantum Improvement Over Email
When projects are managed without team collaboration tools and email is used instead, then you definitely have lost knowledge. You have to have received the email (or a subsequent derivative) to know of its existence. Conversations can be held about projects that are forever invisible. At least with work and conversations transacted within a collaboration tool, it’s all there if you have access to the space in question.

And email mailboxes gets deleted when people leave the organization. Now you’re really talking about knowledge that gets lost.

The Core of James’s Bugbear Is a Governance Issue, Not a Tooling One
James writes:

“The strengths of collaboration tools in supporting the needs of individuals and groups are also the potential weaknesses for the organisation as a whole.

By default, staff will tend to publish all of the content they produce into ‘their’ local collaboration space, rather than into a higher-level corporate space.

Left unmanaged, this will inevitably lead to the proliferation of hundreds or thousands of collaboration spaces each containing a small subset of corporate content.“

You can not reasonably make a case that this is an issue of the tools in question. It needs a governance approach that clearly articulates that collaboration spaces are for the collaborative development of deliverables and content, which should, when in final form, be published into corporate repositories for wider distribution. If you do that, and make it work through a combination of written policies and the post-project review phase, the problem goes away.

I think that team collaboration tools are the best thing that’s happened to knowledge sharing in the organization recently, not the worst.

I do believe that a hodgepodge of disparate collaboration tools within the enterprise can cause many problems, which is why:

1. I wrote the vendor-neutral 7 Pillars reference architecture for designing an enterprise collaboration environment;
2. I want to see greater collaboration amongst collaboration vendors leading to tooling interoperability;
3. I help clients work through an effective decision process on questions of designing collaboration environments; and
4. My SharePoint for Business white paper calls this out as a specific issue.

What’s your experience?