---
title: "Implementing a Department Wiki? A Writer Shares Some Dos and Don’ts (Guest Post)"
date: 2009-06-30
description: "$( document ).ready(function() { // Handler for .ready() called. $("
canonical_url: https://idratherbewriting.com/2009/06/30/implementing-a-department-wiki-a-writer-shares-some-dos-and-donts-guest-post/
---
# Implementing a Department Wiki? A Writer Shares Some Dos and Don’ts (Guest Post)
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! 

## Wiki Dos (and Don'ts)

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.

### Start with a clear purpose (a.k.a. Avoid the "if you build it, they will come" fallacy)

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](http://www.productivity501.com/index.php?s=two+types+of+technology+users). 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.

### Prove how the wiki can benefit users

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.

### Ease existing fears about the wiki

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.

### Provide proper training

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).