21 days of wiki adoption

Like many others, I’ve been following these great short videos (2-3 min) on wiki adoption from Stewart Mader of the Wikipatterns blog.

My favorite point so far?

• Don’t have a pilot wiki with just early adopters. This was counter-intuitive to me, as you’d expect to get the highest leverage with an enthusiastic group of early adopters. Turns out – those early adopters are often disconnected from the rest of the team. People remain skeptical even if the early adopters are gushing. If, instead, you use a mixed group with some regular users and some skeptics, people will pay attention to what they’re saying!

More on Meetings on a Wiki

Bill Ives of the FASTForward blog adds some very insightful comments to my earlier post on holding meetings on a wiki.

Bill has an interesting point regarding notifications:

I would add to also allow this [notifications] to go somewhere besides the email inbox. I am not excited when a heated discussion on an email group suddenly drops twenty messages in my inbox. Take advantage of the common workspace here and do not drag in the sins of email spaghetti with its overlapping tangled mess.

I fully agree. I love RSS. I would, however, approach it in a differentiated manner depending on the lifestage of the wiki and people’’s level of familiarity with it. If participants are not used to RSS, I’d rather give them updates via email than wait until they learn to use RSS. After they get smothered in email, they will also be more likely to see the use for RSS :D

Stewart also comments:

One suggestion with the point about structure – it’s important to be careful to use as little structure as possible, and make sure people know that they can change the structure of a page if it makes sense to do so. In other words, the flexibility of the wiki is what makes it such a great event planning tool.

Yes, the simplest structure will usually work the best. Once a community has been using a wiki for some time, structure can be very sketchy and free-form. I find that with a community that has only just started with a wiki, an empty page will not trigger participation. Populating the page with some content – breaking the ice, as it were – gives the discussion the traction needed to get going.

Four wiki implementation take-aways

Nathan Wallace posts a great case study on creating a wiki intranet at Janssen-Cilag. The approach is refreshingly common-sense. My main take-aways:

• Pre-implementation conversations are a great way to create excitement and obtain personal commitment to maintain content. Also helpful: sharing articles that give a glimpse into the possibilities.
• Use the “social force control” argument when pitching a wiki: if social forces keep people from sending out weird email messages (which colleagues do not see), social forces will act more strongly to keep people on target in editing a wiki page. Also helpful: pointing out that changes captured in a wiki and monitored will be much easier to manage than the quiet behavioural departure from “norms” experienced by many companies.
• Use Wikipedia as an uber-known example. This provides a very positive point of reference for a new technology that is disconcertingly free-form.
• Offer ultralight training – Nathan was able to offer the necessary training in 5 minutes. After that, one-on-one coaching and a help section provide ongoing support. Also helpful: Begin with a basic help file, and as people have more questions, explain – then ask them to update the help section. People who are only just learning how to do something are much better equipped to explain to their peers than an “expert” is.

Nathan’s approach to content ownership and maintenance is remarkably simple and clear:

1. If someone isn’t willing to maintain a piece of content, it can’t be that important to the business.
2. We happily show people how to do things with the site, but we don’t do it for them.
3. Occasionally we highlight sections of the site on the home page, which is a great way to drive the defacto owners to clean it up a little.
4. We encourage people to have high expectations for content on the Intranet. If something is missing, please report it to the appropriate area of the business, or better still, add it for them.
5. The answer to verbal queries for many departments has become, “it’s on JCintra [the wiki/intranet]“. This reminds people to search first and ask later.
6. In the end, the quality of content in an area is a reflection on the defacto department owner, not the Intranet itself.

“It’s on the wiki!”

The one thing that most discourages team members from actively participating on a wiki: being asked to provide – verbally, via email or other direct communication – information that they have already written on the wiki.

To counter this: give everyone free license to say again and again – “It’s on the wiki!”. Encourage wiki participants to NOT give out information through another medium.

Bonus: any technical issues that keep the wiki from being fully functional will surface and be solved much sooner.

How to hold meetings on a wiki

In the days immediately following our first World Cafe, our team couldn’t find time to hold an evaluation meeting. We decided to try holding the meeting on our wiki, and found that the results were better than in a traditional meeting. Here’s what we learned:

1. Allow enough time for the discussion. While a traditional meeting can last as little as a dozen minutes, the time-distributed nature of a ‘wiki meeting’ makes it necessary to allocate at least one day, depending on how busy team members are with urgent projects. Don’t expect people to drop everything and participate on a wiki discussion. We created the wiki discussion as soon as the World Cafe ended, and within 24 hours had obtained input from all team members.

2. Offer structure. As you create the wiki page, populate it with questions and issues. Make the structure simple and specific. Add content, don’t just post the meeting agenda. Include all relevant information, spell out your opinions on each subject and ask for more information where necessary. People are much more likely to respond if all they have to do is agree / disagree with an opinion or answer a specific question.

3. Encourage participants to openly sign their contribution. Mediawiki software parses three or four tildes (~~~~) into the signature of a participant to a discussion. A simpler option is to simply preface each comment with “Ron says:…” While most wiki software allow readers to find out who performed each edit, openly signing content goes a long way to keep the tone conversational.

4. Provide participants with tools to follow the discussion. Whether your software produces RSS feeds or simply sends email, make sure everyone knows how to set up frequent notifications. (Wouldn’t it be great to have wiki software produce Twitter feeds?)

5. Manage the discussion. While a moderator is usually not necessary once you have created structure and obtained participation, a discussion will often require participants to gather additional information or perform external tasks. Someone might have to install and demo some software, make some phone calls, cross over into the office of a non-participating coworker to obtain his expertise on a particular issues, or simply dig up some information. While participants will often self-organize, it is your job as the initiator of the discussion to follow through. Above all, make sure you keep contributing with any information or ideas made necessary by the discussion.

6. Capture actionable items. Regardless of the project management system your team uses, it is very important to capture and act on any requests made during the discussion. At the very least add ideas to a “To consider” or “Someday” list that everyone can see. Discussions on a wiki are available for reference, and few things discourage people from participating as much as the evidence that their contribution was not followed through.

7. Declare the meeting closed. Give participants 3-4 hours’ notice to put in a last word. After, that, formally close the meeting. Post a notice at the beginning of the wiki page. Don’t leave the conversation open-ended. It’s discouraging.