A Methodology for Web 2.0 Collaboration Experiments (in Reluctant Organizations)

• What’s perceived as urgent in most organizations (i.e. what’s keeping management awake at night) isn’t collaboration or innovation or technology or worker effectiveness, it’s cost reduction and risk management. Nothing else gets any executive bandwidth.
• You can’t change an organization’s culture (short of firing everyone and starting over with new managers and staff). The best you can hope to do is help people adapt to the existing culture in useful, valuable ways.
• Organizations are, mostly, complex adaptive systems, so one-step needs identification is futile. You have to let a full understanding of the organization’s problems and needs, and the solutions that address those needs, co-evolve. By the time you have an intelligent answer, your understanding of the problem is usually vastly different from what it was at the outset.

So any methodology that hopes to help improve collaboration in an organization needs to be very adaptable, modest in resource demands, sponsored, and attuned to the complexity of collaboration challenges. I think I’ve come up with a methodology that meets these requirements, and it’s illustrated above. Here’s how it could work:

1. The Champions Self-Organize: I know you’re used to me starting innovation process charts with ‘needs’, but in this case I think it makes sense to start with people. What I call ‘champions’ consist of three groups: 
1. the organization’s thought leaders ñ people who, regardless of seniority or title, are considered innovative and ‘ahead of the curve’,
2. current users of web 2.0 applications ñ kids who use blogs and wikis and RSS feeds and mindmaps and forums and people-finders and social bookmarkers and all the other social networking tools, and can get the others up to speed on how and when to use them effectively, and
3. what I call ‘respected sponsors’ ñ people whose use of new collaboration methods and tools will raise eyebrows and get others on-board for fear of falling behind, and who will invest the time to use these methods and tools continuously and regularly, not just during a one-shot launch. 

2. The Champions Meet Face-to-Face: I think it’s asking too much for all the heavy lifting of new collaboration projects to be done virtually, at least at first. No question that the champions need to use the tools for their own activities, but there is much work to be done up-front to understand the opportunities and challenges, and some sleeves-rolled-up face-to-face is needed to do this. These meetings should start with a learning event to get those unfamiliar with the tools, the applications, and the current state of the business, up to speed. Brainstorming just to get a lot of ideas and possibilities on the table should follow.

3. Design & Create Experiments: Then, with this knowledge and some inexpensive ‘infrastructure’ in place, the organization can start launching, and encouraging, the most promising collaboration experiments. These should meet five ‘design rules’ (and while lots of experiments should be encouraged, those that defy these rules should be questioned at the outset, since they are more than likely to fail):
• Participation should be easy (or else new collaborators will get discouraged quickly), intuitive (or else collaborators will go back to using e-mail and other ineffective methods), open (to participation of any employee or customer who wants to contribute), and voluntary (the quickest way to kill enthusiasm for a new idea is to make it mandatory).
• The collaboration process should extend and build on existing relationships and conversations. Social networking and web 2.0 are all about strengthening relationships and capturing and sharing the learnings from conversations. This relationship-building and these conversations are occurring anyway, so rather than forcing them to occur a different way, collaboration experiments should encompass and help capture, facilitate and improve this knowledge and learning without interfering with how it occurs now.
• The new collaboration processes and tools should be integrated with existing processes and tools like e-mail, PDAs, CRM, IM, HR and other systems and collaboration tools and ‘spaces’ that are currently being used (with varying degrees of effectiveness) to collaborate. Rather than trying to prohibit e-mail and IM for collaboration, for example, link from them to wikis, mindmaps, forums and other tools that more effectively capture and facilitate collaboration, to wean e-mail addicts painlessly away.
• The experiments should be self-managed. Let the people who stand to benefit from new collaboration methods and tools figure out how to use them, and for what. They will need to learn and practice, and you can’t do that for them.
• You must build in personal ‘what’s in it for me’ attractors. People want to do their jobs more effectively, but not at the expense of working harder or longer. Give them their own personal space (e.g. through a blog or personal web page that hosts collaborations or conversations) that offers ‘pride of ownership’. Don’t forget that ‘commons’, even collaborative virtual ones, will usually suffer from the tragedy of the commons.

4. Run the Experiments: Give them time, space and nurturing, but don’t get in the way. Be patient. Focus on the learning. Give people the opportunity to practice safely using the new method or tool, until they become confident and proficient using it. A great way to do this is to show a wiki or mindmap evolving in real time on-screen at the front of the room during in-person meetings and by ‘sharing your screen’ electronically during virtual conferences. Let people see how these tools capture the essential learning and consensus from a meeting. Let them practice using them, until using these tools in all collaborations, face-to-face and virtual, becomes ‘the way we do things’. And be sure to grant permission to fail — many collaborations will turn out to be unsuccessful, but they’re still valuable learning opportunities.

5. Monitor and Celebrate Success: Identify the attempted collaboration experiments that just aren’t working, for whatever reason, and kill them. Don’t force people to use a collaborative method or tool that just frustrates them. Instead, watch for successes, and craft stories that explain how and why they worked, in the context of your own organization — these will be the models that will spawn other successes. Leverage learning and successes, and steer people to the methods, applications and tools that have worked in similar situations, using the story as your ‘selling tool’. It works!

I should note that this methodology is just intended for web 2.0-enabled collaboration projects. There are other types of collaboration (peer production and idea markets most notably) that organizations may benefit from as well, that would perhaps require a different approach.
I’m going to try this methodology out in the organization I’m currently doing contract work for. The opportunity there is great, but the cultural barriers are high and a sense of urgency is lacking. Even with these challenges, I think it could work. I’ll keep you posted.

I’d like to thank New Paradigm for facilitating a workshop today, and also the bright participants in the workshop from a couple of dozen organizations, who helpedcrystallize my thoughts on this. I’d also like to thank my online collaboration colleagues and the members of my Toronto KM breakfast club, for their contributions to these ideas.