Documenting Standard Operating Procedures

What a procedure is for

A standard operating procedure, often shortened to SOP, is a written description of how a routine task is carried out. Its purpose is simple: to let a competent person do the task the same way each time, without relying on someone’s memory. Good procedures help with training, cover for absences, consistent quality and, where it matters, evidence that work follows agreed rules.

Procedures only help if people use them. A document that is out of date, buried or unreadable becomes a formality that nobody trusts. The following sections focus on keeping procedures usable and accurate over time.

Decide what deserves a procedure

Not every task needs one. Writing and maintaining documents takes effort, so it is sensible to prioritize. Tasks that commonly justify a written procedure include those that:

• are performed often by several people
• are costly or risky when done wrongly
• involve several teams or hand-offs
• are subject to rules that must be shown to be followed
• are done rarely, so people forget the steps

Highly variable or creative work is usually a poor fit for step-by-step documents. For that kind of work, guidelines and principles tend to serve better than rigid steps.

Write for the person doing the task

The best source for a procedure is the person who actually does the work. A manager or analyst who writes it from a distance often describes the ideal version, not the real one. A useful approach is to observe or interview the people doing the task, draft the steps, and then ask someone who has not done the task to follow them. Where they get stuck shows where the text is unclear.

Practical writing habits include:

• Start each step with a verb: “Check the order number against the purchase order.”
• Keep one action per step, in the order it happens.
• State who does the step if more than one role is involved.
• Use plain words and define any term that a new person would not know.
• Include the reason where it is not obvious. People follow a rule more reliably when they understand it.
• Say what to do when something goes wrong or does not match, instead of leaving the reader stranded.
• Use screenshots or diagrams only where they truly help, and remember that they go out of date quickly when software changes.

The tone of good procedures matches the advice on policy and standards writing generally: short, direct and written for the reader.

A simple structure

Consistency between documents makes them easier to find and read. A typical layout includes:

1. Title and identifier. A clear name and a reference number or code.
2. Purpose. One or two sentences on why the procedure exists.
3. Scope. What it covers and what it does not.
4. Roles. Who is responsible for performing, checking and approving.
5. Steps. The numbered instructions.
6. Exceptions and escalation. What to do when the normal path does not work, and whom to ask.
7. Related records. Forms, templates or systems used.
8. Version information. Version number, date, author, approver and next review date.

A template used across the organization saves effort and helps readers. Beyond a certain length, though, a procedure becomes hard to follow. If a document runs to many pages, consider splitting it or turning part of it into a short checklist.

Ownership

Every procedure should have a named owner who is responsible for its accuracy. Without an owner, nobody notices when a step changes and nobody feels entitled to update it. The owner is usually the manager of the process or someone close to it. System ownership roles and process owners are worth distinguishing, since the person who runs a software system may not be the person who knows how the business process uses it.

Approval is a separate matter. Procedures that carry compliance or safety significance usually need review by a second person before they are published. For lower-risk tasks, lighter approval keeps the process moving.

Where to store them

A procedure that cannot be found does not exist for practical purposes. Good storage has a few features:

• One authoritative location. Staff should know where the current version lives. Copies saved to personal folders or printed and pinned to walls drift out of date.
• Searchable and well named. People look for answers by task, so titles should use the words they would use.
• Access control. Anyone who needs the document should be able to read it, but only the owner and approvers should be able to change it.
• Version history. The system should record previous versions, who changed them and when.

Dedicated document management systems can provide these features, but a well-organized shared folder or wiki may be enough for a smaller organization. The tool matters less than the discipline of using it.

If printed copies are necessary, mark them as uncontrolled, with a note that the current version is online.

Keeping them accurate

Procedures usually go wrong not when they are written but afterward. Common reasons include a system update that changes the screens, a reorganization that changes who does what, or small shortcuts that become habit. Practices that help include:

• Review dates. Set a regular review interval for each document, such as annually, with shorter intervals for risky or fast-changing work. The right interval depends on the task.
• Change triggers. Update the procedure whenever the process, system or responsibilities change, not only at the scheduled review. Tying updates to IT change control or project completion helps.
• Easy feedback. Give users a simple way to report errors, such as a comment link or a named contact. People who use a procedure daily notice problems first.
• Spot checks. Occasionally watch someone do the task and compare it with the document. Differences point either to a bad procedure or to a training problem.
• Retiring old documents. Remove or archive procedures that no longer apply, and keep a record. Old versions should be kept as long as records rules require, as described in data retention schedules.

Training and rollout

Publishing a new procedure does not mean people will follow it. Tell the affected staff what has changed and why, and give them a chance to ask questions. For significant changes, short training or a walkthrough helps. If staff regularly depart from a procedure, ask why before assuming they are careless. The procedure may be impractical, and a standards exception process can give a recorded route to adjust it.

Common mistakes

• Writing the procedure to satisfy an audit, not to help the worker.
• Making documents so detailed that nobody reads them.
• Leaving out the exceptions that cause most of the real trouble.
• Having no owner and no review date.
• Storing several versions in different places.
• Treating the document as finished once it is published.

Well-kept procedures are modest, current and trusted. A small set of accurate documents for the most important tasks generally serves an organization better than a large library nobody maintains.