Stage 6 – How to Write Standard Operating Procedures

sop-write-first-sop

This is Part 6 in our series on writing Standard Operating Procedures. If you’ve missed the first five, sign up for the newsletter and the whole set of tutorials will be sent to you automatically.

How to Write Standard Operating Procedures

Next up, write the procedure. First, let’s take a deep breath and see where we are.

So far, we’ve:

  • Shared our vision with the Management team so they understand how all Departments, Business Units, Customers and Staff will benefit from this activity. Getting support from Management is crucial as their support will give the project the attention it deserves especially when you hit bottlenecks.
  • Defined a writing process for the procedure writers and those involved in all associated procedure-related activities, for example, testing that the procedures work as per the instructions. Note that some procedures can only be tested in a live environment and need to be managed with care.
  • Gathered the documents, process maps, flowcharts, and other material we needed to assess the procedure
    Interviewed those who use the procedure in a working environment, for example, the Call Centre staff if you’re writing Technical Support procedures.
  • Interviewed those who prepared the current procedure and asked for their recommendations on how it could be improved.
  • Collated all the material on the shared server (maybe password protected if you’re concerned that others are too curious about works in progress.)
  • Updated the Project Stakeholders every week with Status Reports.
  • Sent reminders to other parties that you will need time with their staff in the coming weeks. Always give advance notice. You’re colleagues have their schedules too.

Structure the Writing Project

Large companies have libraries of SOP templates for such projects. They will also have invested in Style Guides, Writing Manuals and other materials to assist their writing teams.

If you don’t have these, buy some professional Procedure templates on the web so you can hit the ground running. Make sure the templates work on your PCs, are easy to modify and within budget.

Of course, you can always create your own – choose whichever is most cost effective. Time lost is money lost. Use common sense and get started.

How to Write Procedures

This week we’ll look at how procedure writing at a high level. In the coming weeks, we will drill down and show you how to write procedures from scratch.

Before you start writing, do the following.

  • Naming Convention – Establish a Naming Convention for the documents. Think ahead. If you have 200 procedures to manage, what naming convention would work best to track the documents.
  • Web Friendly – Remember, SOPs may also be published to the Internet, so use a system that is intuitive and easy to follow. Don’t get too esoteric!
  • Share – Create a Shared Drive where all the writers can post the documents. Password protect the drive, if necessary.
  • Style Guides– Invest in Style Guides and other support material. Make sure there are enough copies to go around. Some will hog the guides and resist sharing.
  • Templates – Develop a set of easy-to-use templates. Don’t make them so complex that writers need to be trained to use them. Keep it simple and assume that others (non-team members) will use the same templates to update the procedures.

Tip: Number each procedure. Use Excel to record and track each procedure.

Tell me more about Naming Conventions!

Instead of calling the document, Health Procedure.doc, give it a more meaningful title. For example, ACME-Pharma-F-SOP-05052009.

ACME refers to the name of the company or client or project
Pharma refers to this division within the company
F refers to Final. D can be used for Draft.
SOP refers to the document type.
05052009 is the date the document was signed off.

Using a naming convention will allow you to retrieve documents faster, especially if you have multiple versions of the same document all with different sign off dates. You want to avoid making the reader open each document to determine the version numbers.

If you use MS Word, use the File, Properties option to add further information, such as keywords, Author name, and other comments.

Writing Your First Procedure

Procedures are instructions. So, put yourself in the user’s shoes and write from their perspective. In other words, unlike other types of documentation, you don’t need to give the reader very much background details.

Do the following:

  • Write in the Present tense. The user is performing the task NOW. Don’t write in the past, conditional or future tenses unless you have good reason to do so.
  • Avoid Ambiguity.
  • Be concise.
  • Use short words. This isn’t a romantic novel you’re writing. Keep the words short and get to the point.
  • Move from one step to the next in a logical manner. Steps should follow each other in a logical order.
  • Highlight Exceptions. Use a symbol to flag that this is an exception and how to handle it.
  • Highlight Warnings. Again, warn the user that caution must be used in this scenario. Warnings MUST stand out. Use a larger font or a warning icon.
  • Reduce the word count where possible without altering the meaning of the text.

Do Not:

  • Introduce acronyms without explaining what it means. What does OLA mean to you? I know but most folks don’t.
  • Be Vague. Don’t use the work ‘may’ if possible as it implies that the user can do something under certain conditions. Instead be positive and tell them what to do.
  • Get the sequence wrong. Steps have to be in the correct order.
  • List steps that should be numbered. What I mean is that some items can be listed, for example, a list of ingredients when cooking. But, you need to number the steps in the correct order so the cook can prepare the dish.

Finally, the process of writing a SOP requires the writer to consider all steps in the procedure and perform a risk assessment before work begins. The best approach to writing a SOP is to perform the procedure, write it and test it, write it again.

Number Each Step in the Procedure

Every procedure lists the actions that the reader must take. To keep things simple, we list the actions (aka steps) is sequential order. Start at 1 and work upwards.

Note that some Business Analysts prefer to start at 0 and continue from there. Starting at 0 is used in Project Management documentation and often crosses over to other business documents.

Which is Right?

What’s important is that you choose one style and be consistent. Don’t change styles. Make sure your co-writers also use the same numbering system.

Also, if you’re using MS Word to write the documents, you can take advantage of the automatic numbering system. If you opt to start at 0, create a unique Style for numbering the steps and use this instead.

One word of warning: if you share writing duties, you may have to remind the other writers to start at 0 instead of 1. I prefer to keep things simple and start all lists at 1.

Why Number Steps?

There’s a few reasons for this:

  • It ensure that the reader starts at the correct place.
    It removes any ambiguity or misunderstanding that could arise if the steps were not numbered.
    It ensures that the reader does not ‘interpret’ the procedure as he/she understand it and makes errors when performing the task
  • It ensures that there is an agreed way for all staff to perform the same task. While this may seem intuitive, in smaller companies staff may performs tasks in different ways as per their understanding, training and preferences. How you backup files may be very different than how your colleagues do it.

How About Exceptions?

There are different schools of thought on this. Number the steps starting at 1 and

Continue upwards, e.g. 2, 3, 4, etc.

Or

Use 1.1, 1.2, 1.3 for sub-steps.

Or

Use If Then Else tables for sub-steps.

If Then tables let you present information is a nice, attractive manner and lets the reader see the different options available to them in a grid format.

How do It Then Tables work?

A simple example is applying for a bank loan.

If Then And
If the value of the property is less than $500k Deposit 10% of value Minimum deposit is 50k.
If the value of the property is less than $700k Deposit 12% of value Minimum deposit is 70k.
If the value of the property is less than $900k Deposit 15% of value Minimum deposit is 90k.

The advantage of using an If Then table is that the user can drill-down and find the EXACT piece of information they need. For example, they need to know there is a 50k minimum deposit.

The alternative is to present the information as a list. While this may be easier for you to write (i.e. you don’t need to create tables) it is harder for the reader to locate the specific piece of information.

  • If the value of the property is less than $500k, you must deposit 10% of value and the minimum deposit is 50k.
  • If the value of the property is less than $700k, you must deposit 12% of value and the minimum deposit is 70k.
  • If the value of the property is less than $900k, you must deposit 15% of value and the minimum deposit is 90k.

They have to scan the entire sentence until the locate the information and then read the next line to compare one piece against the other. Not easy to do when you’re tired or in a crowded bank branch with small children running around.

Over the coming weeks, we’ll drill down and look at other ways to write your procedures.

Tomorrow, we’ll look at how to test the procedure.

Get free and premium MS Word, Excel and Apple templates today


Acceptance Test Plan

Contingency Plan

Software Development Templates

Acquisition Plan

Conversion Plan

Software Requirements Specification

Action Plan

Cost Benefit Analysis

Software Testing

API Documentation

Database Design

Standard Operating Procedures (SOP)

Audience Analysis

Datasheet

Statement of Work

Availability Plan

Deployment Plan

System Administration Guide

Bill of Materials

Design Document

System Boundary

Business Case

Disaster Recovery Plan

System Design Document

Business Continuity

Disposition Plan

System Specifications

Business Plan

Documentation Plan

Technical Writing Templates

Business Process

Employee Handbook

Test Plan

Business Requirements

Error Message Guide

Training Plan

Business Rules

Expression of Interest

Transition Plan

Capacity Plan

Fact Sheet

Troubleshooting Guide

Case Study

Feasibility Study

Use Case

Change Management Plan

Functional Requirements

User Guide

Communication Plan

Grant Proposal

Verification and Validation Plan

Concept of Operations

Implementation Plan

White Papers

Concept Proposal

Installation Plan

Work Instructions

Configuration Management Plan

Interface Control Document

Software Development Templates

Acceptance Test Plan

Maintenance Plan

Software Requirements Specification

Acquisition Plan

Market Research

Software Testing

Action Plan

Marketing Plan

Standard Operating Procedures (SOP)

API Documentation

Needs Statement

Statement of Work

Audience Analysis

Operations Guide

System Administration Guide

Availability Plan

Policy Manual

System Boundary

Bill of Materials

Project Plan

System Design Document

Business Case

Proposal Manager Templates

System Specifications

Business Continuity

Proposal Template

Technical Writing Templates

Business Plan

Quality Assurance Plan

Test Plan

Business Process

Release Notes

Training Plan

Business Requirements

Request for Proposal

Transition Plan

Business Rules

Risk Management Plan

Troubleshooting Guide

Capacity Plan

Scope of Work

Use Case

Case Study

Security Plan

User Guide

Change Management Plan

Service Level Agreement (SLA)

Verification and Validation Plan

Communication Plan

Setup Guide

White Papers

Concept of Operations

Social Media Policy

Work Instructions

Concept Proposal

Contingency Plan

 

Configuration Management Plan

Conversion Plan