Everything is fragmented— Blog storming in six stages

The adoption of wikis has been disappointing, in part because of the need to pre-populate the wiki and to achieve a minimal level of HTML literacy. That’s a shame because a wiki is infinitely preferable to the confusing colors of a word document with the edit feature switched on. While most people have used the Wikipedia, fewer have edited it, and even fewer have created a page from scratch or from a stub. Even if you get someone to create an article, you run into the problem of ownership. The original creator can be possessive, and others may be reluctant to challenge that person's authority.

A blog storm, executed in six easy stages, can overcome those issues:

1. Choose a subject where there is a need to produce a policy paper, business plan or something similar that requires active participation from 10 to 20 people in the drafting stage. It’s vital to make sure that the document is important and is seen as such to create the right sort of social pressure. Don’t be tempted to try out this technique on something that doesn’t really matter.

2. Ask each participant to engage for a two- to four-week period blogging on the subject matter as a thought occurs to them, but minimally once a day. If they do not blog, then set it up for them and schedule a daily slot in their diary where you will handle all the technical aspects. Teach them gradually, adding capability over time. Whatever else you do, keep up the pressure for the daily blog. Use the daily session to show people what others are doing. Don’t use threaded conversations or group blogs; it needs to be personal.

3. Start sending out e-mail requests: "Does anyone have any thoughts on this issue?" "Can everyone try to find some evidence to prove or disprove this claim?" The idea of those questions is to get more content into the blogs in the manner of a conversation. Install an RSS feed for all participants and link to all the blogs; teach them to comment and hotlink. Publish the top three blogs every day based on their authority by reference over the past week and make that visible. Start to suggest relevant blogs and Web sites that the participants might want to have in their RSS feed. Stimulate multiple fragmented posts, forget structure.

4. At the end of the period, you are going to have several thousand words of rich, fragmented content. Employ a technical writer or a copy editor to create the first wiki article. They can do in a couple of days what it would take a subject matter expert weeks to complete, and it’s easier to read. To avoid the problem of ownership, don’t use internal people for that.

5. Don’t stop people blogging while this is taking place, but they need to know that the content generation period is over for the moment. Use the same software as the Wikipedia. That way the training tools available in the Wikipedia, as well as other editors, will provide free learning. Encourage people to play there while you get the first draft together.

6. Now release your bloggers onto the Wiki document you have created. The five pillars of the Wikipedia are a good set of guides as well, so use them. None of them own it, all will want to check that their ideas have been incorporated. Make sure you have an admin function in place and feel free to ban people for the odd hour for breaking the 3RR rule or similar. (If you don’t know what that is, look it up.)

So that’s it. It’s a simple process based on the principles I laid out in my last column for blog adoption. It also follows the principles of a complex systems approach to technology adoption. I will pick up on this topic in my keynote address Sept. 22 at the KMWorld & Intranets Conference in San Jose, where I will talk about project management and IT adoption from a complexity perspective.