The Ideal SOP

One of the greatest compliments I have ever heard paid in this industry is “By the time she’s finished with the SOPs, you might even want to read them.” But what a sad indication this is of the general opinion of the documents on which we depend.
Standard Operating Procedures are supposed to describe the procedures and best practice we follow in order to remain compliant with the regulations that govern the pharmaceutical industry. They guide us in our work to ensure that processes are followed consistently and there are few surprises. If something does go wrong, they tell us what to do about it and how to record it. But none of this is of any use if no-one reads them.
“But of course people read them!” you cry. “We make every new starter sit down with a heap of documents and sign to say that they’ve read and understood them!” Well yes, but I doubt that much of what is read is retained, and the new starter probably learns more from the people they work with than from the SOPs. And staff who have been doing their job for some years have developed their own way of doing things and only refer to an SOP when it’s sent round for reading after an update (if then). This is borne out by the number of observations resulting from regulatory inspections that cite ‘failure to follow procedure’ as an issue.
Writing instructional documents is an art. Many of the SOPs I’ve seen are either lengthy, or are not structured in the best way for the users, or use over-formal or over-technical language or are simply badly written. Often these problems are seen in combination, so anyone trying to read them has to struggle to comprehend what they are actually supposed to do, particularly if theirs is only a small part of a longer process.
So how can you improve things? Well, there are some golden rules:
1. Always prepare a flowchart of the process you are writing about before you even put pen to paper (or fingers to keyboard). Flowcharts provide a structure for the SOP. Often a rough sketch will do, although for cross-functional processes it’s best to get a few people together and do it properly. You can use the flowcharts later for training (or, indeed, include them in your SOP).
2. Use straightforward language. Technical terminology is fine for technical people, but it makes reading hard work and most people switch off. If you do use technical or local terminology, make sure that it’s standardised and explained. Keep sentences short, too, so that your reader has to take in only a small amount of information at a time.
There is a tendency among some SOP authors to use the language of 21 CFR: “ x shall be done”. There are several problems with using this style for SOPs. Firstly, I rarely see it used either correctly or consistently; it’s usually mixed with other styles which makes for very odd and stilted reading. Secondly, it’s easy to forget to state who should perform the action. Thirdly, it’s simply off-putting for most people.
3. Think about the layout. Lay out the information in your SOP in such a way that its structure becomes clear. If your headings all look the same and your text all looks the same, the document is not only dull and uninviting, it doesn’t provide your reader with any clues as to how the different chunks of information are related to each other. Do use different levels of heading, and use white space to help show how information is arranged. For example, you would leave more space between sections of an SOP than between the different steps within a section, and more space around higher level headings than around subheadings. Use numbered steps and bullet points appropriately (number where the sequence is important, bullets where it isn’t).
4. Ask someone else to read your SOP, preferably someone who is unfamiliar with the process described within it. And make sure it’s someone who won’t be afraid to tell you if a sentence isn’t clear. Even the most seasoned writers can write a sentence that makes perfect sense to them but may be ambiguous to someone else.
There’s a lot more I could add about improving your SOPs, but this would turn into a book! Let me just give you one example.
I was sent an SOP on which a great deal of time and effort had been spent. It was quite long and detailed but neatly divided into different sections so that it was quite clear where information could be found. So far so good. But the feedback the authors were receiving was far from positive. Why?
The SOP was about material control – the different statuses that existed for raw materials coming in to the plant and finished product going out, including quarantine, pending release, released, rejected, and so on. For each status (or ‘disposition’) the authors had listed when it was to be used, how it should be entered on the material control system, what labelling and location was allocated to each, and so on. The trouble was, what the end users needed to know was "What do I do when I receive raw material?” As it stood, they would have to search through the SOP until they found the information for the first status (quarantine), then search again for the next status (pending release), and again if they needed to reject it. The information was all there; it was just spread around. So I suggested to the authors that they rearrange the information according to the different processes that occurred: raw material receipt, finished product release, management of returned goods and so on.
Ironically, the authors had prepared some superb flowcharts but hadn’t used them as the basis for the SOP. What a lot of work they could have saved themselves if they