Standard Operating Procedures

Standard Operating Procedures, often abbreviated in “SOPs”, are sheets describing how something should be done.

They contain a title, a list of steps, and name what roles can perform them (any employee? special requirements?).

They should also contain the date of the last revision and who reviewed it, for accountability purposes. Similarly, they should contain the date of the next revision and what role(s) should be involved, to protect against obsolescence.

SOPs have two goals. First, they describe how something is done. Second, they provide an objective reference against which to compare reality to surface problems.

The second point is often overlooked. Without SOPs, a worker who encounters the problem is likely to attempt to solve it by himself, by adapting the way he’s doing his work. His adaptability is worth celebrating. On the other hand, it prevents other people from learning about the problem. Moreover, a problem resolved downstream means that it is not addressed upstream, at his source. Generally, you want to address problems as upstream as possible, where their resolution saves time to the largest amount of people.

Conversely, a worker that uses SOPs and encounters a problem must raise his hand. He must ask his manager, “can I do something outside of the SOP to address the problem?” The result is often that either management rewrites the SOP, or takes action to solve the problem at its source. Either way, thanks to the SOP, all workers involved in the operation benefit from this adaptation, not just the worker who faced the problem in the first place.

This is not an exhaustive description of SOPs. I go much further in detail in my book “Best Practices For Operational Excellence.”