Insights / Checklist / SOP optimisation and continuous improvement
ChecklistWhat makes a good SOP: a pre-publication test
A short test helps you judge any procedure before it is published: purpose, roles, inputs, usability and a named owner with a review date.
Most organisations review procedures for accuracy and sign-off, then publish them. Fewer check whether the procedure will actually work for the person who has to follow it. A short test, applied before anything is published, catches most of the problems that make SOPs ignored or misread.
Use the checklist below as a gate. If a procedure fails more than one or two items, send it back for revision. Each section explains why the test matters and what a good answer looks like.
Is the purpose clear?
The reader should know why the procedure exists. People follow steps more carefully when they understand the risk the steps control. A procedure that opens with three lines on purpose and scope saves many questions later.
- One or two sentences explain what the procedure achieves and why it matters.
- The scope says when the procedure applies and when it does not.
- Key risks are named: safety, quality, customer, financial or regulatory.
- The title matches the words people use for the task.
Are roles and inputs clear?
State who does what, with which inputs and tools. Ambiguity about roles is one of the commonest reasons steps are skipped: each person assumes someone else does them.
- Every step names the role responsible, not an individual’s name.
- Handovers between roles are explicit, including what is passed on and how.
- Inputs are listed: documents, data, materials or information needed to start.
- Tools, systems and equipment are named, with versions or settings where they matter.
- Approvals state who approves and what they are checking.
Can someone new follow the steps?
A procedure is only as good as its weakest step. The best test is to give it to someone who has never done the task and watch. If that is not possible before publication, check the writing against these points.
- Steps are numbered and in the order they happen.
- Each line holds one action and starts with a verb.
- Critical points describe what good looks like, so people can check their own work.
- Photos, diagrams or screenshots support any step that is physical or visual.
- Exceptions and rare cases are moved to a separate section or linked reference.
- A new starter or colleague from another team has followed it without help.
Will people find it when they need it?
A correct procedure that sits in an unvisited folder has no effect on the work. Check where it will live and how people will reach it at the moment they need it.
- The procedure is available at the workstation or inside the system where the task is done.
- It can be found by the name people use, not only by a document number.
- Older versions are withdrawn, so nobody follows an outdated copy.
- People know how to report an error or suggest an improvement.
Is there an owner and a review date?
Procedures without an owner and a review date decay. Processes, systems and suppliers change, and a document that was right last year may now be quietly wrong. Ownership is what keeps it current.
- A named owner, ideally someone close to the work, is accountable for accuracy.
- A review date is set, typically every twelve months or sooner for high-risk tasks.
- Triggers for an early review are listed: system change, incident, audit finding or process change.
- Version history records what changed and why.
A quick scoring rule
Treat the purpose, roles and ownership items as must-haves. A procedure can be published with a minor usability gap if it is scheduled for testing, but not without a clear purpose, clear roles and a named owner.
Putting the test to work
Add this checklist to your document approval workflow so reviewers use it every time. Run it across your ten most-used procedures first; the gaps you find will show where to focus. Then make it the standard for every new or revised SOP before it reaches the people who use it.
Expect the first pass to be uncomfortable. In a typical review of an established procedure library, the most common failures are missing owners, steps that bundle several actions into one sentence and procedures that still describe a system screen that changed two upgrades ago. None of these is hard to fix once it is visible. The value of the test is that it makes the gaps visible before a new starter or an auditor finds them for you.
Keep a simple log of which items fail most often across your library. If the same gap appears again and again, the answer may be a better template or a short briefing for authors rather than more reviews.
Source: Intelliversal analysis.
