How to create a process documentation system
How to build a process documentation system that is still true in two years: a process inventory with named owners, review intervals set from the rate of change, and a dated defect for every lagging map.
A process documentation system keeps a library of process documents true over time: an inventory with one named owner per process, a review date that reaches that owner, and a rate of decay somebody measures.
The short version
- Start with an inventory, not a document: one row per process, one owner, one due date.
- Build the meta-process before the first document: creation, approval, publication, training, retirement.
- Across a library, the average document spends half its review interval out of date.
- A change that reached production before its map is a documentation defect with a date.
- A review that changed nothing still owes the register a dated entry, or accuracy looks like neglect.
The system is the meta-process, not the template
Any organisation can produce fifty process documents, and several have done it twice. What a documentation system settles is not how they are written but what will be true of them in two years. The arithmetic is unkind. If nothing but the calendar forces a revisit, a change made the week after an annual review goes unnoticed for most of a year, and across a library the average document spends half its review interval describing work that has moved. An authoring template has no bearing on that figure.
So the first artefact is not a document. It is an inventory: every process the organisation runs, one row each, with one named person accountable for its description, the level it is documented at, and a review interval. Then comes the meta-process: the route by which process documents are created, approved, published, trained on and retired. Without it, every document is maintained by whoever happens to remember it, and the rule for a process that changed before its map did is never written down.
What follows is that meta-process itself rather than one of the processes it governs. "Confirm the accountable policy owner" is the second row, before any analysis begins. The "No change" exit from "Change to the policy required?" reaches "Review recorded, new date set": a review that rewrote nothing and still moved the date, which is the entry an ageing library never has. And "Redraft" sends the approval decision back to "Draft the revision in tracked changes".
Build the meta-process in five stages
The meta-process a library runs on, not one of the processes in it. Read it for what the register is owed after a policy has been published.
An owner before an analysis
The trigger is a calendar date or an event, and the row after it confirms the accountable owner before anything is read. "Change to the policy required?" then treats "No change" as a real ending: "Review recorded, new date set" is what keeps a register honest about a document's age.
Consultation is not a courtesy
Drafting in tracked changes, then the affected business areas, then legal and regulatory fit. "Employee consultation required?" routes to the representatives, and "Not agreed" ends at "Referred to formal negotiation": an ending outside the library's control, drawn rather than assumed.
Tiering keeps the board free
"Which approval tier applies?" splits three ways into the board, the executive committee and the policy committee, and all three converge on "Approval decision?". Its "Redraft" exit points back at the drafting row; "Rejected" shelves the revision and leaves the previous version in force.
Publication writes back to the register
The register is written from two rows: "Publish the new version and announce it" and "Supersede and archive the old version". The new revision, the publication date and the next review date all come from them. A publishing step that writes back to nothing leaves a register ageing on its own.
The obligations after publishing
A materiality decision routes training, attestation is recorded against the affected staff, and "Refresh the exception and waiver register" catches waivers granted against clauses that no longer exist. The system ends at "Revised policy in force" rather than at publication.
How it works
Write the process inventory before any map
List every process the organisation runs, one line each, with a named person accountable for its description, the level it should be documented at, and how critical it is. Expect the list to be shorter than feared and the ownership column to be the argument. Nothing else can be built while that column has gaps.
Set each review interval from the rate of change
Take the interval from how often the process actually moved over the last two years rather than from a policy default: three changes earns six months, no change in five years earns two. Record the interval, the next due date and the documented level in the inventory, so none of the three is re-argued at every revision.
Build the meta-process as a chart first
Before documenting any real process, put your own documentation route into rows: what triggers a review, who confirms the owner, who is consulted, who approves, how it is published and trained. Type the stages into the Box text column and join them by row number in the Line to column. Every later document inherits from it.
Put the approval tier on the chart as a decision
The routing row takes Decision in the Shape column, with the tiers written into Line text against the numbers in Line to, so a revision's route is known before drafting starts. Use the Horizontal lane column for the phase and the Vertical lane column for the owner, so the diagram shows that a policy office and an approval body differ.
Draw the redraft loop as a backward number
An approval that sends work back is a row number pointing at an earlier row, not an arrow somebody adds to the drawing afterwards. Because the Line to column holds data, that loop survives inserting a step above it. A diagram showing only forward motion describes an approval body that has never once disagreed.
Audit the library against its own dates
Each quarter count four figures: documents past their review date, documents with no named owner, documents whose process changed before its map did, and reviews recorded with no change. The last is health. Book the next count in the inventory before closing this one, because a count with no next date lapses and the library resumes decaying.
Mistakes to avoid
Running documentation as a project
The project delivers the library, disbands, and decay begins the week it closes. Documentation is a standing function with an owner and a budget line, or it is a snapshot of one quarter that ages badly.
Addressing the reminder to a department
"Owned by Operations" means the due date is delivered nowhere. A department has no calendar and no inbox that answers, so the reminder is generated, addressed to a function, and read by no one in particular.
Reviewing only what is on the shelf
A review cycle can act on the list it has, so the processes with no document at all are the ones it never surfaces. Build the inventory from the work the organisation does, not from the folder of documents that exist.
Redocumenting weeks after the change
A process that changed in March and was redocumented in May was wrong for eight weeks, and nothing in the library records that. Log the interval with dates; the pattern across those intervals shows where the system leaks.
Build your own documentation system
Open the policy review example as your own chart, then set the owner, the approval tier and the review interval your library will run on.
Related guides
Frequently asked questions
What is a process documentation system?
It is the set of rules and roles that keeps a body of process documentation true, as distinct from the documents themselves: an inventory with one named owner per process, the level each is documented at, a review interval whose due dates reach those owners, a measured rate at which the library falls behind the work, and a route for creating, approving, publishing and retiring a document. The template matters least. The test is what the register says about a document nobody has touched for three years.
What should a process inventory contain?
One line per process: the process name, the owner as a person rather than a team, the level it is documented at, its criticality, the location of the current version, and the dates it was last reviewed and is next due. Two further columns earn their keep quickly: the systems the process runs in, which tells you what a migration will invalidate, and the clause it exists to satisfy, which tells you what an auditor will ask to see. The inventory comes first because every later decision is a query against it.
Who should own a process documentation system?
One person, and not the person who owns the most documents. The system owner holds the inventory, the meta-process and the register of review dates; each document owner holds content. Merging the two produces the familiar failure where every revision queues behind the one individual who understands the system, and the queue gets reported as a resourcing problem rather than a design one. Half a day a week carries a library of fifty processes, provided the reminders are automatic and every owner is a name.
Where should process documentation live?
Wherever the inventory says, which is why location is a column in it, not a decision taken once for the whole library. A quality management system, a wiki and a shared drive can each hold a current version; none of them can tell you which processes have no current version at all. So the test is not which platform but whether every row in the register names the place its readers are sent, and whether arriving there produces the revision the register claims. A process with no row is invisible to any platform choice.
