“SOPs keep planes in the sky, trains on the tracks, and televisions on and operational.” (*)
By writing this blog post, we wanted to elaborate on the what and how of both form and content when compiling a standard operating procedure.
SOP: say what?
Standard or standing operating procedure, is a set of written step-by-step guidelines or instructions for the completion of a routine task. Basically it is a checklist, used for and designed to increase performance, decrease variation, improve efficiency, and ensure quality through systemic homogenisation.
The term ‘SOP’ was first recorded in the mid-20th century. One famous example is the checklist pilots need to complete before take-off. Even though these standard operating procedures are used in various context such as health care, industry, the military, they all systemise individual steps performed in the implementation of a repetitive task to create an overall quality system.
AppSaloon’s SOPs
When we decided to start using SOPs within AppSaloon, this was Spring 2018, we also created an overview document containing all existing SOPs’ locations, making it easy for the team to find them and view what each individual SOP is about. Because our team has grown a lot over the past few years, the importance also increased in documenting procedures and gathering know-how in these documents, making them available for everyone.
By October 2019, AppSaloon is using over 40 SOPs, divided into categories (development, privacy & GDPR, HR, ….). Managing this SOP growth also requires an SOP template, containing guidelines on how to write and compile an SOP. This template also provides a short SOP on how to use it… Meta, much?
SOP do's & don'ts
Which criteria should you consider when starting to document your organisation’s procedures and standardising them?
Index:
- Indexing SOPs is important, make sure they have a number, a category and a title making it obvious for everyone what the procedure is about.
- Develop a box or table above which mentions the following fields:
created by: {name}
in use since: {date}
status: draft / under review / live
to be reviewed by: {name}
reviewed by: {name} on {date}
to be tested by: {name}
tested by: {name} on {date}
purpose: {describe purpose in 1 short sentence}
Purpose & scope:
- Explain why this SOP is important, what is the scope and the purpose of it
- Which problem(s) can be avoided by it, which situation are you trying to avoid by writing this SOP
- Mention which (quality) standard you are trying to reach
- Who is impacted by it
Checklist:
- Which precise steps need to be followed?
- Wonder whether a checklist could be useful: an easy way to do this is creating a ‘template’ checklist in Trello: a Trello card including a standardised checklist which can be copied by anyone who is completing the SOP
- Make the order of actions chronological
Help: ask for help if you do not have the info or knowledge available to write a specific (part of an) SOP
Language:
- don’t make sentences too long
- use imperative mood
- use language you and everyone in your team can comprehend: everyone who is going to use the SOP in the future should be able to understand it and reproduce every step in it. Don’t write it for yourself.
- add definitions if necessary, explaining specific jargon
Structure: divide into logical parts keeping the overview and making it easier for colleagues to find the required part of the SOP
Visualise: add URLs, flowcharts, images, screenshots, examples, text or code snippets
Specify: do not leave out sub-tasks and descriptions
Responsibilities: if more than 1 person follows the SOP, state who takes action
Due dates: specify deadlines if required
Troubleshoot: identify potential problems in the process and offer solutions
Criteria: offer tools to measure improvements or changes (f.e. conversion rate)
Revisions & tests:
- have the SOP reviewed and tested by someone (if possible, a non-developer)
- fill out who and when tested and reviewed the SOP in order to track changes
Additional info: mention background information of references for additional input or help understanding certain words or actions, or references that support your procedure
Conclusion
After reading all this you might ask yourself: do we really need that many fixed procedures? Do we need an SOP for everything? Most certainly not. The more, the merrier is not something that applies here. The downside of standardising your business procedures is that it limits individual freedom and creates extra paperwork. We try not to create an SOP just for the sake of it. But certain procedures have become very well documented and detailed.
Standard operating procedures cannot be rigid but need to evolve, be reviewed and updated on the go. Using checklists cannot mean an organisation is hindered to change or grow. And, by using documented procedures, you can document the growth and the changes made in your organisation. You are documenting your organisation’s history!
Sources :
