Posted on

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.

Posted on

Stage 5 – Analyzing Alternatives and Contingencies to the As Is Business Process

sop-as-is-process

Yesterday we looked at the Information Gathering Phase and described different ways you can get that information from Subject Matter Experts and those in the frontline who use the procedures.

Gathering Data For Procedures

In general, Business Analysts gather data through workshops and interviews. Emails work too but I prefer to see the white of their eyes.

You can also collect data from reading historical documents which may give more background to the project. These may include Specifications, Requirements and Flowcharts. Gather all these and hold them in a centralized location.

Does the Process Work?

As mentioned in the previous tutorial, we need to test the procedures (aka SOP) and determine if they work. Your goal at this point is to:

  • Determine if the procedure works as documented in the SOP.
  • Identify mistakes or anomalies that have crept into the material.
  • Determine if the procedure has been updated, version controlled, and also if multiple copies of the same SOP are in circulation. It’s not unusual for multiple copies of the same procedure to be in circulation if there is no known Document Owner or if there are no Version Controls in place.

Once you have captured the existing process, share your notes with the team members.

Looking at Alternatives To The Current Process

The next step is to look at alternative ways of performing this process and contingencies that need to be considered when developing the new process.

At this point, you should understand how the current process works. What you want to do is see:

  • Where it can be improved.
  • How the process can be streamlined so there are fewer activities, transactions, manual interactions required.
  • Who needs to be involved in the revised process.
  • What technologies are required to perform these tasks.
  • What parallel processes must be performed for the primary process to work correctly.
  • What sub-processes need to be developed to support the new process.

There are several ways to approach this. One is to look at the actors in the process, (for example, the Cashier) and see how his role could be streamlined.

  • What activities can be removed?
  • What activities could be collapsed into a single activity?
  • What tasks could be automated?
  • What activities could be changed so there are fewer activities later on.
  • What security measures need to be considered, for example, sharing information between department and/or with partners.

Here’s an example from the real world.

When I apply to have my credit card limit increased, the process works as follows:

  • Ivan contacts his Local Branch.
  • Local branch tells me to call another number. They can’t forward me for technical reasons.
  • Ivan called the Credit Card office.
  • Credit Card Dept ask me to fax in the paperwork, e.g. utility bill. They do not accept documents over the web. Oddly enough, you can apply for a credit card and even a mortgage over the web….
  • Credit Card Dept faxes this to Relationship Manager at Local Branch for verification purposes.
  • Local Branch forgets to process my application… Relationship Manager may have moved to different office.
  • Credit Card Dept don’t follow up.
  • Ivan calls Credit Card Dept to remind them to chase up Local Branch.
  • Ivan needs to send over the documents again.
  • Does Ivan do this? You know the answer, I’m sure.

OK, clearly this process could be improved if I could give the documents to my Local Branch  instead and if there was a reminder for the Credit Card Dept to follow-up if they did not hear back from the Local Branch. Otherwise, applications disappear into black hole.

FYI – actually, I did. While re-sending the documents was an inconvenience, I wanted to finish this task and move on to the next thing… which you can read about tomorrow.