SOPs Are in Place — So Why Aren't They Being Followed?

2025-09-24

Executive Summary

• When SOPs aren’t followed, the common response is to blame employees or write better SOPs. Both miss the actual problem.
• Three core mechanisms cause SOPs to fail: they describe ideal conditions rather than operational reality; they exist in a document system but not in the actual workflow; and employees have insufficient reason to follow them when no one is watching.
• A good SOP doesn’t only describe the process correctly — it’s designed to be executable in the actual conditions where employees are working.
• The solution isn’t rewriting SOPs. It’s changing how SOPs are created, maintained, and embedded in operations.

A familiar cycle

The audit ends. The non-conformance report notes: process X was not executed correctly according to the SOP.

The classic response: organize a training session to review the SOP. Employees sign off confirming they’ve been trained. A month later, the same issue recurs.

The next response: write a more detailed SOP, add verification steps, add signature requirements.

Six months later: a larger document library, an unchanged problem.

This cycle is common — and it’s common because the way we frame the SOP problem is usually wrong. We frame it as a compliance issue and respond by increasing controls. But the actual source of the problem typically lies elsewhere.

SOPs and operational reality — a gap most people don’t see

One uncomfortable reality needs to be acknowledged: most SOPs are written under ideal conditions, by people who are not the ones executing the work daily, describing an ideal process under ideal conditions.

Operational reality is not ideal.

Raw materials vary. Equipment ages and changes behavior. New employees must learn while doing. Real-time pressure forces people to choose between “follow the SOP correctly” and “finish on time.”

When there’s a gap between the SOP and reality — and that gap isn’t acknowledged — employees must resolve it themselves. How they do it: skip the step that doesn’t apply to their actual situation, adapt based on experience, or do things “the way we’ve always done it” rather than the way the SOP describes.

This is not non-compliance driven by laziness. It’s a rational response from someone working in real conditions with an SOP that wasn’t designed for those conditions.

Three core reasons SOPs don’t get followed

Across many organizations, three primary mechanisms cause SOPs to fail consistently.

Reason 1 — The SOP describes ideal conditions, not operational reality

This is the most fundamental technical cause.

SOPs are typically written as best-case scenarios — how the process works when everything goes according to plan. But most of an operator’s time is spent handling things that don’t go according to plan.

A practical example in food manufacturing: the incoming materials inspection SOP describes the procedure with materials that meet specifications. But when materials arrive with an unusual characteristic — not a clear violation, but a grey area — the SOP provides no guidance. The inspector must exercise their own judgment, ask someone more experienced, or accept the batch to avoid delaying the production schedule.

The result: the SOP isn’t followed correctly — not because the employee doesn’t want to, but because the SOP isn’t useful enough for the actual situation they’re facing.

How to recognize this cause: Experienced long-tenured employees execute tasks differently from what the SOP describes — and when asked why, they have specific, coherent reasons. The difference isn’t carelessness; the SOP doesn’t reflect how the work actually needs to be done.

Reason 2 — The SOP exists in a system but doesn’t live in the actual workflow

This is the systemic cause.

Many organizations have invested in building a substantial document library — a shared drive, a DMS, an intranet. But when an employee is working and needs information, they don’t open the document management system. They ask a colleague, work from habit, or recall what they were trained on when they joined — which may be out of date.

The reason: SOPs exist as reference documents — not as part of the actual workflow. They don’t appear at the right time, the right place, in the right form for the person doing the work.

The problem is particularly serious when SOPs are updated: the person who updated it knows, their manager knows, but the person executing the work is still following the previous version because they weren’t aware a new version exists, couldn’t find it easily, or simply don’t have a habit of checking.

How to recognize this cause: During an audit, the person executing a task doesn’t know the current version of the relevant SOP. Or when asked “how do you perform this step?”, the answer differs from what the SOP describes — but the employee isn’t aware they’re doing it differently.

