Standard Operating Procedures (SOPs) are necessary for any efficient system, and yet their effectiveness can vary widely based on how well – or not – the procedures are written.
Writing clear SOPs is difficult because they serve two distinct audiences: your internal team that has to execute the procedures, and the auditor who reviews them to ensure compliance. The trick is to strike a balance in the content, style, and organisation so they’re easily understood by anyone who reads them.
Know your audience
Keep in mind the following key aspects of potential readers as you create your SOPs:
In general, auditors or FDA inspectors are highly educated, have extensive industry experience, and are well-versed in regulatory lingo and nuances. They know what they’re looking for in your SOPs. Your team, on the other hand, includes people in various positions (e.g. junior developer, senior HR manager, mid-level software designer) with different levels of education, industry experience, and regulations knowledge. And there’s a good chance they’ve never been through an audit or inspection, either.
An auditor she must be able to quickly identify where your SOPs fail to comply with industry regulations. She also needs to use this document to assess whether or not all members of your organisation consistently follow those guidelines. Your internal team, on the other hand, is focused on getting their jobs done. Their goal is to minimise the impact of regulations and quality assurances on their work.
Pain points & challenges
Badly written SOPs are a worst-case scenario for auditors. Not only can they slow down the process, but also ambiguities and inaccuracies can lead to their reporting wrong findings. Your team members, on the other hand, are bothered by interruptions to their daily activities. To them, poor SOPs are obstacles to getting their work done.
Ideal experience with SOPs
Both sides want to be able to scan SOPs to easily find what they’re looking for, but for different reasons: The auditor is looking for keywords and phrases that demonstrate compliance, while all the team member really wants to know is what she needs to do next.
Strategies to write SOPs for all audiences
While writing clear and effective SOPs may seem complicated, there are ways to simplify the process.
- Write both SOPs and Work Instructions: SOPs contain all the high-level details necessary for regulatory compliance, so optimise that document for auditors by using the wording and phrases that they’ll be looking for. Then write a separate Work Instructions document that provides the specific information that team members need to get their jobs done.
- Add a clear workflow diagram near the top of your SOPs. There’s a lot to the old adage “show it, don’t tell it,” although in this case, it’s good to do both. Make your content easily digestible by including a visual to introduce your workflow. A clean, clear diagram is a good entry point for both auditors and team members.
- Use a tool like Confluence for display flexibility. Make your SOPs easy to scan by highlighting key points, with the option to get more details in an expanded view. For example, use Confluence to write your SOPs so you can utilise the “expand” macro. The result will be a short page of content that highlights the main sections and includes brief overview paragraphs . If the reader needs more information, then she can click a link to open the “expand” section. There she will find additional information such as references (which auditors need) or descriptions of how tasks should be completed (which team members need).
- Narrow your SOPs audience by managing your process in an eQMS. A well-designed electronic QMS allows team members to participate in the quality process without referring to SOPs. This means that you can then write your SOPs for a singular audience: auditors. This makes a lot of sense when you think about SOPs like you would a detailed user manual. For example, when was the last time you consulted a user manual to use a smartphone app? Chances are you referred to a quick start guide so you could skip reading all the unnecessary legal and technical information. Similarly, when you implement a quality process in JIRA, you can use what you know about UX optimisation to make it simple for team members to access just the information they need to get their work done without ever referring to your SOPs.
Writing a high-quality, clear, effective SOPs can be tricky, but when you think through how your intended audiences will use them, you can trust yourself to create documentation that works for everyone.