Almost in-vitro CoPs. And I don’t mean CoPs for reproductive health :-). Not that it’d be a bad idea.
But to the point. Recently I’ve had reason to give a lot of thought to CoP-fostering as a whole, and as a managed process.
Picture this. You are an organization that is somewhat removed from the people that matter for your goals. They interact with you only after a lot of preliminary, arduous work has taken place. Indeed, they deal with you almost through a filter, for their needs are complex and your part in solving them is very specific. You don’t half understand their domain, and they don’t really understand yours. You fret that helping them through their preliminary work would help you too, and wish you knew how to drive more from your competition. Then someone talks to you about communities, and you realize that what they need is peer support and a holding hand. A CoP, in short, with you as a sponsor. You’re an enterprising organization, so you get to work.
Being also a practical, intelligent organization, you hire me to help with that work :-). And so the fun begins.
Take the business from under the bushel
Some people will say you don’t build CoPs :-), they just emerge like mushrooms after the rain. And in fact you don’t. You foster the community and you build it’s environment: in other words you arrange the trees and pour the rain, and often put there the early spores just in case. The CoP must do its own growing.
Most CoP-building starts with the aim to give a platform to an existing community, or to catalyse some that are already clearly there (often partly inside the buiding). The saying is “you find the CoP, you don’t build it“. The funding organization has a clear interest in it, so the business side of the matter is just “how do we measure results”, not “what should be we doing”.
Some others have to do the business case to get the funds. Here, we had to go back to designing the business angle, since we could not take anything for granted. What are the targets? How should the community further them? What specific processes should be designed and integrated to make sure it does? How do we track it? Now, what’s the business case? Too often, the questions go unasked and the CoP effort launches without having defined some things that should be essential for its success… and ultimately falls by the wayside as irrelevant.
Project management and community work
So once we have a clear understanding of the business needs and a general design of the would-be CoP’s integration in the organization’s business processes, then we can start to flesh the idea with the usual concepts of domain and community and whatnot.
That will usually be managed as a project. And project management has a tendency to rely on clearly defined phases, tasks, deadlines, deliverables, and (especially) responsibilities. That will serve us early in the project when we’re dealing with the organization… but as soon as we have a community core, and want it to evolve ideas or test services, out goes most planification. And you want the core’s input, since you can’t build a home for a community of which you won’t be a member, not without their help.
You need to identify relevant content and services (to start with). You want to fine-tune the technology (at least a bit) guided by early use. You want to fire-check the ground rules and community guidelines (and if possible add to them from user input). You want a lot of things, and you want it now. They want to go on holidays. And they do. Volunteers have that.
So it helps if you map out exactly what you want them to tell you early on. It’s not that much: most community evolution will have to take place later, involving people in the use of resources already built. But you need to define the domain, you need to define the community (the target you’re driving at), you need to define the services and content they will find useful, and that will therefore drive them to you and catalyse conversations. You need to define may other things, but in less detail… and if you’re an old CoP hand, you don’t really need much more early help.
But that data you will pursue and get, and get it by due dates. It will fall to you to exact it and coax it into proper design documents: no foundling community will do that for you. So at the beginning, it’s you that the project will be managing.
Thereafter, marrying the needs of project management and the creative chaos of community evolution require a clear understanding of each other. You can’t drive volunteers, but you can egg them on. On the other hand, you can’t rely on getting a “finished” anything from them, so (for the more formal work that needs doing) you’ll be forced to work iteratively.
Iterations and deliverables
Communities evolve their practices and their ideas, especially early on. On day 30, they may like something that they find inadequate on day 300 (or even on day 40). They might find out they need a different tool, or a different rule, or a different way to manage new users, or…
So anything you build or manage for them (say, a portal, a forum system, and identification system, a rulebook) will be perpetually needing evolution. On the other hand, if you work as is usual in professional services firms, you want a start and an end date, and clarity in between.
The only solution I’ve found to date is to identify those evolving things, mark them out as tasks, and set “freezing points” at which requirements are gathered and the next iteration is launched. That helps manage resources and focus community minds at the same time… and not least, it enables you to give the customer some formal, solid, deliverables at the expected time.
So the trick is: define unending, iterative community activity, and fit them with fixed-date “freezing” tasks where your resources help it define current requirements; then define the resulting iteration as a conventional project activity, with deadlines and resource involvement and clearly defined deliverables. You can even plan ahead this way.
More news? This is a marriage of conventional project management and the community development practices described in “The Cathedral and the Bazaar”, that beautiful Bible of collaboration. It was done in self-defence. And it works.
PS: Asif Devji is guilty of teasing this out of me with his related work and questions, at com-prac and at his blog. I don’t really buy his model (a mite too formal and idealistic :-)) but it does depict most things that need to be attended to, and he’s working hard at it.