So, you’ve picked out a Wiki platrform, successfully beta-tested it with a small group of users and have rolled out your final production version. Unless you are an exceptional individual possessing an encyclopedic volume of knowledge which you can dump into the Wiki, you will need other people to help you.
Building that community, however, could prove to be the most difficult task. In a business environment, it is important to get management to buy in to the idea of building the Wiki, but it is most important to build a base of content contributors. Without that content, the Wiki will have no value at all.
In my experience, I found that the “old guard” was a very large obstacle to implementing a Wiki as a documentation system. Most people, by nature, are averse to change. Change requires them to learn a new way of doing what they already know how to do the old way. At first, they won’t be proficient at the new way so they will be strongly tempted to revert back to the old way. And they did. For quite some time, I felt I was the sole contributor to our Wiki.
It took an influx of new employees before the Wiki really came into its own at our company. These new employees were able to see both the old ways and the Wiki way in action. From that experience they were able to experience the virtues of recording and sharing information through the Wiki. Most of them enthusiastically adopted the Wiki as their preferred method for documenting their activities.
Did that leave the “old guard” behind? Yes, it did. That is a challenge we need to deal with going forward. Hopefully, building a critical mass of usable documentation within the Wiki itself will eventually bring them around. Eventually, they will have little choice left as the old methods become impossible to maintain and others start asking, “Why isn’t this information in the Wiki?”
Next time: The double edges of the Wiki blade.