When the SOP Works on Paper but Fails on the Shop Floor

When the SOP Works on Paper but Fails on the Shop Floor

Why a Documented Procedure Is Not Always a Usable Procedure

A standard operating procedure can be technically correct, approved and fully compliant—and still fail at the point of work.

The employee may be trained, yet an operator still asks a colleague what to do, a technician adapts the sequence, or a digital SOP is difficult to access beside the machine.

The issue is not necessarily that the SOP is wrong. It may have been designed as a document rather than as part of the work system.

An SOP translates engineering requirements, quality expectations and safety controls into real work. The UK Health and Safety Executive (HSE) recommends designing procedures around the user, task and environment. HSE guidance on procedure design.

A procedure becomes effective when it works where, when and by whom it is used.

1. The Procedure Is Not the Task

A document describes work; it does not perform it.

A procedure can define the sequence, but the user must identify equipment, locate controls, interpret instructions and respond to changed conditions.

A maintenance isolation procedure may be technically sound, but the technician still has to identify the machine and isolation points, understand energy sources and verify the safe state.

The procedure is only one part of the operating system; its effectiveness depends on the person and equipment involved.

The real test of an SOP is whether it enables correct work, not only whether it is technically correct.

2. The Point of Work Changes the Requirement

A procedure written in an office is experienced differently on the shop floor.

The user may be wearing PPE, under time pressure, moving between locations or coordinating with another person. These are part of the task.

HSE recommends examining tasks in the actual plant environment, including communication, information retrieval and decisions. Procedure format and detail should suit the user, task and consequences of failure.

Leaving the work area to retrieve information, asking another employee for clarification and making decisions when conditions change are all part of the process.

The real process includes everything required to complete the job.

3. When a Correct Procedure Creates Friction

A procedure does not need to be technically wrong to become difficult to use.

A long instruction may be hard to navigate; a generic procedure may not fit a machine; a digital SOP may be inaccessible at the point of work; a critical warning may be buried in text.

The system can add to the problem: machines change while documentation, training, drawings or labels remain outdated.

People then adapt: they rely on experience, ask colleagues, use local references or create workarounds.

HSE recommends involving users and using task analysis in procedure development. Procedures and competency should support each other.

A workaround is not automatically evidence of poor discipline. It may be an adaptation to a process that does not fit actual conditions.

It is information worth investigating.

4. How Much of the Procedure Lives in the Person?

Procedure usability also depends on where knowledge resides.

Imagine two technicians receive the same SOP. One has worked on the machine for years and relies on memory; the other is experienced but unfamiliar with that equipment.

The first may use it as confirmation. The second may depend on it for primary guidance.

That difference exposes an important design issue:

How much of the procedure lives in the document, and how much lives in the person?

If critical knowledge lives mainly with experienced employees, the formal system may carry less operational knowledge than assumed.

HSE states that procedures do not replace competency. Its human-factors guidance also recognises the influence of task design, equipment, workload and working conditions.

This is where Factory UX becomes relevant: can the user see, understand and act on what the process requires?

5. An SOP Has to Survive Change

The real test of a procedure begins when reality stops matching the original assumption.

Machines, materials and priorities change; tasks move between shifts and abnormal conditions appear.

A useful procedure must support judgement as well as sequence.

For facilities covered by the United States OSHA Process Safety Management standard, procedures must be accessible to affected employees and reviewed to reflect changes to process chemicals, technology, equipment and facilities. This applies only within that standard's scope. OSHA Process Safety Management standard, 29 CFR 1910.119.

Procedure management is more than document control. When a task or machine changes, related instructions, drawings, labels and training need to be checked together before the revised method is used.

A machine modification without a procedure update separates Engineering from Operations. A procedure change without training separates Process from People. Updated documents without updated asset identification separate Information from the workplace.

The document may be correct in isolation while the system around it is not.

6. Workarounds Show Where the Design Meets Reality

Workarounds reveal where the designed process struggles to carry the real work.

A worker may create a shortcut when the sequence is cumbersome, use a local reference when the official document is hard to navigate, or ask a colleague when an exception is not explained.

Not every workaround is safe or acceptable. But treating it automatically as a discipline failure can miss useful information.

HSE distinguishes intentional violations from other human errors and recognises that design can make some errors more or less likely.

The practical question is why the workaround exists and whether the underlying process can be improved.

The workaround may be the visible behaviour. The design condition behind it is what needs to be understood.

7. Designing the SOP Around the User

A usable procedure begins with the task, person and environment.

SEE — Observe the task, its sequence, information needs and decisions.

CONNECT — Identify the people, equipment, systems, controls and documents involved.

DIAGNOSE — Find breakdowns in sequence, access, language, visual communication, machine configuration or exception handling.

DESIGN — Make critical information easy to find, distinguish routine steps from decision points and reflect actual conditions.

IMPLEMENT — Put the procedure where work happens; training, visual references and digital access should reinforce it.

IMPROVE — Use questions, deviations and workarounds to check whether the procedure still works.

This is the BRIGS SEE → CONNECT → DIAGNOSE → DESIGN → IMPLEMENT → IMPROVE cycle applied to procedure usability.

The procedure is not finished when the document is approved.

It is finished when the work can be performed reliably.

8. Where BRIGS Creates Value

BRIGS treats the SOP as part of the operating environment, not a standalone document.

Factory UX addresses the human interface: can people understand the workplace, identify equipment and act without unnecessary friction?

Factory OS addresses information and workflow: procedures, permissions, maintenance information and approvals that move with the task.

Machine and Process Safety address controls for hazardous energy, machine interaction and critical process conditions. Instructions must remain aligned with those controls.

Workplace improvement connects the design to reality: a procedure must work beside the machine under actual conditions.

BRIGS looks beyond writing better SOPs to understand what the procedure must connect to and what reliable execution requires.

9. A Practical SOP Usability Check

Check the task. Can someone follow it in the actual workplace? Does it reflect the real sequence and conditions?

Check the information. Is it available when needed, and can the user find the correct machine, drawing, instruction or control?

Check the sequence. Are critical actions, decision points and escalation clear?

Check the equipment. Does it match current configuration, controls, labels and isolation arrangements?

Check the user. Does it support a less-experienced employee, or depend on experienced workers?

Check actual use. Do people ask questions, skip steps, create workarounds or report difficulties? These patterns may reveal needed improvements.

This is not a document-format audit. It checks whether the procedure supports the work it is meant to control.

Conclusion: A Procedure Has to Work Where Work Happens

An SOP is often treated as the final expression of a process. In practice, it is part of the process.

Its effectiveness depends on the instruction, user, machine, information and conditions of the task.

That is why a procedure can be technically correct and still fail at the point of work.

At BRIGS, Factory UX, Factory OS, machine safety, process safety and workplace improvement come together around one question: can people understand the procedure, access what they need and act reliably?

The question for manufacturers is not simply:

Is our SOP correct?

It is:

Does our SOP still work when a real person uses it on a real machine under real operating conditions?

A Practical Next Step With BRIGS

BRIGS can help manufacturers examine whether procedures support the work or require people to compensate for gaps.

The BRIGS Factory Systems Self-Assessment examines People, Machines, Processes, Information, Interfaces and Control to identify areas for deeper investigation.

Start with one procedure that people regularly struggle to follow. Examine it where the work happens. Then determine what needs to change to make the right action clear, usable and repeatable.