What does an SOP look like that has Everyone In The World as an Audience? What procedure could you write that could actually be complied with?

Well, there’s really Only one SOP that you could write for everyone in the world, and it basically comes down to this sage bit of wisdom:

.

Anything else would require more information about who and what the procedure is for.

Ok, so that’s a bit of a silly example, but it makes an important point: you need some constraints to be able to write a meaningful procedure.

Earlier this month I wrote about narrowing down the scope and audience of SOPs to make procedures that are easier to follow and more modular. In our final post of "SOP November" we’re going to extend this concept: Using constraints to help us not only to write better scoped SOPs; but to design an intentional interface between the SOP and the wider system.

Ok, so we're not really going to write an SOP for everyone. Let’s say we constrain the audience a little: Write an SOP that applies to all employees performing any role or function in the facility. What would this SOP look like?

Probably something very general like a Security or HR policy.

Would you be able to write any specific, step-by-step procedures, checklists or forms for this wide-ranging policy? Perhaps, but not many. Even something that seems universal such as swiping in to the facility would actually need some more constraints: additional procedures for the night shift, excluding remote workers, etc.

So without constraints we’re actually restricted to very general policy statements. We also don’t have enough information to provide procedures, create a product, document results, or even measure success.

These examples are like a jigsaw puzzle where every piece is blue with smooth sides. Sure, you’re free to put it anywhere, but with infinite choice you have no guidance as to where it fits into the wider picture, or even much of a wider picture at all.

Good constraints, like the nodes of a puzzle piece, narrow down the choices of which things fit together. So while there may be fewer choices, you know something more about each of those choices. That, in turn, opens up more options.

Instead of 500 possible pieces that can fit that one piece in your hand, now there are exactly four. And those four open up another twelve, and so on until the puzzle is completed.

Why would we care about how an SOP fits into the wider picture? What kinds of things do we want to ‘fit’ with our procedures? Here are some examples:

Consider this simplified take on the classic

.

Here we have something that’s been constrained to be a little more useful. We have three roles that we’re addressing, that happen to translate into three ‘activities’. Now we have a little more information that we can use to write our SOP.

So we write our SOP on SOPs that meets these constraints. It provides procedures on submitting SOPs to review, and ends up with an approved SOP. Everything else is an implementation detail, right?

Does it meet regulatory requirements? Who signs off on these SOPS? Management? QA? Do we have any documentation on the process? What were our requirements anyway?

Instead of leaving these questions as implementation details, let's see what happens if we spend some time pulling them out as some additional, explicit constraints on our SOP.

Now we have a shape to our SOP we can work with. Let’s write it down somewhere and keep it for later.

First of all, writing this SOP just became alot simpler: by putting some up-front effort into this list of constraints, we’ve (hopefully) highlighted everything that our procedures need to meet. Now we’re free to write, draw, flowchart or tabulate whatever instructions will best communicate the procedures, as long as they meet these constraints.

You might have noticed that our list of constraints has basically become a specification for the SOP.

Why not keep it around? In fact, with a little bit of work we can write these to be nice, testable requirements. We're designing our procedures!

Now we have a checklist for the reviewers - making their process easier with fewer back-and-forths. Proposed changes may be validated and justified against the specifications before implementing. New revisions of the SOP can be easily checked against them.

Forms and QC/testing programs can be built against them.

By spending a few minutes up front writing out constraints, you’ve just streamlined the whole SOP authoring and review process, and freed us up to build other components that we are confident will fit to the shape of the SOP.

When you constrain the design of some function or process, you provide guarantees that open up new options. Your SOPs are more modular, your forms fit better, your QA and QC requirements are better defined.

More importantly, documenting those constraints - bringing them forward either as frontmatter, some kind of metadata, or as a separate specifications document - can actually make things more streamlined.

And that wraps up SOP month. We'll mix it up a bit for December. Until then, thanks for reading!

– Brendan