Most documentation goes unread, for good reason: most documentation isn’t worth reading. It is rare to find an organisation where the documentation isn’t a shambles. Most often, you find a mess of documents that are badly written, incompetently edited, at least partly out-of-date, inconsistent, and boring.

An organisation’s documented knowledge should be a core asset. Poor documentation leads to poor performance and poor compliance. At its worst, bad documentation kills people. Good documentation adds value at every point in the business cycle, from start-up to exit. Documentation matters.

So why is most corporate documentation so awful? The first problem is simple lack of competence. Many people are lousy writers. That’s a given. But even worse, most people are terrible at documents. ‘Editing skills’ doesn’t often show up in management resumés. And even with the skills, no-one has the time.

Unless you have dedicated personnel who do nothing else, trying to manage your documentation as a set of manuals is doomed to failure.

You can’t create a good manual unless you can dedicate uninterrupted time to the task. No manager with a day job can do this.

If there are multiple contributors, there is no way to maintain consistency of content across a set of manuals. Even if you start with a vision for what belongs in which manual, that vision won’t survive the rough and tumble of the organization’s real life activities. Something happens; someone creates a new document and adds it to the collection. No-one goes back to review the old documents to remove duplications and superseded content, or to ensure mutual consistency.

The older a manual gets, the more reluctant managers will be to make revisions, for fear of opening a can of worms. Changing a procedure implies a change to a position description which requires a change to the compliance schedule …

Document management systems (like SharePoint) don’t solve these problems. They just motorise them.

The three types of user

Documentation has three types of audience:

• End-users: the people (employees, for the most part) who are expected to follow the documentation;
• Managers: responsible for the content of the documentation; and
• Auditors: the people who verify and validate the organization’s activities.

To be effective, documentation must meet the needs of all three groups. Too often, documentation is prepared with just one group in mind, such as quality system documentation written solely for the use of the auditors.

End-users have to be able to find the information they need very quickly, and must have confidence that the content is correct. People don’t read documentation; they refer to it.

For managers, there are two requirements:

• They must be able to reach consensus on how the organisation is intended to function. The documentation must provide a clear definition of the boundaries and relationships between functions. If managers are accountable for content, they have to know where their accountability begins and ends.
• They must be able to make changes quickly and precisely, without getting caught up in the documentation chores of cross-referencing and indexing.

Auditors must be able to validate and verify the organisation’s activities reliably and efficiently: the documentation must explain what the organisation is aiming to achieve, the standards to which it is subject, and how its activities are intended to comply with those standards. They shouldn’t have to read entire volumes to make sense of what’s going on.

Here are some suggestions for creating documentation that works —

1. Create an integrated body of knowledge

Think of your documentation not as a set of manuals, but as a single, integrated body of knowledge. All the elements of a business have to function together: you carry out procedures to achieve your objectives; your people carry out your procedures; your governance systems control how your procedures are carried out … The elements of your knowledge system should similarly function together.

For example, in traditional documentation there will be procedure documents of various kinds (work instructions, standard practices, operating procedures, and the like). Separately, there will be position descriptions, listing the responsibilities of each position. At best, this separation leads to duplication of content; more commonly there is no coordination at all between the two types of document.

A better approach is to document your procedures with direct reference to the positions involved, and create your position descriptions primarily by cross-referencing the relevant procedures. This has these advantages:

• People have an accurate statement of their responsibilities and direct access to the documentation relevant to those responsibilities;
• Position descriptions are always up to date because they are updated immediately when a procedure changes;
• If a position title changes, all references to the position in procedure documents can be updated automatically;
• People can be notified automatically if there is a change to a procedure for which they have responsibility;
• It reduces the total quantity of documentation; and
• It’s much less work to maintain (a good knowledge management system handle the updates and notifications automatically).

2. Define your elements

Define the types of documentation you will have in your system, such as: policies, procedures, position descriptions, guidelines, governance requirements. The fewer types, the better.

Specify the type of content expected for each type, and set the rules for creating and issuing that type of content. Don’t try to be subtle in your definitions: the subtlety will be lost as soon as people start creating content. If you have trouble defining the difference between two types of document (e.g. work instruction vs. operating procedure), then merge them into a single type.

3. Don’t repeat yourself

There should be a single place for each item of information. Don’t allow content to be duplicated across multiple documents. Apart from the duplication of effort, the different versions will inevitably become inconsistent.

When work instructions have been written by different people at different times, you often end up with sequences of steps repeated in multiple instructions (for example, the paperwork and filing instructions repeated in each of a set of maintenance procedures). Those common steps should be documented separately, in their own document, and cross-referenced from all the other documents. This reduces the total quantity of documentation; more importantly, it standardises your procedures. If the common procedure changes you have just one document to update. (In the example, you don’t need to update every maintenance procedure when the filing step changes.) The more you standardise, the less work you have to do and the less scope there is for error.

In traditional documentation it is common to find a glossary in each document, with the same set of terms defined repeatedly (and often differently). It is better to create a single Definitions section, containing all your defined terms in one place. This ensures consistency across your entire knowledge set; and if you change a definition, you need to make the change in only one place. If your documentation is delivered online (as it should be), your definitions can be linked as popups.

4. Define the accountabilities

Every item of documentation must have an explicit owner, who is accountable for the content and who has final authority for approving the content for use. Approval means certifying that using the documentation (e.g. carrying out the procedure, following the guideline, etc.):

• is legal and safe;
• is consistent with policy;
• is in the organization’s best interests; and
• is the best available way to achieve the stated objective.

The documentation owner is also responsible for reviewing the item regularly. All documentation should be reviewed at least annually. In some jurisdictions this is a legal requirement for some types of document; it is good practice in all cases.

5. Demand management commitment

You can’t expect the employees to be committed to following the documentation unless their managers are equally committed to keeping the documentation up to date. In change programs, updating the documentation is often the last item on the task list: it should be the first.

Disrespect for documentation is contagious. The moment any part of the documentation is disregarded — because it’s out of date or unintelligible or unworkable — then the rest of the documentation becomes suspect. Hold the document owner accountable for this.

6. Hide the document control data from end-users

It is common to see factory-level work instructions containing many pages of control data and half a page of actual content: a page of signatures, document history, references, definitions …

The control information may be essential for compliance purposes, but it has no value to the worker trying to do the job. Organize your documentation so that the control information is available if needed, but is hidden by default.

7. Monitor usage and feedback

Monitor feedback: Every item of documentation is intended for some audience. Check that the audience does, in fact, receive the content and can understand it.

If your documentation is delivered online, check which pages get looked at, by whom, and how often. Like everything else in management: measure your performance.

George Kesteven is a management and documentation consultant specialising in the design, development, and documentation of corporate management systems. http://phrontex.com/