Not surprisingly, our research also found several examples of less successful wiki projects. Some organizations were surprised to learn that a wiki could not fulfill their—perhaps too hopeful—expectations. The fact that content is always evolving can be a difficult new way of working if you are used to sharing only authorized, well-documented, and well-managed information.
Before we dive too much into the lessons learned from those with large, complex, and global wikis, let us first go through the initial planning.
A Wiki Business Case?
If you are looking solely at bottom-line improvements, a wiki may be hard to justify. It can be hard to put a value on increased flexibility and support for processes that are more ad hoc, and as with any other tool, there will be actual costs in installing and implementing the product. Few, if any, wikis bring in additional revenue or direct cost savings. In other words, creating a hard dollar business case for your wiki initiative may not be an easy task.
By now, you may be tempted to extrapolate timesavings into real money. Consider that 5 minutes saved by all employees every day will surely add up to a large sum. In reality though, the financial gain from timesavings tend to be more mythical than anything else. That is, unless you actually plan for the wiki to enable you to reduce the head count and then save money on salary.
A more realistic objective is that a successful wiki may save you and your colleagues some time and free it up for other tasks, but is this a good enough justification for you and your management?
A Part of the Toolbox
When formulating your business case, it may perhaps be wiser to consider wikis as a part of a larger web toolbox alongside other tools such as blogs, newsletters, and search. You can then look at overall costs and create a sensible business case for the toolbox as a whole.
While a wiki is indeed flexible, it does not replace the need for other tools, such as a web CMS or an enterprise search engine. Defining the relationship between the wiki and the intranet can be a difficult exercise, with the two sometimes in competition with each other. Implementing a logical relationship between the two includes integrating the wikis into the intranet navigation and making the purpose of your wiki clear. For example, a wiki will have trouble meeting the requirements for an HR intranet with self-service.
Just like wikis, blogs are also tools for ongoing dialog and collaboration, and it may not always be easy to decide whether your new content is really better suited for a wiki page or a blog posting. Blogs let people add comments, but each post is a separate article controlled by the author. In a wiki, there is no such control as each page can be edited and linked to other pages by anyone. Blogs emphasize discussion through comments linked to individual posts, while wikis emphasize co-creation of content and structure, in perhaps a very large, ever-growing, set of pages.