The audit passed. The process had been dead for a year.
The audit closes on a Friday with no findings. Every procedure in scope sits in the document library: signed, versioned, formatted to the template, reviewed within its validity date. The auditor ticks the last box and leaves.
Three weeks later, a supplier failure lands on the management agenda as a surprise. It should not have been one. The risk procedure requires a quarterly review of exactly this kind of exposure. Someone opens the risk register to check. Its last entry dates from the kick-off workshop, fourteen months earlier.
Nobody did anything wrong in the narrow sense. The procedure existed, and the audit confirmed that it existed. What nobody had checked, because nobody is ever asked to check it, is whether the procedure had ever run. Versions of this scene recur across organisations of every size and sector, and they all point to the same uncomfortable fact. A signed procedure is evidence of intent, not of operation: a procedure is a document that says what should happen, while a process is that procedure actually running, with an owner, a cadence and a forum that acts on what it produces.
A procedure is a document; a process is a procedure that runs
A procedure describes what should happen: steps, roles, inputs, outputs. A process is that description plus everything that makes it happen without anyone having to remember to start it. In practice, that means five things: a named owner, a cadence that actually fires, data that feeds it, people trained to run it, and a forum that acts on what it produces.
Remove any one of them and the procedure keeps its shape on paper while the process quietly stops. An owner without a cadence produces good intentions. A cadence without data produces a meeting. Data without a forum produces a report nobody reads.
This distinction matters because organisations measure the first and assume the second. A document library is easy to count. Running processes are not, unless someone goes looking for them.
Audits check the library, so the gap stays invisible
Most governance checks look for the artefact. Is there a procedure? Is it approved? Does the library hold the current version? Those questions have clean answers, and clean answers make for clean audit reports.
The question that matters is harder to evidence: when did this last run, and what happened as a result? Few audits ask it. Document control then becomes a proxy for process control, and the proxy keeps passing long after the thing it stands for has died.
The incentives point the same way. Quality functions report library completeness as their headline number. Managers feel relief when the box is ticked. Auditors work to a scope that names documents, not outcomes. Nobody in that chain gains anything from discovering that a well-written procedure has never been used.
Procedures bought from outside arrive without owners
The gap is widest where the people meant to run a procedure never wrote it. Organisations outsource procedure writing for understandable reasons. The topic is specialised, the industry or regulatory knowledge has to be current, and the internal team has neither the expertise nor the time. Somebody usually finds the budget without much argument, because a set of professionally drafted procedures feels like progress you can point to.
What almost nobody budgets for is the handover. The consultant delivers the document set, the project closes, and the documents land in the library with roles named but nobody actually holding them. Less experienced managers often assume that owners will emerge on their own, and that whoever showed the most interest during drafting will naturally pick the process up.
They do not. Ownership by implication does not work. The person who attended the workshops was a contributor, not an owner. Without a decision that names them, they have no mandate to convene anyone, no time carved out of their week, and every reason to treat the procedure as someone else’s job.
A process needs an owner appointed in writing, by someone with the authority to appoint, at the moment the documents arrive. Discovering one later by elimination rarely happens at all. Bought procedures are not the problem. Bought procedures without a handover are.
Process ownership is part skill, part disposition, part permission
Naming an owner is necessary. It is not sufficient. Training can cover the mechanics of ownership well: how to set a cadence, which data to watch, when to escalate, how to run a review that ends in a decision rather than a discussion. A few focused days teach most of it.
What training cannot install is the drive-through habit. That is the instinct to close each loop rather than report on it, and to chase a missing input before the review instead of noting its absence during it. Some people bring that disposition with them. Others never develop it, however good the course.
Neither skill nor disposition survives without permission. An owner needs protected time, a forum that acts on what they bring, and a sponsor who backs them when the process becomes inconvenient. It is the same split between what a course can teach and what only an organisation can grant. Appoint people who already close loops, teach them the mechanics, and give them the standing. Skip any one of the three and the procedure drifts back to paper.
Five questions tell you whether a procedure is alive
Any manager can test a procedure in ten minutes without reading it. Ask five questions, and accept only specific answers:
- Who owns it? A name, not a function or a committee.
- When did its cycle last run? A date, not “regularly”.
- What data fed that last run? A source someone can open.
- Who has been trained to run it, and when? People, not “the team”.
- Which forum acted on its last output? A decision someone can point to.
One answer of “nobody”, “never” or “not sure” means you are looking at a paper process. Two or more, and the procedure is effectively decorative, however good the document is.
The test is deliberately crude. Its value is that it moves the conversation away from whether the procedure is well written and towards whether it is alive. Most organisations have never put that question to their own library.
Paper processes are expensive precisely because they look finished
A missing procedure is a visible gap. Somebody notices it, raises it, and eventually fills it. A paper procedure does more damage, because it closes the gap on paper and keeps it open in practice. Leadership sees a document set and assumes the topic is covered.
Strategy deployment is the classic case. There is a documented cascade from long-term plan to annual departmental objectives, and no review that ever checks whether the objectives moved. That is exactly the gap strategy execution exists to close as a discipline. Risk management is another case: a register filled once at a workshop and never fed again.
In both, the organisation believes it has a capability it does not have, and it discovers the difference at the worst possible moment. That false comfort is the real cost. It is also why paper processes survive so long. Nothing about them looks broken until something breaks.
Measure the gap before you write another procedure
When governance feels weak, the instinct is to write more: a new procedure, an updated template, another policy. That usually adds paper to a library that is already ahead of reality.
A better first step is a documentation-versus-reality review. Take a sample of the procedures the organisation genuinely depends on — strategy deployment, risk, change control — and look for evidence of the last real cycle. Map what runs, what half-runs and what exists only in the library. A review like this takes weeks, not months, and the map it produces is usually worth more than any new document.
The fix it points to is often counter-intuitive: fewer procedures, actually activated. Activation, in turn, is not an administrative task. Someone with authority has to decide that a process will run, name its owner and give it a forum. It is the same founding discipline a PMO needs before its first hire, applied to every process the organisation claims to have.
An organisation is governed by the processes that run, not by the ones it has written down.