Deviations often arise because procedures do not match reality
Aliases: procedure-practice gap · work-as-imagined · work-as-done
What it is
Procedure–practice mismatch is the structural gap between work-as-imagined and work-as-done: the equipment state, tooling, staffing, and time windows a procedure assumed when it was written drift away from what the field actually looks like, until literal execution stops being feasible. The root cause is usually not attitude on the floor — it is how procedures themselves get produced: who writes them, on what cadence, and how long a revision takes to catch up with the field.
Why it happens
Procedures are typically written by engineering, process, or compliance staff who are not standing the shift, working from a snapshot of the equipment register, process parameters, and staffing at one point in time. Once issued, that snapshot is frozen until a formal revision is triggered, while the field keeps moving: equipment modifications, substitute parts, small process tweaks, and shift composition change almost continuously. Formal revision carries its own approval chain and verification cost, so the actual update rate lags the rate of field change, and the gap compounds over time. What operators face is not a choice about compliance — the conditions the procedure describes have already stopped existing, and they have to assemble a workable path across that gap themselves.
Studying it
Compare a procedure's last revision date against the most recent engineering change to the equipment or process it covers; the distribution of that lag quantifies the width of the gap directly. Counting "cannot execute as written" field reports against the number of procedure revisions over the same period works too — reports climbing while revisions stall means the revision pipeline itself is not keeping pace. Interviews should pin down the exact step where execution first became infeasible and what substitute was used, not ask generally whether the procedure was followed.
Where it stops holding
Structural lag does not endorse every deviation: crossing isolation, interlock, or authorization boundaries still needs a dedicated review even when the underlying cause is legitimate organizational lag — an out-of-date procedure does not excuse skipping that review. The gap between procedure and field can never be compressed to zero either; this is not a one-time fix, only a feedback loop to shorten, and there is no endpoint where a procedure stays permanently synchronized with reality.
Applying it
- Build a "cannot execute as written" reporting channel that records the step, the asset or condition involved, and the substitute action taken, and route it to the procedure owner directly rather than only into a shift supervisor's log.
- Have the people who write procedures walk the shift periodically and watch actual execution, instead of updating text purely from the equipment register and process documents.
- Make major equipment overhauls, process changes, and staffing reconfiguration mandatory triggers for procedure review, not just a fixed periodic cycle.
- How to check: sample a batch of procedures and measure the gap between each one's last revision date and the most recent engineering change to its equipment; a lag that keeps widening means the revision pipeline itself needs fixing, not the wording of any single procedure.