Somebody, at some point, did a lot of work. There’s a shared drive folder called “Procedures” or a binder on a shelf. It has an SOP for opening the office, closing out a job, onboarding a customer, ordering supplies, and probably forty other things. Some of them are long. Some have screenshots of software the business stopped using two years ago.
And nobody uses them. People do the work the way the person who trained them did it.
What the owner thinks is wrong
“The team won’t follow procedures.” Sometimes followed by, “We need to write better ones,” or, “We need to enforce them.”
I understand the frustration. Someone spent real effort, and it feels like it was wasted. But I don’t think the problem is the team’s attitude. I think the documents stopped being useful, and people quietly worked around them.
What I’d investigate
- Which SOPs exist? Just a list.
- Which are current? Does this still match how the work is done, in the tools you use today?
- Where do people actually look when they’re stuck? Usually: a coworker. Sometimes: an old email. Rarely: the binder.
- What do people do instead? That’s the real process. It might be better than the written one.
I’d also look at length. If an SOP is eleven pages, nobody is opening it in the middle of a task.
What’s probably underneath it
Documentation became the goal instead of the tool. Somebody was asked to “document everything,” so they did. But nobody decided which processes actually needed a document, who would keep them current, or where people would find them in the moment they need them.
So the documents aged. The software changed. People changed. The binder didn’t. And once someone follows an SOP and it’s wrong, they stop trusting all of them.
Knowing what should happen and having a process people actually follow are two different things.
What I’d change
- Keep the few that matter. The processes where mistakes are costly, rare tasks people forget, and things every new hire needs. Archive the rest.
- Cut them short. A checklist, a few steps, a screenshot if it helps. The goal is to be usable mid-task.
- Put them where the work happens. Inside the project tool, linked from the form, pinned in the channel. Not in a separate folder somebody has to remember exists.
- Give each one an owner and a review date. If the process changes, someone updates the doc. If it’s not reviewed, it gets flagged.
- Use the real process. If the team’s workaround is better than the written version, write down the workaround.
One more thing I’d do: ask the people who do the work to help write the short versions. They know where the real steps are, and they know which parts of the old document everybody skips. A procedure written with the team gets used. A procedure written at the team gets filed.
What I’d leave alone
Documents that have to exist in full for compliance, legal, safety or contracts. Those can stay long. They just shouldn’t be the thing someone has to read to do the daily work.
The tradeoff
Archiving documentation feels risky. “What if we need it?” It’s still there, just out of the way. And short documents won’t cover every edge case. That’s fine. Edge cases go to a person. The SOP covers the normal path.
The pattern
The most useful SOP I can imagine is the one that’s open on the screen when someone is doing the task. The least useful is the perfect one nobody can find.
A template can show you what to do. It can’t make the process work inside your business.
So here’s a test: pick one SOP from your folder at random. Ask the person who does that task to follow it exactly, step by step. See where it breaks. That one test will tell you more about your documentation than a full review.
If the answer is “most of them are out of date,” that’s a good thing to sort out on a Systems Fit Call.
