This is a guest post by Cathy Wildhaber about her experience implementing a wiki in her department. Cathy is a technical writer in Kansas City. For the past 4 years, she has worked for a company that provides computer systems and services to financial organizations.
Ever take a look at some slick wiki technology and think "Wow, that's really cool…I want one"? I did, and the results (an internal wiki for the documentation department where I work) were…less than stellar. Here's how you can avoid my mistakes.
I had been working on a continuing education SharePoint site for the department. There was a wiki webpart available in SharePoint, and I became intrigued. What better way to help department members increase their knowledge about the profession than by harnessing our collective brainpower and talents! We could create collaborative summaries of training we'd attended! The intern could create a "new hire" section! We could have a knowledge base! How cool!
I immediately set up the webpart, learned how to create and edit pages, and provided a training session for my coworkers. I gushed about the endless possibilities, and then sat back and waited for the quality content to roll in. It didn't.
Where had I gone wrong? Through the power of hindsight—and the research I should have done before I launched the wiki—I've come up with a few guidelines to follow next time. Perhaps you'll find them helpful, as well.
If you get starry-eyed over a wiki and then try to come up with ways you could use it, adoption is likely to be weak, as was the case in our department. If, however, you have a genuine process inefficiency or lack of resource that a wiki could help solve, you have a much better chance of success.
This phenomenon is best described by Mark Shead. He defines two types of technology users. Members of the first group identify a problem and then seek a technology to resolve it. Members of the second group, on the other hand, start with a cool new technology and then look for a way to incorporate it into their lives. When members of the first group adopt a technology, they are more likely to stick to it. Members of the second group often abandon the technology after a short time.
To embrace a wiki, users must first see how it will benefit them. Provide examples of how their real-world work could be moved to a wiki, and show how it could result in more efficient processes.
People unfamiliar with wikis may fear that a platform in which any person can edit or delete any page will be chaotic. They may feel concern that a wiki could easily devolve into a free-for-all.
In a company wiki, the accountability for contributions and edits is much higher than in a major public wiki like Wikipedia—no one could leave anonymous spam. And while a small company wiki would likely not have the system of checks that Wikipedia employs, most small wiki communities tend to be naturally self-regulating. Chaotic editing and questions of ownership tend to be non-issues.
If members don't understand the broad concept of a wiki or the specifics of creating pages and setting up links, they won't use it. Be sure to train users on what a wiki is (its purpose and what it's good for) as well as on the wiki tool itself (how to create pages and set up links).
Don't force the wiki upon department members. A lack of posts or edits by a particular member does not necessarily mean that the member is not finding value in the wiki.
A wiki needs care and attention. Having an official "administrator" could imply that content is being policed, but you should ensure that someone performs a few maintenance functions:
To keep your wiki well-organized and usable, incorporate metadata. Metadata allows users to sort by category to quickly find what they're looking for. Many wiki programs allow you to require that metadata be selected and allow you to define your own metadata. Other possibilities for metadata include content stages (can indicate whether the page is new, developing, or complete) or audience tags (can indicate whether the page is primarily for management, administration, or developers).
A system that notifies members when information has been added or changed will remind users that the wiki exists, and it will help ensure that the content is current, correct, and relevant. Notifications could come in the form of an RSS feed, or they can be as simple as an email alert. Users may prefer to receive a daily or weekly digest of changes, rather than notifications about every single change.
A good way to encourage participation in the wiki is to enlist the help of a select few. You may select the most well-respected and established veterans of the department, or the enthusiastic early adopters of each new gadget, or the department members most willing to share their opinions. Often these individuals can pave the way for the rest. Recruit them to help get the wiki started; the rest of the group may well be more willing to participate after ground has been broken.
Get new posts delivered straight to your inbox.
I'm a technical writer based in the California San Francisco Bay area. Topics I write about on this blog include the following technical communication topics: Swagger, agile, trends, learning, plain language, quick reference guides, tech comm careers, and certificate programs. I'm interested in information design, API documentation, visual communication, information architecture and findability, and more. If you're a professional or aspiring technical writer, be sure to subscribe to email updates using the form above. You can learn more about me here. You can also contact me with questions.