Barb Mosher set the scene for this month's CMSWire focus on communities (or at least, online communities!) with her thought-provoking piece, "Communities: We All Want to Belong, or Do We?"

Barb references a definition of communities from David Coleman (founder and MD of Collaborative Strategies): "Communities rely on the strength of social ties, where your being there is important." I would add that in this case, "being there" includes in a virtual mode, as in logging on and taking part in the online communities activities.

Barb goes on to say this about internal communities in the enterprise: "Internal communities are about a groups of people working and collaborating for a common goal." Well, at this point I would like to respectfully disagree with my erstwhile colleague!

I would suggest Barb is actually describing a small team or a work group -- people closely collaborating (as in working together toward a common objective).

Communities of Practice versus Communities of Interest

So at this point, I would like to refer to the Wikipedia page for the term "community of practice" -- principally to the anchor on that page for a section called "Communities of practice versus communities of interest." Notice how I just slipped two different types of community into the conversation?

To borrow a single bullet point for each from the terms above, we can provide a very short and succinct definition:

  • Community of Interest (CoI): The purpose of the CoI is to provide a place where people who share a common interest can go and exchange information, ask questions and express their opinions about the topic.
  • Community of Practice (CoP): The purpose of a CoP, as discussed above, is to provide a way for practitioners to share tips and best practices, ask questions of their colleagues and provide support for each other. Membership is dependent on expertise -- one should have at least some recent experience performing in the role or subject area of the CoP. 

How do these different types of community fit in an enterprise context?

At a recent ECM strategy workshop provided by OpenText, I found myself surrounded by Ontario Provincial Government employees. At least three or four of them were records managers for specific Provincial Government agencies, while five or six others had a non-records specific information management role for the same or different agencies. Based on the above definitions, the records managers would be members of a CoP because they are active RM practitioners, while the information managers might be members of a wider RM CoI because the subject is definitely of interest to them, but they are not actively engaged in records management on an operational, day-to-day basis.

To compare both of these communities to a project team or work group, it might be easiest to think of communities as being driven from the bottom-up, growing organically as the membership discovers and understands its joint interests and goals. The project team, by contrast, is more top-down, brought together to achieve a particular effect by working toward a specific objective.

Now that we have some baseline definitions and understanding of these differences, we can consider two elements that link communities to your enterprise information management and enterprise content management strategies: culture and technology.


Organizational culture is important for nurturing communities. Does your organization value sharing and cooperation, or as Barb mentions in her posting, does your organization value hording information, taking the old "knowledge is power" position? Even if your organizational culture is not one of open sharing, communities, due to their bottom-up nature, may still spring into being; they bring together like-minded individuals who do want to share and cooperate, even if that means "swimming against the current."

This actually leads to the linkage to technology platforms. If the organization itself will not actively support the communities, then those communities may end up making use of externally hosted technology (if firewall roles, proxies, etc. allow it).

Technologies and Tools

Based on our above definitions, we might decide that CoP's, CoI's and project teams (and work groups) all have a slightly different focus, and therefore, their mode of interaction might require separate tools or technology platforms.

If we pare this down to some very simple basics, it might look something like this:

  • Project Teams: need to coauthor or co-edit documents; need shared calendars and "to do" lists, plus various other tools, all integrated into a "workspace" -- this often pans out as mostly document centric collaboration.
  • CoI's: Need to discuss their joint interests, share links, and maybe publish some information to provoke discussion, etc., because it's more about sharing a common interest than working toward a common goal.
  • CoP's: Everything the CoI needs, plus perhaps a little of the project team technology; maybe the ability to post a document not just for publishing, but for some edits from the rest of the community.

As I say, this is a simplistic view, and these are not meant to be hard and fast delineations, but we can see that from a technology point of view, CoP's and CoI's might gravitate more toward "social" platforms -- blogs, micro-blogging, discussion forums, rich personal profiles and the ability to discover particular individuals and subscribe to their status updates -- so the internal corporate version of LinkedIn rather than the SharePoint team workspace.

So if we loop back round to culture, we must consider the regulatory environment, and the externally hosted versus internal servers issues.

Heavily regulated, or not regulated at all?

At one end of the spectrum, an organization maybe more than happy using an external social networking type platform for their communities -- tools such as Yammer or SalesForce Chatter. However, if the regulator environment means that you have to keep your communities secured behind your firewall, it may mean tools such as Lotus Quikr, a social intranet platform like ThoughtFarmer, or add on's to SharePoint 2010, like NewsGator or Jive. Furthermore, you may need to manage the content of your community platforms from an enterprise content management perspective, applying content lifecycles and records management policies.


If an existing internal community comes to you, or a senior manager suggests setting up some enterprise-wide internal communities, try to figure out what type of community it will be: CoP, CoI or something else entirely. Talk to community leaders or champions about their requirements. This of course may have to be an iterative process if your organization has never had communities before! Just don't try to ram a community "square peg" into a project team workspace "round hole." If possible, take a "right tool for the right job" approach.

Editor's note: You might also be interested in: