How To Create Successful SOPs: Standard Operating Procedures

In the quest to achieve goals, organizations strive to improve their operations — the ways they work — in order to raise quality levels, become more client-oriented, and meet stakeholder requirements.

In medium- and larger-sized entities, variation is likely to derail these outcomes, however. That’s why standardizing the ways of working is one common technique to ensure success. This involves the definition of process activities in the form of work instructions or procedures.

In this article, I’ll deep-dive into the topic of standard operating procedures, including how to structure and build SOPs and best practices for managing them over time.

What is a SOP?

The ISO 9000:2015 standard defines a procedure as a specific way to carry out an activity or a process.

Standard operating procedures, commonly known as SOPs, are one example of process assets that define work instructions in a structured manner that can be employed across an enterprise. SOPs detail the regular recurrent actions conducted within business functions. Examples include:

• How user requests are handled
• How administrative tasks are executed
• How technology systems are used

Structure of SOPs

Ideally, a SOP is not an independent element, but part of the governance of a management system that includes policies, processes, and procedures, as shown below. In general:

• A policy defines the direction and rules based on the organization’s principles.
• A process defines what activities needs to be done in line with the policy directives.
• A procedure details how the specific process activities will be carried out.

(Related reading: process vs. practice: what’s the difference?)

What to include in a SOP

While there is no one-size-fits-all approach to the structure of an SOP, the general consensus is that the main elements that any SOP should capture include the following:

1. The cover page. This part includes the title of the SOP, an identifier (based on the organization’s document control approach), versioning, author, and approver information.
2. The main content. This part outlines the purpose of the SOP, scope or applicability, and the sequence of activities including timelines and responsible persons. A flow chart may be included where required. (More on this in the next section.)
3. Supporting information. This includes relevant references, definitions, abbreviations, and appendices such as forms and checklists.

(Related reading: how to write IT strategic plans.)

How to develop and write SOPs

The development of an SOP would follow a similar process as other organizational documents. An example of a process is shown below:

Sample SOP creation process

Now let’s look at the phases involved in writing a SOP. Follow these and you won’t miss anything. Keep reading for the section on tips and best practices, which will help support these phases.

Initial request for a SOP

The requirement for an SOP may come from management or a specific team, based on a repeatable operational task that needs to be documented in accordance to business policies and processes. In some organizations, an approval to document the SOP may be sought first before the work to create it.

Documenting, drafting, and testing

The documentation of an SOP may be subject to a document control framework that determines a standardized structure and formatting approach.

The SOP should be drafted by someone with expertise on the actual tasks to be documented.

Importantly, however, that draft should be independently tested by one or more persons with less experience to validate that it serves the purpose. (Because this person is not an expert in the task, they must rely on the SOP draft)

Review and feedback

Once the SOP is reviewed with appropriate parties, the requestor or team responsible for owning the SOP will:

• Incorporate the findings of the testing.
• Provide feedback for any more modifications.

Final approval

Once the draft SOP is reviewed and feedback incorporated, the SOP may go through another approval phase (as outlined in the document control framework). Since a SOP is mainly a document that is local to a team, then the team lead or manager may be the appropriate approver.

Once approved, the SOP is communicated to stakeholders involved in that activity, and may be posted in an intranet or knowledgebase for easy access.

Usage and ongoing maintenance of the SOP

As the SOP is used, metrics should be collected on how it is supporting the relevant business process. (This may be enabled or built-in to the platform/location where the SOP is hosted.)

Conduct regular reviews — at least annually — to determine if the SOP remains fit for purpose in the environment. Incorporate these updates, then update the review information within the Cover Page versioning section.

Once an SOP no longer adds value or has been overtaken by changes in the organization, it should be:

• Withdrawn from circulation.
• Archived as per the document control framework.

(Related reading: the data management lifecycle, from creating to archiving and deleting.)

Tips & best practices for managing SOPs

The value that SOPs bring to an organization is tied to two conditions:

• The way the SOP is written.
• The way it is used.

A poorly written SOP cannot support the consistent performance required by those responsible for executing the tasks. On the other hand, if no one follows the SOP, then the expected gains of quality and compliance will never materialize.

SOPs are an integral part of a well-working management system, so there has to be concerted effort to ensure that the way the SOP is crafted and how it is deployed lead to effective usage.

Writing the SOP. The way an SOP is written matters. Write standard operating procedures in a concise and easy-to-read format, using active voice and present verb tenses. Keep the document size short, the text simple, the layout logical.

Testing the SOP. Clarity and understanding should be key. That’s why the SOP should be tested with less experienced staff members to validate that it can be followed with little or no variation.

Communicating or “socializing” the SOP with others. The organization should then use the most appropriate communication channel to make the SOP known to all who will use it. If an organization prefers collaboration chat systems, then the SOP should be formatted for and communicated through such platforms.

The repositories used to host the SOP should be accessible by all its users, and where the SOP involves use of an IT system, that system’s own data repository (such as a knowledgebase or wiki) should include a link or reference to that SOP.

Monitor the SOP and consider if reporting is helpful. The usage of the SOP should be monitored, at the very least, and reported where necessary. By hosting the SOP on collaborative tools, users can do things like:

• Rate the SOP (5 stars, hopefully).
• Leave comments and questions, which the process owners can use to improve it.

A good idea can also be for users to reference the SOP when actioning their assigned tasks. For example, if an IT system administrator is assigned service request ticket to create a user, they can link the ticket to the appropriate SOP listed in the ticketing system’s knowledgebase. This provides a forum to review the quality of the SOP when analyzing the ticket handling performance.

Final thoughts: SOPs support compliance

SOPs are a critical enabler that support consistency, effectiveness, and compliance within a work environment. No matter the size or sector, use of SOPs can reduce variation in task execution which is crucial for quality and customer satisfaction.

New staff members can be quickly and smoothly onboarded when there well defined SOPs, while the work of auditors is simplified — after all, SOPs provide the best reference for checking whether tasks are carried out according to policies and other requirements such as laws, regulations, and standards.

For organizations with a goal to achieve ISO certification, the presence of SOPs goes a long way in showcasing operational control.