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.