Skip to content

Keeping standard operating procedures alive: owner, review date, one-page format and retiring stale ones

6 min read
Operations
Keeping standard operating procedures alive: owner, review date, one-page format and retiring stale ones

Key Takeaways

  • 1A procedure without a named owner and a review date is already going out of date
  • 2One page is enough; longer documents are rarely read and almost never updated
  • 3Trigger a review when something changes, and also on a fixed calendar
  • 4Mark every document with its status so colleagues know whether to trust it
  • 5Retire stale procedures openly instead of letting them linger

Many small companies have a folder of procedures. Someone wrote them during a burst of effort, perhaps before an audit or when a new colleague joined. A year later the tools have changed, two steps have moved to a different person, and the folder is trusted by nobody.

The problem is rarely the writing. It is that nobody was given the job of keeping the document true. A procedure that is not maintained is worse than none, because colleagues follow it and get a wrong result.

Why procedures go stale

  • No owner. Everyone assumes someone else will correct it.
  • No trigger. Nothing reminds anybody to look at it again.
  • Too long. A twelve-page document is painful to edit, so small changes are skipped.
  • Hidden location. If people cannot find the current version, they keep their own copies.
  • No way to say "this is old". Outdated and current files look the same.

Step one: one named owner

Each procedure gets exactly one owner, a person and not a team. The owner is usually the person who does the work most often or is accountable for its result. The owner does not have to write every word, but they answer the question "is this still how we do it?"

Add a deputy for key procedures, so that a holiday or a departure does not leave the document orphaned. If you have just handled an internal tool whose author left, our article on who owns an internal tool after its author leaves describes the same problem from the tool side.

Step two: a one-page format

A short fixed format is easier to write, read and update. A page with these headings works for most routine work:

  1. Purpose: one sentence on what this procedure achieves.
  2. When it applies: the trigger, for example "a new supplier is approved".
  3. Steps: five to ten numbered actions, each starting with a verb.
  4. Who does what: names or roles for the steps.
  5. Exceptions: what to do when something does not fit, and whom to ask.
  6. Header data: owner, deputy, last reviewed, next review, status.

If a procedure needs more than a page, it is often two procedures. Split it, or move background detail into a linked note and keep the steps on the page.

Step three: a review date on every document

The "next review" date is the most important field. Choose it by how fast the work changes:

  • Every 3 months: procedures touching tools or people that change often.
  • Every 6 to 12 months: stable routines such as month-end tasks or onboarding.
  • Only on change: rare, low-risk procedures, but still with an upper limit of two years.

Put the dates into the owner's calendar or into one shared list sorted by next review. A single list that shows all documents, owners and dates takes ten minutes to read and shows at once what is overdue.

Step four: review on change, not only on the calendar

A calendar catches slow drift. Sudden changes need their own triggers. Ask the owner to check the procedure whenever:

  • a tool, supplier or contract is replaced (a contract renewal calendar shows these dates in advance),
  • someone in the procedure joins, leaves or changes role,
  • an error happens and the review says "we did not follow the procedure" or "the procedure was wrong",
  • a colleague says "we don't do it like that anymore".

The last one is the cheapest signal. Make it normal to say so, and make correcting a document a five-minute task, not a project.

Step five: show the status

Give every document one of three statuses in its header:

  • Current: reviewed within its review period.
  • Under review: the owner knows it needs changes; use with caution.
  • Retired: kept only for history, not to be followed.

Colleagues should be able to tell within a few seconds whether to trust a page. When a review date passes without a review, change the status in your list to "under review", which pushes the owner to act.

Step six: a short quarterly pass

Once a quarter, spend thirty minutes with the list. Check three things: which documents are overdue, which have no owner because someone left, and which nobody has opened. For the last group, ask the owner directly: is this still needed?

Step seven: retire openly

Deleting quietly causes confusion, and keeping everything creates noise. Retire a procedure when the work no longer exists, when it is replaced by a better one, or when nobody can say who does it. Mark it as retired with the date and a pointer to the replacement, move it out of the main folder, and tell the people who used it. Keep the old version for a limited time in case a question arises later.

Common mistakes

  • Writing procedures in a rush and never scheduling the first review.
  • Making the document so detailed that nobody dares to touch it.
  • Assigning ownership to "the office" or "management".
  • Keeping several copies in email, chat and personal folders.
  • Treating a review as reading the document, instead of asking someone who does the work to follow it step by step.

Summary

Keeping SOPs alive needs very little: one owner and deputy per document, a one-page format, a review date, review triggers for real changes, a visible status and a short quarterly pass that retires what is no longer true. Start with the five procedures your company relies on most, and add the rest only when those are in good shape.

Sources

  • Our related articles linked above.
  • The formats and review intervals are a working practice for small companies, not a formal standard; adjust them to your size, sector and any regulatory requirements. No client results or market figures are claimed in this article.

Share this article

Interested in Custom Software & Systems?

Learn more about how we can help your organization with this service.

Explore Service

Need expert guidance?

Let's discuss how our experience can help solve your biggest challenges.