Writing a quality management procedure that people will actually follow

Most written procedures are not used. They are produced, filed, referenced in an audit, and then ignored by the people who do the work, who have their own version in their heads. That gap is not laziness. It is usually a drafting problem, and it is fixable in an afternoon.

This page is about writing one document: a procedure that a competent person who has not done this task before can follow to a correct result, without finding you.

What to take away

Decide who it is for, and say so at the top

A procedure written for everybody is written for nobody. Three readers want incompatible documents from the same task.

The person doing it for the first time needs every step, including the ones that are obvious after a week. The person who does it daily needs a reminder of the order and the easily forgotten items, and will not read prose. The person checking afterwards needs to know what evidence should exist and where.

Pick one. Write the others separately if you need them, or accept that the experienced reader will skim. A single line at the top saying who this is for and what they are assumed to already know saves more confusion than any amount of formatting.

It also tells you what to leave out, which is the harder half of the job. The general point about writing for a named reader rather than an imagined one runs through operating processes as well.

The anatomy of a step

A usable step has five parts, and most drafts carry two of them.

The rule that fixes most drafts is one action per step. "Check the order and enter it into the system" is two steps wearing one number, and when someone is interrupted between them, the checking is the part that disappears. Splitting it costs a line and buys you a place to stop.

Passive voice is the other reliable defect. "The form is reviewed" leaves the reviewer unnamed, which is fine until two people each assume the other does it. Name a role, not a person, so the document survives someone leaving.

Decision points are where procedures actually fail

A linear list of steps is easy to write and rarely matches the work. The interesting parts are the forks: this or that, depending on something.

Three things a decision point needs.

The question, stated as a question. Not "handle exceptions appropriately" but the actual thing being asked, in the words the reader would use.

The observable that answers it. Something the reader can look at right now. If the answer requires knowing what happened three weeks ago in another team, say where to look.

Both branches, written out. The second branch is the one that gets omitted, and it is the one the reader is standing in when they open the document.

When a fork truly needs judgment that cannot be reduced to an observable, do not pretend otherwise. Name the deciding role, then give the reader two or three considerations that go into it.

A procedure that says "escalate to the shift lead, who weighs the delay against the rework cost" is honest and usable. One that says "use appropriate discretion" hands the problem back to the person who had it.

Write the abnormal path first

Nobody reads a procedure when everything is going normally. They read it when the system rejected the entry, the part does not fit, the customer asked for something the form does not have, or the person who usually does this is away.

So the abnormal path is not an appendix. It is the reason the document exists. For each step, ask what happens if it cannot be completed, and write that down: who to tell, whether to stop or continue, what to record, and how long to wait before the answer is that nobody is coming.

The British Health and Safety Executive's guidance on procedures makes the related point that a procedure people cannot follow as written gets replaced by an informal practice, which is then invisible to everyone above the work.

Where an entire class of abnormality exists, that is a separate procedure, not a bullet. A rule of thumb: if the exception path is longer than four steps, it wants its own document with its own trigger.

Test it on someone who was not there

Every procedure reads perfectly to its author, because the author supplies the missing steps from memory without noticing.

The test that works costs an hour. Give the draft to a competent person who has not done this task, ask them to do it exactly as written, and watch without helping.

Note every moment they hesitate, ask a question, or do something the document did not say; those are your defects. Do not explain; explaining repairs the reader instead of the document.

Run two variations, giving one to someone who does the task daily and asking where the document is wrong; their answer reveals the real practice.

Give the other to the person who receives the output, and they will tell you which steps produce what they actually need. Interview technique for both is in operating processes questions.

Ownership, versions, and knowing when it is dead

A procedure with no named owner rots at a predictable rate. It stays accurate until the first system change, then becomes half accurate, and then becomes something people cite when they want to block a request.

The minimum that keeps one alive: a named owning role, a date of last review, and a rule for when it gets looked at again. Tie review to an event rather than a calendar where you can.

"Reviewed whenever the intake form changes" catches the thing that invalidates it. An annual review catches it up to eleven months late.

Retirement is the part nobody plans. When a procedure describes a task that no longer happens, delete it instead of leaving it filed. A mostly stale document library teaches people not to trust documents, and that is expensive to reverse.

What counts as a document worth keeping is covered in the wider quality management view. The shape of recurring checks around it is in quality management checklist.

Where the rules are not yours to write

In regulated work, the form and the content of procedures are set by somebody else, and general drafting advice does not override that. Requirements differ by industry and by jurisdiction, and they change.

Look up the current text from the body that sets it rather than from any summary, including this one. One example: the US Occupational Safety and Health Administration publishes process safety management material. It is worth reading for the shape of the obligation even if your work sits well outside it.

Common questions

How long should a procedure be?

As long as the task, and no longer. Length is a symptom rather than a target. If a document runs past a few pages, check whether it is one procedure or several that share a folder, and check how much of it is background that the reader does not need at the moment of doing.

Should the people doing the work write it?

They should draft it, because they know what actually happens, and someone else should edit it, because they cannot see their own assumptions. The combination works better than either alone. What does not work is a document written entirely by someone who has never done the task.

What if the real practice is better than the written one?

Then the document is wrong and should be changed, unless the real practice is skipping a control for a reason the skipper cannot see. Find out which before you do anything. The gap itself is useful information, and treating it as a discipline problem guarantees you stop hearing about it.

We have no procedures at all. Where do we start?

With the task that hurts most when it goes wrong, or the one a single person holds in their head. Not with a documentation program. One good procedure that gets used is worth more than a set nobody opens, and it teaches you what your house style should be before you commit to one.