Using a Wiki for Document Control

Using a Wiki for Document Control

by F. Castano, G. Mendez and L. Day

Keywords: Document Control, wiki, ISO 9001, Knowledge Management

Geometrica builds domes like this one at the Hyatt Cancun

Change happens and successful organizations embrace it as a spark for improvement. Yesterday’s “way we do things” may be ineffective today, or perhaps even damaging. Work methods must be quickly adapted to condition shifts and knowledge gains. A key component of embracing change is document control, which lies at the heart of any business management system.

ISO 9001:2008 requires document control: reviewing, updating and approving documents prior to use; ensuring that relevant versions are available at points of use; identifying necessary updates and making changes; and preventing the use of obsolete documents. Easier said than done -- and paper-based systems and typical office software can make it almost impossible: Nearly everyone ends up with obsolete or defective documents stashed in desks, files and email in-boxes. Custom or packaged document-control software is expensive and may not be flexible enough to suit an organization’s needs. In short, controlling documents is a recurring challenge.

Fortunately, there is a new, affordable and flexible tool to tackle this challenge: a wiki. This tool makes document control straightforward, even enjoyable if you have ever attempted other methods. We have written before about how a wiki may be used for a management system (Using a Wiki to Implement a QMS). This paper expands on the prior one, focusing on how Geometrica has used our wiki for document control.

Organize for Availability

The process approach to management aims to break down barriers between functional units in an organization, and to describe how different processes interact. Despite this aim, traditional documentation systems organize documents in a hierarchy, and while interactions may be plain in the process map, they get lost in lower level documents. The structure of documentation in a wiki can be much more flexible. A hierarchical system is indeed available, but it’s also easy to enrich documents at all levels by embedding links and including other documents. These enriched documents map how different processes and activities interact in the most natural way and much more powerfully than with a lone linear hierarchy.

Indices and menus

Geometrica's QMS wiki (which serves as our Quality Manual, and which we use here as an example) ensures that every document is never more than two clicks away. Moreover, any document belonging to the same process as the one currently displayed can be reached in one click.

Accomplishing this requires two indices:

The Main Index lists and links to all of our processes, sales, engineering, procurement, installation, etc. This index appears on the homepage of the wiki, and also as a "primary menu" in the header bar of every document. In this primary menu, the process names are shortened to a two-letter code. When you mouse-over one of these abbreviations, the entire name appears. Clicking on any abbreviation takes you to the homepage for that process.
The Process Index lists all of the documents related to a process. The index for a document's main parent process appears as a sidebar at the right side of the document and shows all the documents within that process. It is possible to access any of these process-related documents with one click.

Links and ‘includes’

Complementing the two navigational tools above are context-relevant links and ‘includes’ embedded in the body of each document. ‘Link’ is a familiar term, but ‘include’, not so much. A link takes you to a new page, but an ‘include’ displays another document within the document you are viewing. For example, it may be convenient to display forms and checklists within more than one Work Instruction. ‘Include’ enables us to have one and only one place where any piece of information is stored. When the information changes, all documents that display that information are automatically updated. Not all wikis have this feature, but we find it indispensable and recommend that you look for it when comparing wiki engines. We use ProjectForum. Many other engines are described in the Wikimatrix.

Many wiki engines have "categories" or "tags" for wiki pages to help keep documents organized and indexed automatically. We did not use this feature -- it's too easy to create too many tags, and the automatic indices were unsorted or too unwieldy to be useful. Instead, our procedure for creating new documents required adding the document manually to its process index and keeping the index sorted in the particular order most useful to us. With a bit more work than tagging, the result was much better because, as the indexes became larger, using them never became more difficult. In fact, the secondary menu on every page of our wiki (on the sidebar) is implemented as an include of the corresponding process index page.

Menus, links and includes have no counterpart in traditional systems, and yet they are the natural way to describe interactions and relationships among processes, activities, and documents themselves. They are also incredibly useful in clarifying or debugging these relationships.

Even with optimal organization, indexing, linking and including, there will come a time when you don't remember what document addresses a particular subject. The search capability built into wiki engines makes it easy to find the document by searching for any text string – way better than shuffling through binders or nested directories!

Make Content Visible and Editable

We post information to our wiki as text using the somewhat limited formatting options in the wiki, instead of prettier word documents or pdfs.

When you post a file to a wiki instead of posting the text itself, a reader must take two extra steps to see the information - downloading the file and opening it in another program. Then he has a file on his computer that essentially is an uncontrolled copy of the document. And an editor must take three extra steps to do his or her work: downloading, opening and uploading the changed file.

In cases where we must post a file because it contains information in formats not available in the wiki, such as CAD drawings or schedules, we always post a screenshot of the information in addition to the source file. This saves readers the extra steps, but still makes the information accessible to the editor.

Optimal Amount of Detail

An on-going discussion among quality professionals is about the optimal amount and detail of documentation in a management system. Too many documents become constraining, difficult to access and maintain, and they end up unused, obsolete, and a source of non-conformities. But relying on fewer and broader documents also has downsides: It can lead to attributing non-conformities to a mirage of "human errors" or "lack of training" root causes when documentation is simply not clear or detailed enough to avoid ambiguity. Still, traditional document control (i.e. paper or office software) favors the minimalist approach because anything else is unmanageable.

