So, You Want to Write an SOP?

A standard operating procedure (SOP) is a procedure that is specific to your company or organization that describes the activities necessary to complete a particular task. Some would say that writing an SOP is both a science and an art form. There’s a lot of truth in that. I have to admit that I’ve seen a number of approaches for writing SOPs, some that I liked better than others. I’ve seen SOPs that to say were “minimalist” would be an overstatement. I’ve seen SOPs that could be considered novels. I’ve also seen the impact of poorly-written or non-existent SOPs.

Writing an SOP is both a science and an art form.

My thinking about SOPs has evolved as well, and I’ve become a believer in documentation in bite-sized chunks, with each document having a clear purpose. The way I approach it, the SOP is one of three types of documents that should be in an SOP manual:

• Policy. Answers “Why?” Provides broad, overarching guidance.
• SOP. Answers “What, when, and why.” What needs to be done, when does it need to be done, and why is it being done. There may be multiple SOPs that support a specific policy.
• Work Instructions. Answers “How.” A work instruction (WI) provides the step-by-step directions for accomplishing a particular task. There may be multiple sets of work instructions that support a specific SOP.

Why Are SOPs So Important?

SOPs are a primary way to implement or enforce a policy. Policies are intended to steer an organization to achieve the mission, vision, and goals of an organization, but without SOPs, are not actionable. SOPs also encourage consistency in execution, which is critical for demonstrating compliance with or achievement of targets described in a service level agreement.

Challenges in Writing SOPs

One of the most significant challenges in writing SOPs is that there are no hard and fast rules for writing them. A format or writing style that works for one organization may not work as well with another organization.

Secondly, SOPs can become out of date very quickly if not regularly maintained. The business is ever-changing and evolving, and as a result, IT changes and evolves as well. If SOPs aren’t maintained as part of those changes, they will become obsolete.

Things to Consider

While there is no right or wrong way to write an SOP, there are several things that you must consider when writing an SOP. SOPs must be: 

• Readable. This means legible font sizes, numbered pages, titles, numbered paragraph headings, and effective use of whitespace.
• Consumable. Using a template or predefined format makes the content easy to read.
• Understandable. To be effective, SOPs must be focused and to the point, using relevant, but simple terms.
• Actionable. SOPs must clearly and succinctly describe what is to be done.
• Measurable. The activities described within an SOP must be specific and measurable.

A Plan for Writing an SOP

Just like you wouldn’t begin a journey without knowing where you were going, writing SOPs should not be done without having a plan. To develop a plan, first draw a simple flowchart to map the activities of the procedure from beginning to end. This helps form the outline and scope of the SOP as well as confirm the sequence of activities.

Next, combine any closely-related topics so that the SOP becomes more concise and readable. For example, the flowchart may depict an activity for capturing a caller’s name, followed by an activity for capturing the caller’s contact information, followed by an activity for capturing location. These three activities could be combined under a single activity called “Capture caller information.”

Randy Celaya makes the case for SOPs in The Benefits of Standard Operating Procedures for Tech Support.

Check to ensure for the right balance regarding the number of activities within an SOP. If you don’t have enough detail, the SOP is useless; it’s not worth reading. If you have too much detail, the SOP is useless; no one will read it. I recommend keeping an SOP in the general range of five to seven steps. This approach helps with readability and censurability—sufficient depth without being overwhelming.

Now revise the flowchart to reflect the actual number of steps and number each step. Now you’re ready to write a concise, focused description for each of those steps.

Finally, with the heart of the SOP written, write a brief, opening overview paragraph that briefly describes the topic of the SOP, inputs, output, expected results, and involved roles. When you do this, a reader can quickly determine if the SOP is the correct one for a particular job.

Five Guiding Principles

I follow five guiding principles when writing an SOP:

• Keep it simple. Keep in mind that especially at the Service Desk, the SOP is likely to be referenced while handling a customer contact. The SOP should augment and reinforce training; it is not a substitute for training.
• SOPs must be portable. Even if an underpinning application or tool is changed, the “what, when, and why” generally will not. This is why I use work instructions to map the SOP to the underpinning tool.
• Flowcharts and diagrams tell a story. People learn and interpret information in different ways. Some people like to read about how something should be done, others like to see “the big picture” and then read the details. Having a flowchart or diagrams (as appropriate) is a great way to quickly communicate what activities are addressed within the SOP.
• Consistency counts. Develop and use a consistent format or template to help make the SOP consumable.
• It’s about the audience. However you write your SOPs, keep in mind that you’re writing them for your audience. If the SOP does not work for your audience, your SOP doesn’t work. Conduct regular periodic reviews of SOPs with the people that use them to identify and incorporate improvements.

Ready, Set, Write that SOP!

Writing SOPs is often considered a mundane, tedious job, but it doesn’t have to be.  An effective SOP depends on several factors, like readability, understandability, and measurability, but it doesn’t have to be an overwhelming job.  Put together a plan and give my guiding principles a try.  If you do, I think you’ll find that writing SOPs will become a differentiator for your IT organization.