I often help customers automate their business processes with Server Automation. I start by gathering information about the process. In many cases, people do not know how the entire process works. They will know their step in the process very well, and everything goes smoothly—until it doesn’t.
For example, an employee leaves for vacation. Will their stand-in be able to complete the tasks? A new worker joins the company. How will they learn the process? A standard operating procedure, or SOP, makes it possible for work to continue smoothly in these scenarios. An SOP is also a go-to resource for when questions arise.
Businesses and teams of all types regularly find themselves in need of writing an SOP, or standard operating procedure. In this article, we’re exploring the basics of SOPs, including:
- Defining what SOPs are (and aren’t)
- Highlighting the benefits of SOPs and SOP libraries
- Outlining steps for writing your SOP
- Sharing best practices and real-world examples
What is an SOP?
When automating a business process, one of the first things I look for is an SOP. IBM defines an SOP simply as “a set of instructions that describes all the relevant steps and activities of a process or procedure.” It’s crucial that organizations know what is needed to complete certain tasks or processes, and an SOP offers that guidance.
An SOP lays out the tasks and roles needed to achieve a policy outcome. This removes the reliance on one person to know how to complete a task, or a set of related tasks. Anyone, then, can consult a single SOP or a group of related SOPs to determine what steps are needed.
Used correctly, an SOP describes in detail the implementation of a business policy. This includes:
- Fulfilling policy requirements such as regulatory policies, internal standards, and/or industry best practices.
- Mapping the applicable policy, standards, and practices to an explicit, step-by-step set of actions.
- Defining the goals that the process will accomplish, and breaking these into individual steps to achieve that goal.
- Assigning the roles responsible for carrying out each step.
Importantly, I like to highlight what an SOP is not: SOPs are unlike work instructions (WI) which contain specific instructions using specific tools. Work instructions flow from the steps of an SOP: an SOP describes “what” needs to be done, and WIs describe “how” it is done. (Read further for a real-world example of this difference.)
When and why to write an SOP
Broadly speaking, an SOP takes organizational policies, goals, missions, and visions and turns them into actions. The SOP gives tangible, real-world guidance to help put appropriate policies into place. In addition, it helps to provide consistency in how tasks are executed throughout an organization.
More specifically, there are a number of organizational benefits that SOPs offer:
- Help your organization meet compliance standards
- Adhere to schedules
- Simplify and maximize production/output
- Set safety standards
- Support training efforts
- Ensure business activities have no adverse environmental impacts
- Prevent organizational failures
The business value of an SOP library
As you create SOPs, you are also creating a library—a place to reference all of your operating procedures. A single SOP is useful to the people directly involved in that task, but an entire body of SOPs provides high-level context and shows how tasks are related. A library of SOPs provides many benefits:
- Helps workers define and learn their role and responsibilities
- Promotes consistent outcomes
- Delivers a key step in the implementation and verification of business policies
The SOP will also help your employees learn how to fulfil their responsibilities and communicate what is expected of them. Additionally, SOPs introduce other groups and roles to the reader to better understand their actions in the larger context of the company.
As a written record of “what” needs to be done and “who” should perform the work, SOPs lead to consistent outcomes. The step-by-step descriptions ensure a task is fully completed according to expectations. By assigning a role to each step, the SOP ensures the correct people/teams are completing the right steps.
Finally, an SOP library helps fulfill business policies. Business policies are implemented via SOPs. In turn, the steps in the SOP are performed according to the work instructions. The output of the work instructions demonstrates the fulfillment of the business policy. A cycle is created from policy to SOP, SOP to work instructions, and the output of the work instructions shows the policy is successfully carried out.
The process for writing an SOP
The process for writing an SOP is unique for each organization, so it’s important to find a drafting process that fits your team’s specific needs. Rather than getting overwhelmed by the idea of this process, utilize these tips and steps to put together a plan. Once you’ve developed a thorough plan and system, trust that system to help you create an effective SOP that your team can utilize.
Of course, there are a few things that you should always consider when starting to write your SOP:
- First and foremost, make your SOP easy to read, understand, and use. If not, it won’t be utilized and, thus, won’t be effective.
- Make your SOP actionable. Your audience should know exactly what actions to take to meet the specific task or goal.
- Make your SOP specific and measurable. This will ensure that you can evaluate the effectiveness of a process while adjusting as necessary.
Guided by these three SOP principles, here are the steps you can follow for writing your SOP:
Keep the end objective in mind
When you’re ready to draft your SOP, start with the end in mind. Consider what you want the SOP to achieve and all activities, from beginning to end, that are necessary to meet this objective.
To help, consider mapping out the activities with a flowchart or diagram to help understand every aspect of the process. Doing so should give you an outline, scope, and sequence of the relevant procedure.
Balance depth and usability
From your outline, you should have a clear understanding of each step of the process. It’s important, however, to consider which steps can be combined, which can be eliminated, and which ones need to be expanded.
One of the most challenging aspects of drafting an SOP is ensuring that it has enough detail to be usable by your audience, but not so much detail that your audience doesn’t want to use it. Experts recommend having 5-7 steps per SOP. Before writing your SOP, work to ensure that your outline has adequate detail but not so many steps or so much depth that it’s overwhelming and unusable. (For more details, see the section on being concise.)
Draft the SOP
Once you’ve revised your outline and any applicable flow charts or diagrams, draft your SOP. It may include:
- A title page. This should have the title; SOP id number; the date it was drafted or revised; the name of the organization, role, department, or division that it applies to; and the names and signatures of individuals that drafted or approved it.
- The relevant procedures. Start this section with a short introduction that conveys what the SOP is about, what it’s intended to accomplish, and to whom it’s applicable. This introduction should guide users through the SOP. In addition, include the scope of the SOP; any details that are needed to accomplish each step of the procedure; clarification for any ambiguous language, including acronyms or terms that are not widely known; and any supplies or equipment that are necessary to complete each step.
- Additional sections such as table of contents (only for longer SOPs), health and safety warnings (depending on the procedure/task you’re describing), troubleshooting tips, and a glossary for defining any acronyms or jargon.
Once you’ve developed a successful SOP, use that structure as the template for all SOPs. While there are many options for formats and no single style to use, be consistent with your format. This makes it easier for your audience to navigate and benefit from the SOP.
7 tips for the most effective SOPs
An SOP that can fully reach its potential has the following characteristics:
1. Focus on the process—not the tools
An SOP should focus on the process, so try to be tool- or software-independent. As we stated earlier, SOPs are unlike work instructions (WI). Work instructions are tool-specific instructions, whereas our SOP is the process.
For example, a customer wants to automate the process of promoting software to a testing environment for proper testing. An SOP may have these steps:
- Developers notify release engineers when code is ready to be tested.
- Release engineers copy code to the test environment from the development environment.
- Release engineers notify QA team that the code is ready to be tested.
The WIs that would flow from this SOP will be instructions around using tools such as FTP to transfer the code, and so on. To automate this, I follow the same process and use Server Automation where possible. The process stays the same, but the WIs will be different, as they’ll reflect the new tools.
2. Be concise
An SOP should be short, readable segments that describe how to accomplish a specific task. If there are too many steps, consider splitting sub-tasks into separate SOPs that reference each other. This results in SOPs that are easier to read and understand, and you’ll already have a working SOP library.
For example, a customer may have an SOP that describes the entire software development lifecycle process, starting with initial development through testing and deployment to production. This is a large process with many steps. Realistically, a reader seeking guidance on promoting code to production would not be interested in initial code development. A targeted SOP on migrating code to production would let the reader stay focused on this specific task.
Some logical break points in this software development process example could be:
- Develop code in development environment.
- Promote code to testing environment for proper testing.
- Promote code to production.
Each of these break points could be covered by its own shorter, easier to digest SOP.
3. Write for your audience
For your SOP to serve its purpose, it must be relevant, helpful, and usable for its audience. As a result, write your SOP for your audience. Consider factors like
- Prior knowledge
- Whether you’re addressing new employees
- Relevant factors or context Industry-specific language.
Inherently, the readers of your SOP are looking for guidance and direction, so they may not be familiar with specialized terms associated with the steps of the process. With this in mind, limit the use of jargon or other specialized terminology that may confuse or mislead the reader. (Should you need to use specific acronyms or jargon, consider adding a glossary section to clarify meaning.)
I helped a customer automate deploying patches to their production environment. To document the new process, I put together an SOP of the steps involved. One of the steps used the phrase “smoke test” which refers to “…the preliminary check of the software after a build and before a release to finds basic and critical issues in an application before critical testing is implemented.” However, the customer’s testing group internally uses a similar phrase for testing how much load can be supported by a given hardware. That is, they increase the load on the server until it starts to—metaphorically—”smoke.”
This example illustrates how the phrase “smoke test” had one meaning to me as the SOP writer, but it had a very different meaning for some readers. Instead of using the phrase, the SOP should be more explicit without jargon to avoid any potential misunderstanding; e.g., “…execute short, quick tests to ensure base level of functionality.”
This is perhaps the most important factor to keep in mind.
4. Clearly define steps and roles
The SOP should have explicit steps to provide clear direction to the reader. Each step should also note the role responsible for carrying out the step. Explicit, actionable steps make it clear what needs to be done. Mapping each step to a responsible party clarifies who should do the work.
In addition, it’s important to identify the role(s) responsible to avoid situations where people think somebody else is responsible for a task. The SOP should always describe what needs to be done and who should do it.
5. Seek input from relevant team members and stakeholders
Seeking additional input isn’t necessary for all SOPs, but it’s worth considering especially because a successful SOP is used by the applicable teams. Talk to them before, during, and after the drafting process for input and feedback.
6. Test your SOP
Once drafted but before it’s put in place, test the SOP to ensure that it is accurate and usable. Further, have other team members test it too. This will help you identify and deal with any problem areas before it’s put into action.
7. Review regularly
Policies and processes change over time. IT businesses change rapidly. The SOP itself may be unclear or incorrect. How do you prevent your SOPs becoming obsolete?
SOPs should be updated as changes occur, and reviewed on a regular basis for clarity and correctness. When I automate a customer’s existing process, we often find ways to improve them. Discussing and reviewing a process often results in finding steps that are redundant or obsolete and can be simplified.
Schedule a review of the SOP at least every 6 to 12 months. This will enable you to identify and update any obsolete areas, using your specific and measurable goals, to ensure that the SOP continues to be relevant and helpful to the people who use it.
SOPs for IT processes
As you can see, SOPs play an important role in IT. By following the best practice outlined above, the SOPs will have the right level of detail around what needs to be done. They will ensure that operations remain consistent even when people are on vacation or are new to the team. Lastly, an SOP library will help safeguard your operations and business from costly downtime or other issues.
If you need assistance with developing SOPs for your operations, fill out our form and an expert will contact you to see how we can help.
Additional resources and examples
For examples of real SOPs, see these articles:
