5 Steps to Wonderful Wikis

I often hear the "we need a Wiki" “requirement” from clients.  Since I know that there is no such thing as a "requirement," I always reply back with something along the lines of "what is the business outcome that you are trying to achieve?"  Wikis are merely one of many options for collaboration technology but more than many, they suffer from what I call the "bright shiny object syndrome" (attraction and interest based on the fact that something is new and shiny rather than particularly appropriate).

If the answer to the Wiki question is yes, then here are 5 inevitable Wiki issues and suggestions for how to resolve them.

1.  Editorial control

One of the first questions you need to ask when you think about a Wiki is whether or not you are comfortable giving edit privileges to all users.  At Microsoft, for example, most, if not all, internal employee Wikis can be edited by anyone in the organization.  Why does this work for them?  Think about the population - IT savvy experts in an enormous global company.  Of course almost everyone has the expertise to update content in terms of both technical skills and knowledge of the subject matter!  Plus, the risk of publishing incorrect information is probably not that high in most cases.  Wikipedia works for the most part because there are millions of potential editors viewing content and often updating and a smaller but also large cadre of people who have taken on the responsibility of effectively policing the content.  This model doesn't always provide success for internal Wikis.

Solution:  Moderators and Guidelines

A good option for mimicking the successful Wikipedia model in your own organization is to assign moderators to review the Wiki on a periodic basis.  If you require that content editors "tag" new Wiki pages with a key topic area, you can divide up the moderation responsibilities to a few key moderators who can be alerted when new content is added to their topic area (assuming that your software supports alerts).  To ensure that the moderation burden does not overly tax your community of moderators, you can rotate the responsibility among several people.  Moderators do not have to be subject matter experts (see point 4), but it doesn't hurt if they are.  Ensuring that the Wiki is moderated may help resolve any concern your legal department has about allowing all users to edit content.  You should also be sure to publish Wiki publishing guidelines - something short and sweet that users can easily remember - so that all content contributors understand some general guiding principles.  Be sure to publish the guidelines on the front page of the Wiki (and consider linking to them in the template for every page).

2.  Urban sprawl

 If all users can contribute content to the Wiki, you may find that for a variety of reasons, including lack of time or inclination to search first, users will create new content rather than editing existing Wiki content.  This can result in a proliferation of out of control Wiki pages that inhibit "findability" and the delivery of real value to end users.

Solution: Engage the Community to Help the Moderators

Consider offering recognition or rewards to "duplicate detectors" in the user community.  Use training and communications vehicles to promote the value of not just updating existing entries, but consolidating duplicates.  You can also consider displaying the "creator" or "last editor" of each page prominently on the page so that if a user isn't comfortable editing or consolidating content, they can at least send a message to the creator or last editor asking that individual to do so.  Ensure that your training messages tell users that all users are responsible for the accuracy, reliability, and "findability" of Wiki pages.

3.  Power but no inclination (or time or incentive) to edit

One of the challenges many organizations have as they roll out new Wikis is that users don't may not realize that they have the power to update content or they have no inclination or incentive to do so. (Remember, in most cases, a Wiki is not like a traditional intranet page with a small number of editors and a large number of readers - and that's a new model for many users.)

Solution: Persistent Communications

Launching your Wiki is not a "do it and run" proposition.  At least initially, you need to ensure that your communications plan includes persistent activities to remind users of both their ability to edit, responsibility for content accuracy, and shared accountability for content management.

4.  Slow start or "quick start and fizzle"

Wikis tend to have two deployment stories: they are either slow to catch on or they start with an initial burst of activity and then content contribution fades over time (as the Wiki's "bright shiny object" status starts to fade.

Solution: Core Team of SMEs, Champions, "Wiki Wizards"

This is basically the same recommendation as assigning moderators, but the moderators don't always have to be Subject Matter Experts to be good moderators - your core team should be SMEs.  The idea behind having a core team of SMEs , Champions, or "Wiki Wizards" (you can call them whatever works!) is to ensure that there are designated people who have committed to publishing content.  Subject Matter Experts often have an incentive to publish content "once and for all" in the Wiki, especially for routine questions that they are frequently asked.  They may not be comfortable posting information about more complex issues, but you may be able to get them to define general models for even complex topics so that they can ask users to first check the Wiki and then, after they are more prepared, ask the SME for help.

5.  Lack of organization

The good news when your Wiki is widely used is that there will be a lot of content.  The bad news is that if you didn't document your information architecture strategy as part of the Wiki design, you will need to define an information architecture before things get too out of control.  As much as it pains me to say this, there are situations where you may not want to do too much architecting in advance so that you can see what kind of content gets added and then use the initial content to infer an architecture based on what users really seem to be doing rather than your assumptions about the best way to organize content.

Solution: Don't ignore information architecture (even if you start small)

As content builds, take a look at what users are adding and assign categories to make content pages more "findable."  Ensure that an information architect is assigned to monitor the Wiki(s) so that while you are letting a thousand flowers bloom, you are organizing those flowers into a beautiful garden that makes sense in your organization.  As the flowers continue to grow, your architect (or gardener) should have a persistent responsibility for pruning the weeds, because they are definitely going to pop up in your Wiki, pretty much as quickly as they do in your real garden and while you are likely to be able overcome the contribution and editing issues, most users are going to be very reluctant to delete anything.  That's where your master gardener comes in - this is someone who can be ruthless about pruning content that is either not used, inappropriate, or just too old to be valuable or relevant.

• Microsoft
• best practices
• Governance
• wiki