Reason 3 — There isn’t sufficient reason to follow the SOP when no one is watching

This is the motivation cause — and the one most commonly avoided in SOP discussions.

Following an SOP typically requires more time and effort than not following it. Recording inspection results on the correct form, at the correct time, in the correct way — takes more time than skipping it. Executing steps in the prescribed sequence — sometimes feels slower than the shortcut.

When employees don’t experience direct consequences for non-compliance — and when no one is checking — the reason to do the extra work isn’t compelling enough.

This isn’t a moral failing of individual employees. It’s a system design failure. If the system were designed so that following the SOP is easier than not following it, outcomes would differ. If the consequences of non-compliance were visible and timely rather than only appearing during an audit, perception of risk would differ.

How to recognize this cause: SOP compliance spikes immediately before and during audits, then returns to baseline after audits end. Or compliance is high on steps that get checked and low on steps that don’t.

What makes an SOP executable — not just documented

An SOP that gets followed is not a more carefully written SOP. This distinction is important and often missed.

Executable SOPs share some characteristics that documented-only SOPs lack:

Written with input from the people who execute the work, not only by managers. When the people doing the work participate in writing the SOP, they bring in the real variables that managers don’t know about. The resulting SOP reflects how the work actually needs to be done — not how it theoretically should work.

Addresses non-standard conditions, not only ideal conditions. A good SOP answers “if X happens, do Y” — not only “if everything is normal, follow this sequence.”

Available at the point of execution, in a usable form. A PDF in a SharePoint folder that no one knows how to find is not an operational SOP. An effective SOP appears in the workflow — as a checklist on a tablet at the workstation, a prompt in the work management system, or a guide mounted at the point of execution.

Updated from operational reality. When employees discover that a SOP doesn’t reflect current conditions, there must be a way to flag this — and the SOP must actually get updated. If not, SOPs will continue drifting further from reality, and that drift will continue generating non-compliance.

The conditions for consistent SOP adherence

From the three causes and the characteristics of executable SOPs, a set of necessary conditions emerges for SOPs to be followed consistently.

Condition 1 — The SOP must reflect operational reality. Not the ideal. Not what should happen in theory. But what actually needs to happen under real operating conditions — including how to handle the non-standard situations that regularly arise.

Condition 2 — The SOP must be accessible at the point of execution. Right time, right device, right format. A PDF document in a folder does not meet this requirement for a worker on a production line.

Condition 3 — Non-compliance must generate feedback. Not necessarily punishment. But a mechanism so that the person executing knows when they’ve deviated, and the manager knows in time to act — not only when an audit reveals it.

Condition 4 — The SOP must be kept alive. Not written once and left unchanged. SOPs need review when operating conditions change, when equipment changes, when materials change. And a clear mechanism must exist for employees to flag when they find a SOP doesn’t match reality — and for that feedback to result in an update.

Conclusion

The SOP non-compliance problem is not a people problem. And the solution is not more training or tighter enforcement.

It’s a design problem: SOPs are designed as compliance documents but need to be designed as operational tools.

When a SOP accurately reflects operational reality, is accessible at the point of execution, generates timely feedback on non-compliance, and is kept current — employees follow it not because they’re forced to, but because it’s genuinely useful for their work.

That’s the difference between a SOP as something the organization has, and a SOP as something that’s actually part of how the organization operates.

Which of the three causes is your organization dealing with?

→ Take the Knowledge Management Readiness Assessment to evaluate the quality of current SOPs and processes.

Further reading:

• Tacit Knowledge vs. Explicit Knowledge — Why the Distinction Matters (related article)
• Process Standardization Before ERP: Why the Foundation Comes First (Cluster 1 — ERP)
• From Individual Knowledge to Organizational Knowledge (pillar)

Examples used are illustrative composite scenarios from common patterns in manufacturing SMEs. The three causes analyzed represent a practical framework developed by OKELAS from direct observation — not a formally standardized academic classification.