Most organizations have a terrible time with their policy and procedure documentation. Most corporate documentation is ugly, boring, too long, and poorly organized. And usually, somewhat out-of-date.
The core problem is the idea that documentation means documents. This is a misconception. Documentation is about knowledge. The documentation task is to manage that knowledge: to determine who needs to know what, to ensure that they do know it, and to verify that the knowledge communicated is complete and correct.
Documents ─ if you use them at all ─ should be an output, not a storage medium. For some purposes documents are a good way to deliver information to end-users. But trying to manage corporate knowledge as a library of documents obviously doesn’t work.
Look at the evidence: when was the last time you saw an organization with good documentation?
There was a time when documents were effective, back in the golden ages when organizations had typing pools and could afford a dedicated documentation team that did nothing else. Those days are long gone. In a modern, high-pressure, rapidly-evolving organization, the practical challenges of maintaining documentation as ‘a library of documents’ are overwhelming.
Documents don’t work. Here are some of the reasons:
Organizations are complex. By definition, the elements of an organization have to function together, as a whole (that’s what organization means). But traditional documentation, in practice, treats the elements independently, in separate documents.
The organization changes continually, as does the social and regulatory environment in which it operates. Every change implies a documentation update. And no change is wholly isolated: there are always ripple effects across the organization. A policy changes: what procedures are affected by the change? A procedure changes: is it still consistent with policy?
No-one is in a position to exercise editorial control over the set of documents as a whole. An individual manager is doing well to maintain the documents for their own area of responsibility; they don’t have the time or authority to be working on anyone else’s documents.
New documents get added; old ones don’t get removed. No-one is saying If you add this document to the library, section three of that document is now obsolete.
The result is overlaps, gaps, and contradictions, and a growing accretion of orphaned and obsolete documents.
Traditional procedure documents are trying to do several things at once:
Each of these objectives targets a different group of readers. By combining the content required by each group into a single document, each user group is served badly: most of the content is irrelevant to most users.
The primary objective of documentation is to deliver information to end-users, to the front-line employees who are expected to work according to the documentation. Everything else in the documentation — the policies, the governance framework, the ISO standards — is there to support that objective.
It’s common to see procedure documents with statements like: the purpose of this document is to inform and train employees...
Informing and training your employees is a fine thing to do. But that’s the writer’s objective, not the reader’s.
Controlled documents are bloated with large amounts of content that has no value to the end user. Control is important, of course; but you don’t need to inflict the control metadata on the end user. End users are not going to check the approval signatures, or read the document history, or look up the references.
Converting a library of documents to a knowledge management system typically reduces the total page count by over 65 percent. That’s a measure of how much duplication and garbage is typically found.
The organization’s rules for what content belongs in which documents, if stated at all, tend to be vague at best; and with multiple managers contributing content, duplications and overlaps are inevitable. Everyone wants to be thorough. Policy documents include procedural instructions; procedure documents repeat policy statements. And the HR team may well create its own set of documents for training and induction purposes.
In industrial settings, it’s common to see great collections of work instructions or operating procedures, all containing more or less identical sets of definitions and safety instructions. This is poor practice.
Typical work instruction: seven pages of document, half a page of end-user content
Typical work instruction: seven pages of document, half a page of end-user content
In some quarters there’s a tendency to include content, particularly in relation to safety, specifically so the organization can defend itself in the event of an incident: Look, we did tell the employee — here it is in the document. It’s not our fault if they didn’t read it.
Not only does this create bloated and unusable documents, these days it generally doesn’t work anyway. If there’s an incident, the test is to ask employees what they actually knew, not to look at what the documentation ostensibly told them. If they didn’t read the document, that’s on you, not on them. “Your safety system was just ink on paper,” as a judge put it in a recent case, fining the company $1m for failing to inform the (now deceased) employee.
When you talk to managers about these problems, most tend to nod in sad resignation, as if lousy documentation were an inevitable feature of modern management. Most managers have never seen good documentation, and many seem unwilling even to countenance the idea that something better than a library of unread documents is possible.
As they say in sport: always change a losing game. Documentation can be done well. Just not with documents.
