Chapter 3. Planting The Seed – Think Before You Implement

One of the first steps in implementing a wiki is to ask yourself the most basic question – do you really need a wiki?

You may discover that the community you are planning to set up the wiki for simply prefers another way to collaborate and communicate. One wiki I set up for a local writers group was a spectacular failure because they simply preferred to share information by having a weekly get together in a local coffee shop. The technology became superfluous to the community’s needs.

However, not every company or organization can meet in the local Starbucks, so a collaboration tool that provides access and facilitates conversation across a functionally or geographically diverse group may be essential.

You must also avoid the secondary mistake we made with the writers group, installing technology for technology’s sake. Though a few members of the group were techies and thought a group wiki would be cool, they didn’t have a clear vision of the wiki’s purpose and goals. Unfortunately nearly every case I have come across of a wiki implementation failing was due to it being a technology-driven implementation.

If you are reading this book, there is a good chance that you are what is referred to as “a technology ambassador.” That is, you are among the first to look at, try, and adopt new technologies. But, be aware that the things that appeal to you as a technology ambassador can intimidate average users and even put them off using the technology all together. 

So before you jump in and start, you need to think about what you are doing, why you are doing it, and how it will affect those you hope will use and benefit from the wiki.

Ideally, you should put together a small team to help you ask and answer the questions I outline later in this chapter. The team should consist of at least:

One of the biggest worries managers, especially IT managers, have about wikis is a perceived lack of control. They may believe that wikis must be open to anyone, thus opening the door for system abuse and security risks. The opposite is, in fact, true. Most wikis offer levels of access control (sometimes to the page level) and accountability far greater than many traditional enterprise systems.

By bringing in a fresh pair of eyes, and by being free from the company’s institutionalized habits and assumptions, an outside consultant can often anticipate these concerns, and help educate and manage the change more easily than an internal person can.

Even if you can’t build a full “seed team” you should ask at least one other person, preferably a potential user, to act as a sounding board while you work through pre-implementation questions and concerns.