Keywords: wiki, collaboration, knowledge management, document control, documentation
I often get asked "What is the point of a wiki?" by folks that use MS Word extensively but aren't familiar with wikis. The question is usually followed by “Word has great formatting and we can track changes between versions. I don’t need a wiki.” This article expands on my usual short, verbal answer.
There are several advantages of a wiki over traditional single-user tools like MS Word:
These advantages become compelling once you experience them.
The first, one copy, has no real analogue with traditional tools, nor is its usefulness obvious, but it may be the best feature of a wiki. Say you have to document a quality management system. Maybe your starting task is to compose a list of the processes in your organization with descriptions of each. Of course, this can be done with any editing software. But problems arise if you need input from others.
You write a draft, email it to your colleagues, they edit it with “track changes” and email it back to you and sometimes also to the other folks that you sent the original to. You then must review each contribution and add it to a “master” document. Only, while you are doing that, some of your colleagues have additional ideas triggered by the other flying emails. They email to you and the others again in what can easily become an email stampede. You may or may not even consider these new ideas, as you have to get the new version done and they may be working off an outdated document anyway since others already covered their belated thoughts. After arduous work, you have incorporated everyone’s comments into your new and improved process list and each entry has its short description. You send it again to your team, and again they each edit some bit and send back to you. You once again have to read every document and incorporate it into the master. The more people working on the project, the more coordination work required. Ironically, you may even feel grateful towards those folks that didn’t even bother replying to your original request!
Putting the document on a traditional file server is not much of an improvement. Users copy the file to their machine, edit it, and upload their edited copy onto the server giving it some coded name with date and their initials, such as ProcessList_091220_FC. Pretty soon you have a dozen of these and there is no easy way to tell what each contains or the differences between them.
If you think about the actual workflows in either of the above traditional options from a document control perspective, you can see that every time a document is emailed, or every time a user copies a document from the server to his PC, an uncontrolled copy of the document is produced. Granted, when you are first documenting your system, there may be no need to comply with the requirements of document control. But when do you draw the line? When you do draw the line, the traditional tools become sources of non-conformities (forcibly tolerated) as well as tremendous obstacles to the improvement of your documentation. The above workflows are so bad they discourage collaboration. Users tend to prefer to write everything by themselves and only present their work to others when they are certain it is close to finished. This shortchanges the organization. Throughput is held up at any point where an author gets stuck. And if you are an author you know how often this happens. Also small bits of specialized knowledge of folks only slightly interested in the particular project are never seized. If you’ve ever collaborated on documentation as described above you probably thought at some point that “there has to be a better way”.
Instead of the above traditional solutions, wikis provide a web-based shared space on which everyone can work without copying content to their machines. Say you create your process list on the wiki. Your first draft is a simple numbered list of each process. As soon as you hit save, every one of your colleagues can see your list (without creating new copies in their computers), and edit it. No more email stampede, file proliferation nor uncontrolled copies. But this is only the beginning.
The second advantage is nearly as compelling as the first. With the wiki, you can quickly edit your first-draft list wrapping each item with [square brackets]. This immediately creates new pages and links to these new pages from the list itself. The titles of these new pages are your list items. The new pages are initially blank, but can be edited to contain the descriptions of each process, and the editing may be done by anyone on your team. Right after you save you and your whole team can click on the new links, and write the descriptions of the processes there. Each member of your team can edit what he or she is best qualified for and ignore what doesn't concern them. Everyone immediately sees what has changed.
Traditional tools encourage the creation of large, monolithic documents because many small documents increase the nightmare of file proliferation and email stampeding. With a wiki, the small documents become very useful, as they allow parceling information that does not logically belong together. In groups with some wiki experience, the dynamic of document composition changes completely. Shorter documents are created more often and more naturally. These short documents are easily perfected and can be “included” into more lengthy documents in different ways for different purposes. This “inclusion” is another wiki linking feature that allows one document to include another. For example, you may have your material specifications included in every work instruction where useful, but these specs reside and are editable only in their main location (to which you can get from any of the docs that include it.) Information is in only one place. In another example, "Project Quality Plans" may be composed by simply including the "Control Plans" for each raw material and/or finished part in the project. It is a simple way to create a project-specific plans with aggregation of your standard documentation. Wikis’ “easy linking” allow all of this in a practical manner.
This benefit may not be obvious, but it is huge. In traditional systems, editors are often weary of changing others’ work because such changes can destroy information. With that condition, a potential editor must be certain that his version is better than the previous, and a change risks the document and the editor's reputation. Word’s track changes is an improvement, but without the “one copy” feature, change tracks are often lost in the multiplication of files, or improvement is slowed to a crawl to prevent this loss by coordination. Knowledge ends up not being captured into the documents.
Conversely, a wiki keeps every version of a document in a "document history". Users that gain some familiarity with wikis’ document history lose much of their reluctance to contribute. This promotes continuous improvement of the documentation. Every reader of the wiki content compares this content with his knowledge. If a reader detects a weakness, error or potential improvement in the content, she can change it immediately. Even small improvements get incorporated as users know that their contribution will not damage earlier ones. The changes are immediately available to all, they are transparent (as a comparison with the prior version is readily displayed), and they are reversible with two clicks. The wiki helps capture everyone’s potential contributions.
The history feature also provides accountability, and it produces a built-in ratchet that accumulates good change and that has to be experienced to be appreciated. You may call it Kaizen, Engine of Complexity, CAPA, evolution or other names. It comes free in a wiki.
If you have ever navigated a folder hierarchy created by and shared among several people, you know that such organization is cumbersome at best. File versions multiply. Documents often apply to several branches, but end up filed in only one of them (or elsewhere). And if you need to find a file searching for content, you must rely on the OS's general search feature, which often does not find what you are looking for.
With a wiki, indexes and categories can be created on the fly. There can be multiple hierarchies for any document. Wikis are databases and all content is searchable in an efficient manner. As with the easy linking, the indexes, categories and hierarchies provide for tremendous accessibility and promote the capture and aggregation of your team's knowledge.
Beyond all that, links in the wiki create a "small world network" of documents, where every document is connected to every related document with a single click, and with every document in two or three clicks. This makes accessibility amazingly practical. Your users will consult their documents, and will update them when necessary.
Wikis have many other features and advantages, but the four outlined above are so compelling that, once you experience them, you will never want to compose anything with multiple authors outside of a wiki. Understanding these advantages allows a short answer to the original question: What is the point of a wiki? -- Improvement.
Join a discussion of this article at the Elsmar Cove.
Other articles on wiki use for QMS are available here.
Francisco (Pancho) Castano is the CEO of Geometrica, Inc.