When is it OK to use 'Approximately' in an SOP?
A version of this question came up on the RQAP newsgroup, and as I thought about an answer I realised that there is a surprising amount to say on this topic. It really comes down to the level of precision we use in our SOPs - in terms of the limits and measurements we use to specify the task, but also the precision of the language we use to describe it.
Spoiler alert - I'm basically going to tell you to avoid using ‘approximately’ unless you’re adding guidance to a more precise, measured value. Read on to learn why.
Want to get articles like this right to your inbox, every week? Subscribe Here!
Want to get articles like this right to your inbox, every week?
Subscribe Here!
Be Precise, but Not Too Precise.
Be Precise, but Not Too Precise.
One of my key tenets when writing SOPs is to "Be Precise, but not too Precise".
Basically what this means is that there's a balance to be had between
enough detail
to meet your quality and compliance goals, and
not so much detail
that it makes the task too difficult, wasteful or time-consuming.
What does that balance look like? What tools do we have to control it?
Let's Bake a Pie
Let's Bake a Pie
Let's say we have a process for baking apple pies, and our quality and compliance goals are:
A standard bake, size and flavour consistent with our brand; and
A safe food product: No raw dough or foreign contamination
Simple enough, right? Would the following procedure meet these goals?
Apple Pie Recipe #1
:
A pie crust is made and rolled out to fit the pan. The pie is then filled about 2/3 full with uncooked apple pie filling, mounding slightly in the center. The filled pie is then covered with the remaining crust, vents cut, glazed and sprinkled with sugar. Bake at medium heat until done.
Does this recipe make a pie?
Certainly, for various definitions of 'pie'.
Will the pie meet the goals our process?
Maybe, depending on the skill and experience of the pie maker. They might even be able to make a consistent pie every time by remembering or jotting down how
they
do it.
What if you had 6 different people making pies, 3 shifts on 2 different lines? How often are you going to be consistent with this recipe?
The chances are probably slim to none, since we provided almost no measurements besides the size of whatever pan they grabbed. Perhaps you could employ a really tough manager to keep everyone in line...
What are the chances we have one or more bad/unsafe bakes?
Well, if both our amounts and bake times are completely uncontrolled, the risk is rising with every bake. Ahem.
A Better Stricter Recipe for Apple Pie
A
Better
Stricter
Recipe for Apple Pie
I hope it's obvious here that we need to increase the detail in our procedures so that we can reduce the variability across time, operators, and perhaps even across equipment.
Ok, so we agree that our recipe needs alot more detail. But how much detail is enough? Well, we could do something like this:
Apple Pie Recipe #2
:
1.
Take 314.15 g of pie crust
2.
Roll it out to a 32.27 cm diameter perfect circle, 0.42 cm thick
3.
Spread across a #3 Pieco-brand pie dish
4.
Fill with 14.32 apples diced into 0.72 mm cubes
5.
etc...
Here we've swung the other way - we've gone way too detailed. There is absolutely zero chance the operator can actually meet these specifications. Can you see why?
Even if they spent hours rolling out that pie crust to a perfect circle, there is absolutely no chance that the circle will meet both the specified thickness and diameter. Not to mention the unnecessary difficulties introduced by the other requirements.
Forced Deviations
Forced Deviations
To follow this recipe, the baker needs to change something on the fly. But how can they really know which part is safe to change: the weight of dough? the diameter of crust? the thickness? Any one of those changes could cause a quality problem such as a leaky pie or an incomplete bake!
From a compliance point of view, the operator MUST follow the SOP exactly as specified otherwise it is a deviation (by definition). Therefore
every single one of those measurements is equally important
.
This is an example of a
Forced Deviation
. The SOP has painted the operator into a corner and they will have to deviate from the procedures no matter what they do.
Avoiding Too Much Pie.
Avoiding Too Much Pie.
We could imagine two ways that we could fix this over-specified SOP:
1.
We could
reduce the precision of each number
to some (appropriate) range or limit: Something like "3.0 to 5.0", "314 ± 16", "at least 42" etc. This sometimes gets over-applied, and so you have SOPs saying that sweeping the floor once a day is "every 24 ± 2 hours".
2.
We could
reduce the precision of our language
- signal that a certain measurement isn't very important by using words like "about" and "approximately".
Obviously solution #1 will help us out in most situations - but sometimes a number doesn't matter enough to measure or record. That's where our 'approximate' solution #2 comes in, right?
An Approximate Solution
An Approximate Solution
Here's the catch. The instances when you're truly 'approximate' are fewer than at first glance: After all, if there really aren't any bounds, then why are we providing a number at all?
To take the pie example again, if we say "Approximately ¾ full" what does that mean? Is ¼ full ok? That would make a rather meagre pie. What about if we accidentally go all the way and fill it up to the brim? Are there any consequences to overfilling?
You see, there
is
usually an implicit bound somewhere, and in many cases we might be better thinking about how we can be more specific about that limit than waving our hands at it.
So this is our third option we can add above:
3.
We could
increase the precision of our language
to better reflect the implicit bound. This requires spending a little more time up front thinking about what the limits actually are, and how the operator can measure them.
It's Done When it's Done!
It's Done When it's Done!
Baking time is often used as a convenient proxy for 'pie done-ness', however there are many other factors in the proper baking of a pie. For example: the oven's temperature control; where the pie ends up in the oven; how cold the pie was going in; etc.
If you've ever baked anything, you know that when we say a pie takes
'approximately an hour'
to bake, we might actually mean
'until the crust is golden brown and the filling is bubbling, but before it starts to blacken and emit an unpleasant burnt smell'
.
Well then, why not actually specify a visual indication in our procedure? Or better yet, we might want to combine that with a measure of the internal temperature!
So now we can say something like
'until the crust is golden brown and the filling is bubbling, approximately 1 hour'
. Note that 'approximately' is still there - but now it provides us with some guidance as to when we start looking for our visual cues or taking the internal temperature.
By themselves, neither "Approximately 1 hour" nor "1.00 ± 0.01 hr" were useful controls on whether the pie will come out well done. By providing a meaningful boundary we're giving useful, actionable information.
What if We Define What 'approximately' Means in an SOP?
What if We Define What 'approximately' Means in an SOP?
I've know of at least a few facilities who do this:
The word 'approximately' is defined in our [Definitions / Weights and Measures / Good Documentation Practices] SOP to always mean ±15%"
This now frees authors and staff to use 'approximately' everywhere, and operators and QA will know that means within this specific bound.
What's wrong with that?
•
First of all, the SOP just redefined a word that already has a meaning. So now the text looks like this is a measure that doesn’t matter, but in fact we demand elsewhere that it hold a very specific, but arbitrary, precision. We're still not taking into consideration any bounds implicit in the SOP's context, but we're also not freeing up the operator from having to consider bounds. Let’s say an SOP asks for ‘approximately 0.5 ml’ of an indicator from an eyedropper. Under the 15% definition, 0.4 ml would be a deviation. So you’re back to measuring a value whether it matters or not!
•
Quick:
Is 4.1 within 15% of 4.8?
I'm sure you can figure that out pretty quickly, but the point is that we've implied at least one calculation and one comparison that must be made by the operator in their head, while their performing the procedure. Besides increasing cognitive load, every time we do this we increase the chance of an error being made.
[Aside: this is also a good reason to avoid using
x ± a%
in an SOP]
•
We've defined a concrete requirement in another document. So either the operator has to look it up every time, or we expect them to work from memory.
This last point might seem like a small thing, but it begs the wider question: do we want our operators to follow the SOP or not? When is 'doing it by memory' ok? What if 'approximately' is later changed to be a table of ranges that depend on whether you're measuring volume, mass or temperature?
Front-Load your Effort
Front-Load your Effort
It's true that procedures should not be overly prescriptive, nor force deviations where there's no quality impact. We certainly should not require a number to be measured and recorded if that number doesn't actually matter.
However, none of these are an argument in favour of being vague!
The more vague your procedures are, the more you leave up to 'on-the-fly' decisions, the more you lean on the operator's experience and how they feel that day. You also put more burden on the data collected to provide a 'complete' picture of what happened - so a vague procedure might mean more documentation requirement.
We've made the
author's life
easier while putting
more cognitive load on the operator
!
We should be doing the opposite: SOPs should be
front-loading effort
and making it easier for the operator to meet quality, consistency and compliance goals.
So when can I use 'Approximately' in an SOP?
So when can I use 'Approximately' in an SOP?
Use 'approximately' as a way of
adding guidance to an existing measure
rather than
specifying
. The 'real measure' is specified somewhere close by. Something like:
"Run the machine until the indicator turns red; approximately 20 minutes."
or
"Add fluid until the level reaches 'full' mark; approximately 3 L for an empty tank."
The key here is that the measurement that's covered by "approximately" is clearly for guidance or convenience only. The actual condition is determined some other way.
Don't use 'approximately' to make writing an SOP easier, or as a placeholder for some standardized, looser limit. You will only write the SOP once, but the operator will use it many times. Spend the effort now to more precisely define
what
the bounds are, and take some effort away from day-to-day operations.
Now we can get down to business and record only what we're interested in.
Thanks for reading,
– Brendan
Join Brendan's Beyond Compliance List
Weekly articles on designing, improving, and troubleshooting quality processes for regulated industry professionals from Operations Managers to QA Leaders.
We'll never share your email. Unsubscribe any time.