how to write a standard operating procedure (SOP)
posted by Rob Stewart Jun 30, 2020
A Standard Operating Procedure (SOP) is supposed to achieve consistent results by consistency of action. It isn’t just about a prescribed process - it can also include a basis for assessment such as a decision tree. The whole SOP should work as a flowchart with identifiable stages, logical procedures, and clear rationale for decision points.
A standard operating procedure (SOP) is something I’ve been asked to communicate a number of times. Usually the SOP is already written, but needs further communicating as people don’t seem to be following what it says... It sometimes turns out that further communication is an issue, but not the only issue.
Where do the difficulties lie?
Some of the issues can be spotted if you run through the entire SOP in the actual setting it should takes place. This should iron out the lumps and bumps, but if the person running through it is the person who wrote it, they are likely to be over-generous in the interpretation of anything that is ambiguous. If I’m asked to represent an SOP in a video, it has to work played from beginning to end, as you don’t really want the audience to have to hop backwards and forwards to find what they need. What becomes really apparent is where the SOP logic breaks down and where actions are missed or unclear.
No room for inconsistency.
A standard operating procedure might well be written or approved by a peer group, so there needs to be some awareness when people ‘agree to disagree’. This is quite a normal thing to do in meetings, but not useful if you are trying to create something clear for other people to follow. There needs to be agreement on each point, and only have alternative procedures if it is made obvious why you should pick one or the other.
The main action in a particular stage might be well-defined, but sometimes the transition between stages might not be so obvious, especially for someone new to the procedure. Break the stage down into a beginning, middle, and end to make the starting point and the required end result easily understandable. You should also detail how the transition or handover between each of the stages works. The person or team responsible for the current stage should be responsible for the handover to the next stage, as only they know when their stage is complete.
Resourcing can be an issue.
Check whether everyone has the resources you think they should have. In large organisations, allocation of resources may be a bit patchy as whole company upgrades are difficult to do instantly. If your SOP requires new equipment or access to information, make sure it is actually available to everyone who needs to follow the SOP.
Over time SOPs will need to be amended as internal and external requirements change. If you just edit individual parts, check you are not losing continuity with the other actions in the SOP. You can sometimes see the effects of piecemeal editing when statements change from ‘make sure X is on Y’ to ‘You must always make sure X is on Y’ and then to ‘You are responsible for making sure that without fail X is on Y’. If people aren’t doing the ‘X is on Y’ then maybe just enhancing the imperative to more of a command misses the point. Maybe what they need is a better explanation why it is important that ‘X is on Y’.
Test it before roll-out.
Once you have your agreed SOP, you can trial it. Pick a test group and ask them to use it, and then ask them to highlight any issues where it is unclear, or where they think it doesn’t work well. You might find that a radically new SOP may have unanticipated consequences when people expected to follow the new procedures, so with their feedback you can make revisions.
Check everyone who needs to approve it is happy, and then put on a clear date and a list of who has approved it. Make sure there is somewhere or someone identified to help with difficulties or if anyone is unsure about a new way of working. You are now ready to make it available and engage the wider audience.
Making an SOP available on an intranet, and sending everyone a message that they must read it, is probably not enough. Engage local supervision with implementing the new SOP procedures as they will be the ones seeing the SOP in action day to day.
With your SOP now in use, then set a future date to check how valid it still is. Your SOP is eventually going to need revision, so collect any points to take care of and revise the whole SOP rather than editing small pieces. The SOP should be followed, but it should be regarded as a ‘living’ document that will respond to change.
If you feel you could do with some guidance on creating your effective SOP, get in touch.