Living SOPily ever after

Living happily ever after..

Standard Operating Procedures are – embarrassingly enough – very close to my heart.

For me Standard Operating Procedures, otherwise known as SOPs, are standards, knowledge and benchmarks all in one. Embedding processes and general business activities into SOPs is the ultimate implementation of strategy and is critical to ensuring that what needs to be done on an ongoing basis is done.

For me, an organisation without SOPs is like a game of football without rules, a musical degree without theory and research with any breakthroughs. An organisation without SOPs is disconnected, disoriented and (hmmm…. What other ‘dis’ word can I use? We’ll settle with…) disappointing.

I explored the key benefits of documented processes and procedures in my post ‘All About Going with the Process Flow’ in December. Documentation of these results in retention of corporate knowledge, improving outcomes and how are they achieved, enabling quality accreditation, and potentially systematisation. I don’t want to spend this post going over old ground though, so today I’m focussing on what SOPs actually are and assuming that the benefits of documenting processes and procedures generally is a given. But what exactly is a SOP?

SOPs are documented standards for how a procedure within an organisation must be carried out. As we saw – also back in December – procedures are ‘a series of steps’ that are quite explicit and detailed, and which must be followed by one person from beginning to end (ie they are from only one employee’s perspective). Therefore, to be technically correct, a SOP is written for one role, setting out the steps, rules and knowledge – or directing the reader toward where they can find them – required to enable someone to undertake their section of a process correctly. (In reality, where processes have been documented, SOPs do seem to focus more on processes than procedures though.)

So, what to include in a SOP?

I’m sure this is pretty standard, but different organisations seem to have their own templates and to be quite honest, I don’t like all of them. I would argue that the most difficult part of establishing SOPs in an organisation is not about the writing of them at all, it’s more the people and cultural change factor – the fact that most people don’t enjoy change. Therefore where a culture has permitted operations to be ad hoc and at the discretion of individual people, most of these individual people are going to be resistant to not only changing their practices, but also to following the same documented steps every time. Many people find this kind of change threatening and feel like it undermines their knowledge and expertise.

I don’t think that the purpose of a SOP is to undermine the knowledge and expertise of the people within its jurisdiction. Quite the opposite. For people who enjoy working within processes, SOPS remove ambiguity and allow them to get on with their jobs efficiently and (if documented and followed correctly) with less problems and stress. However, for people who want to capitalise on their knowledge and expertise, SOPs – as a standardised way for how it is generally accepted that things should be done (a benchmark) – give these people a vehicle for building on the benchmark and thinking creatively to improve both processes and outcomes.

(For those of you in government or the NRM space or any other industry where ‘continuous improvement’ or ‘adaptive management’ is a buzz phrase, this should strike a cord. Continuous improvement is about continuously reviewing the current state, identifying improvements and planning then implementing the required change. Without documented procedures, it will be difficult to know exactly what was done and to pinpoint where the change is needed.

Adaptive management, on the other hand, is about learning through doing… as you undertake a mode of action, you see the outcomes and then improve them for next time. This is not a blanket review and improvement of a process or procedure. It is review and improvement of a decision-making step in a process or procedure. Without documented procedures, it is very difficult to know exactly what the inputs and considerations were into the decision-making step and to pinpoint what information and considerations are missing (at increasingly detailed levels of granularity) in order to make the best decisions.)

To come back to the point though, in order to realise the benefit of actually developing SOPs, SOPs themselves need to be used. And to be used they need to be usable. But what will make them usable?

What follows below is my list of what a really good usable SOP should have. As always, this is just my opinion and you can take it, leave it or debate it (ie leave a comment below!).

  1. A title. Maybe that’s a bit obvious, but it can be a trap. The title must be for a procedure – not for a policy or an area of work. For example, you may have a ‘Standard Operating Procedure for the Development of a Policy’.
  2. A brief summary of the procedure.
  3. A flow diagram and a textual description of each step – for top down / visual learners as well as bottom up / non-visual learners.
  4. Responsibilities – who is responsible for doing, managing and maintaining the procedure
  5. Version control – self-explanatory I would hope. How else can you be sure that people are using the latest procedure instead of something that was devised three review processes ago?
  6. Linkages – I’ll go into more detail below.

I like to bang on about traceability, and this week is no different. A SOP does not stand alone and huge numbers of SOPs that have been developed and maintained independently of each other will not form a united and successful organisation. A SOP is a good start, but readers need to be able to see where this procedure fits into the broader web of processes within the organisation. And of course, a SOP without linkages to the other components of the business model (eg metrics / KPIs, rules and goals) may not be meeting the organisation’s needs.

Therefore, in the interests of avoiding duplication, inconsistencies and disconnection I think that it is more useful for a SOP to refer to the definitions, other procedures, supporting documents / tools (eg data tables and systems), business goals, business rules and policies that are documented elsewhere rather that reiterating them all within yet another document.

I recognise that this may be tricky to do and maintain within a large organisation, but there is a saying about aiming for the stars and ending up on the moon, not in mud, or somewhere above mud anyway… I really should find out the real words as I don’t think this misquote is helping my case today! But my point is that any steps an organisation can make toward this type of structure and rigour is helpful, even if the ultimate end product never eventuates.

I will end today’s post there before I get tempted to waltz off along another tangent and confuse the topic further. However to summarise, essentially Standard Operating Procedures are documents that hold the know-how for individual tasks that must be carried out within a role. Not only do they present the steps that must be carried out, but they identify the rules, terminology, tools and other aspects of the procedure that a person undertaking the procedure must be aware of. And if the SOP gets out of date because improvements have been identified? Well that’s the aim! It shouldn’t take much to update an existing SOP, and should make it easy to formalise a better way of work – so we can all live SOPily ever after. Just like the yellow guy at the top of this post (he’s supposed to look ecstatically happy)!

What do you think?

Is it necessary to have Standard Operating Procedures to be a successful organisation? And how can adaptive management hot spots best be identified in a SOP?

What do you think?