With a wiki, documents are always immediately accessible, making it easier to keep them up to date. When tempted to attribute a problem to human error, the relevant document may instead be easily amended to clarify ambiguous instructions or conditions, and thereby avert the presumed human error in the future. Having documents easily accessible for consultation and editing increases the optimal amount of detail in the documentation, and the additional detail comes with less effort.

Control Changes

What are your assumptions about controlling changes? Do you naturally assume that: (1) the change may be worse than the original document; or (2) the change is probably an improvement over the original? Your answer will have a profound effect on the evolution of every document in your system and on the system itself.

In any document, changes must be subject to approval by the person designated as responsible for the document. Most systems implicitly assume that changes can be dangerous, and so the new version of the document is not available until after it’s been approved. Before we implemented the wiki, we made the same assumption. And then we saw how slow it was to revise documents. Drafts languished, waiting for approval, and meetings dragged on as people agonized over every tiny change in wording. In the meantime, other necessary documentation was not even being addressed.

After introducing the wiki, we decided to make the opposite assumption: that any new version of a document would be an improvement over its predecessor. Radical! Fear of chaos reigned in some of us for a while, but we figured that we would at least be able to get the documentation done – and even an imperfect draft document is better than no document at all. We also thought that we would eventually have to institute a more restrictive procedure, but we put that off. What a fortuitous decision that was. We made rapid progress on documentation, and soon our fear was replaced, first by surprise and then by delight.

Improve Continuously

Documents in our QMS evolved very quickly – and evolution is exactly the right name for what happens when you assume that the new will be better than the old.

Every person reading a document judges its quality against his/her knowledge. Our readers are all competent and trained professionals, proud of their work, and vested in the success of our business. When a document applies to the reader's work, potential improvements are often obvious, particularly small changes. If readers are empowered to improve content, they will. During the initial stages of documentation, documents were changed several times a day by several parties. Perhaps more surprisingly, we see cases in which multiple changes are done successively by one person. Despite the many changes, rollbacks to previous versions were extremely rare. And readers of any document can always highlight the changes between the current and prior versions with a click.

We still review changes, of course. The system does not eliminate review and approval, it simply puts it into a different, parallel thread: Every change to a document is logged, along with the author and the date. The responsible person is then notified by RSS or email of the changes to the document, and he/she is charged with reviewing and approving them – and this can be done periodically, when it is convenient for the reviewer.

The ability to make changes easily, together with the knowledge that changes are logged, brings out the very best in the team and discourages malicious or risky edits. The wiki allowed the process of documentation to accelerate beyond what we thought possible.

Several variables may influence whether the above approach works for your organization: group size, maturity of documentation, and risks associated with the accuracy of the documentation. Our contributing group was small (about 3 dozen), the documentation young, and the risks mild. Different circumstances in other organizations may compel restricting creativity a bit, perhaps using subwikis for each process and restricting editing access to the process documents to a select team. But even with our setup, in practice, once a document has been fairly well developed, changes tend to take place through our Corrective Action / Preventive Action process and its issue-tracking database.

So to summarize our experience, documentation improved rapidly when we mixed the following four ingredients:

Competent and empowered individuals with a stake in improvement,
Easy access and editing,
Presumption that the changes our team makes are improvements, and
Automatic version tracking.

Document Control Procedure

Geometrica has three related procedures for document control: [GP: Document Control] deals with control of internally generated documents for the management system, [GP: External Document Control] for externally generated documents, and [GP: Records Control] for documents that evidence compliance with clients' and regulatory requirements. The following is an excerpt from the first of the above. Green words represent links in our wiki:

To compose a new document follow the GP: New Documents procedure.
Publishing Documents:
- The Quality Manual and all QMS internal documents (except certain Records) are published in this wiki. All Geometrica employees have access to the wiki.
- Documents in the wiki are updated automatically when edited. The wiki saves the latest version of the document and every prior version for at least the last 6 months.
- Users of hard-copies of QMS documents must subscribe to the document RSS feed following the procedure described in WI:Monitoring Documents. Every time they are notified of a change in the document these users must print and replace their hard-copies.
Document Updates:
- Every edit to a QMS document shall be done on the wiki.
- Every person with access to the QMS wiki is authorized to edit any document in the wiki to correct or improve it.
- If someone is not certain that a change will result in correction or improvement, then instead of editing the document, he or she shall report the possible change as a Request for Corrective Action following the GP: Continuous Improvement.
- Every edit to a QMS document is incorporated into the QMS immediately and automatically.
Review, Approval and Re-approval: The Owner of a document shall subscribe to the RSS feed of the document in accordance with WI: Monitoring Documents, and shall review any change made to the document as soon as possible after a notification. Approval is by default. If the Owner disagrees with a change, s/he shall roll-back the document to the version before the change, and in this case, the rolled back document takes effect immediately.
Identifying Changes: Changes between versions are identified by clicking the versions link on the document.

Conclusion

Wikis make controlling documents almost automatic, and the optimal amount of documentation in the management system is no longer set by the practical constraints of traditional paper or electronic documentation. Our experience was an eye-opener to everyone involved. Placing documents in a wiki transcends document control and becomes effective knowledge management. We believe that if you trust your team and put up your documentation in a wiki, you too will see improvement far beyond your expectations.

About the authors:

Francisco (Pancho) Castano, PE, is the CEO of Geometrica, Inc.
Gerardo (Gerry) Mendez, has a Masters degree in Administration and is the Quality Manager for Geometrica.
Linda Day is the principal at Day Creative, Houston