Wednesday, 16 August 2017

Communities of practice - managed or unmanaged?

Is the best approach to Communities of Practice a managed one, or an unmanaged one?

There has always been a polarity of views between those who see Communities of Practice as something that should be allowed to flourish naturally and unmanaged, springing up as a bottom-up initiative in response to user demand, and those who see communities as more powerful when they are aligned with the business strategy, and managed from the top down to provide a valuable resource to their members.

In this top down selection , the company decides on strategic knowledge areas, and deliberately selects communities to support these, assigning leadership and core members and securing resources. This allows resources to be spent supporting the communities which will have most value to the company, but sometimes these top down communities may not align with the interests of the workers.

In contract, in the bottom-up selection, the company enables the organizations with community tools, and watches for communities that form spontaneously around an area of business need. These CoPs are often high energy, but may not coincide with areas of knowledge which are strategic for the business. Also it is all too common to find multiple CoPs starting up which cover the same topic as each other, and communities that initially flourish then wither and die.

Given that we have two stakeholder groupings in KM (management and knowledge workers) and both need to be satisfied, and given that satisfying one without the other can lead to instability in your KM program, how do we choose which way to support our CoPs?

Shell's experience

Let's look at some real experience. As part of a Linked-In discussion on "Communities of practice, limited or unlimited", we have a useful story from Arjan van Unnik, who was head of Knowledge Management at Shell.

"In my experience the decision about "limited"or "unlimited" turned out to be an underestimated parameter ... I managed a portfolio with some 35,000 users (no pre-registration - everybody personally requested membership for 1 or more communities).  ....Initially we carefully managed the CoP's, based on skillpools. Than the step was made where everybody via the IT department could request a community. The fragmentation resulted in roughly 35% reduced activity in the communities. I had to implement corrective actions and increase the management of the portfolio." 
 "1 of the biggest breakthroughs was when we combined this unmanaged set of 100+ CoP's into a managed set (15+ years ago, and violating all theories about CoP's). Other companies that are successful in CoP's (Fluor, Schlumberger) also manage their portfolio. I've heard about a company that did not manage their portfolio, ending up in more CoP's than number of staff... Not managing the portfolio indeed implies the risk of ending up in a situation that again staff do not know which communities to join - we had that as well back in 1997, before we started to manage the portfolio".

So Shell tried both approaches - managed and unmanaged. The switch from managed to unmanaged led to a reduction in activity, leading Shell to switch back again.

No comments:

Blog Archive