What is a Wiki good for
In my development teams a Wiki system has always played a pivotal role in capturing documentation about the systems and stuff. The rule is; if its important it should probably go in the Wiki.
Developers are notoriously slack at documenting the things they do. Some will even claim that their code is so well written it is effectively self documenting. In the moment it just seems so obvious what is going on, and then a week later no one including them selves can explain how it works.
Wiki’s are a great response to this dilemma. It is free flowing so you can document random stuff without considering documentation standards or structures. It allows any member of the team to jump in and change what they want. It keeps a full change log which allows version control and the ability to audit the changes.
In a development team this works better than any other solution I have tried, even better than the whiteboard. Mind you the whiteboard is my close second, as long as the contents of the whiteboard get translated to a nice diagram and bullet-pointed list somewhere, like the Wiki.
Where the wiki really shines though is in documenting structured information meant to be referenced. Documenting the systems is an example of this but an even better example is documenting processes, like the Software Development Life Cycle (SDLC).
With the success of a Wiki for the development team the business sometimes asks if a Wiki would be a good idea for a wider purpose of documenting for the business. This has lead me to ask my self what a Wiki is good for.
Every organisation has a set of documents detailing policies, processes and procedures. Policies are high level documents that need to be tightly controlled. When policies change they go through a review process that includes all the most senior managers of the organisation and sometimes the board. Wikis can play a role here but it is not where they shine. The officially endorsed document should not be editable and published in an accessible location. The Wiki can be the place where it is stored or you can lock a Wiki page where the policy lives but this is not what Wikis are good at.
Processes however, are practical work instructions that outline how things should happen in a perfect world. As the organisation learns new ways of doing things those processes need to change. Those learnings usually happen in the functional area that is responsible for the process but it may occur anywhere in the organisation. The process for approving changes to processes is less onerous that the process to change policies. These conditions make a Wiki an ideal place to capture this information.
The Wiki page becomes the reference for anyone who wants to know how to interact with the process and it is open to anyone to contribute to its evolution. It has the ability to audit the changes and a discussion panel to discuss any thorny issues. The page can be grouped into a set of pages such as “Procedures” or even “Staff Handbook” and provides a permanent link that will remain the same even when the policy changes.
At the lower end of the spectrum we have Procedures. This is the most practical of the three types of official business documentation. Processes are step by step instructions on how to do something. It overlaps with the notions of training manuals or a Knowledge Base. My mind is still divided on whether Wikis are a good way of handling procedures. I think there is a line of diminishing returns when it comes to procedures.
The reason for this is that Wikis are intended to be a collection of knowledge articles. Just think of the way you use Wikipaedia. You have a topic and the Wikipaedia has an in-depth article on that topic. If you write a large collection of procedure documents it will become hard to keep all those documents up to date when your environment changes. This is because the Wiki is not well suited to managing hierarchical or interconnected sets of small articles. It is also not easy to format work instructions, managing images is very rudimentary.
Don’t get me wrong, you can do it. I just don’t think a Wiki is a good tool for managing your procedures.
What about FAQ’s and Knowledge Bases? The essence of a Wiki is to be a Knowledge Base but it does it by capturing topical knowledge articles. As such, if the Knowledge Base you are building is topical I think it is a good solution. An example is using it to document the Applications that a development team is supporting. However, if it is a more free flowing Knowledge Base capturing a question and answer type of Knowledge such as at a Help Desk then it may not be the right solution. How do you know? Think of it this way: if the wiki will get messy and hard to organise with the information you are capturing, then it is not the right solution. You are better off with a tool that helps you organise the information and reference it.
FAQs are generally a small set of manually curated questions and answers. As such I don’t think that any system is required for that. Wiki is just as good as any other. The main question is; how do you want to deliver that list? The format and access is more important than the system. This list will not change much at all. If that is not the case then maybe it’s not actually a FAQ.
Wikis are great. They offer something that just did not exist before. Used well they help us organise the chaos but sometimes they turn into white elephants. The difference I think, is knowing what they are good for.
