A Standard Operating Procedures (SOP) is a type of procedure that describes how to perform a specific task.
In general, a SOP is given to specific types of employees to help them perform a task. For example, in the military, a SOP might describe how to prepare a specific piece of machinery in a specific environment.
Learn more about this Standard Operating Procedure (SOP) template
Use the following checklist to write the narrative section in standard operating procedures.
Essentially, there are three things to be aware of:
1. The numbering of the steps
2. The description of the actions
3. The accuracy of the steps and actions in relation to the diagram.
Later, we’ll look at how to write the actual procedure. But, for now, let’s agree on some guidelines for documenting the narrative. The narrative is the text which accompanies the process flow diagram.
1. Start at Step 0. Identify the first step in the procedure, which is the formal starting point in the procedure. Identifying Start as 0 is the simplest way to capture it.
2. For the steps, use a X.x numbering convention for the steps. This allows you to group actions under the same number and avoid having a very lengthy number list. So, for example, go from 1.0, 1.1 etc, to 5.0, 5.1 etc instead of going up to 25.
3. For the actions, use the active voice.
4. State who does what.
5. Write the actions starting with a verb. For example, Step 2: Print page. Step 3: Save page. Here Print and Save are the verbs. This type of phrasing works as it identifies immediately what to do at each step.
6. Be as concise as possible. Remove filler text but make sure, in your enthusiasm, you don’t delete any necessary information.
7. If possible, distill the description into a single sentence. If this is not possible, identify the most important action first, then add additional text to explain, clarify or warn the reader of something they should be aware of.
8. Describe one action in each step. This helps the reader see, at a glance, what occurs at each step. It also helps them check against the diagram.
9. Avoid the temptation to merge multiple actions into a single step.
10. Be consistent in the Yes No order. If 2.1 is Yes, then in 3.1, use Yes. Don’t change the sequence as this breaks the rhythm of the procedure.
11. When adding Yes and No to the lines, put them slightly above the line not in it. Placing the text on the line make it more difficult to read.
12. Where possible use straight lines.
13. Make arrow heads connect to the target shape. Don’t let it hang.
14. Make arrow heads straight.
15. Use consistent colors for your shapes.
16. Remove filler text from descriptions.
17. Identify the final step as the End.
18. If necessary, add a third column to your table. Use this to identify the product or system which performs the action. If tasks are performed by more than one actor, for example, some by a person, some by a CRM system, and others by database, then consider identifying the actor in its own column instead of describing it in the Action column.
19. Check the procedure by starting at the end and working up to the start.
20. Print out the process flow diagram and identify each step. If necessary, use a pen and draw a circle around each step. This ensures that you check each activity on the diagram. If you’ve missed something, you’ll see it immediately.
How can you write procedures so that readers can perform the task correctly, the first time and every time?
Most procedure writers make the mistake of adding too much information, and cluttering up the text, or leaving critical information out, so the reader can not perform the task. In this tutorial, let’s look at how to reduce the word count and refine the text.
When I first started on this article, I wrote:
Procedures need to be written in such a way that the reader can follow the task.
Then I changed it from passive to active phrasing. Here’s what you get:
Write your procedures so readers can perform tasks correctly.
Remember, this type of phrasing doesn’t suit all types of procedures but keep it in mind. You don’t have to slavishly write in the passive voice. If appropriate, use the active voice. The word count shrinks immediately.
Learn more about this Standard Operating Procedure (SOP) template
Download this template – MS Word
Download this template – Apple iWork Pages
Here are five practical ways you can improve your procedure documents.
Instead of writing large blocks of explanatory text, distill the information into short bullet points. If you cannot boil down the text to a series or bullets, i.e. highlight the key points, you may need to step back and gain a better understanding of the task.
In general, most procedures will have heading for pre-requisites, how to perform the task, and next steps. Use these to orient the reader and reduce ‘bridging’ text between sections.
Lead sentences introduce the procedure. Most are redundant. Examples of lead sentences are:
[heading] Printing the page
[lead sentence] To print the page, follow these steps:
[procedure] Step 1. Click this button to do this.
In this example, the lead sentence adds no value. The reader will typically skims over this and go straight to the first step. So, if they’re ignoring this text, what’s the justification in keeping it?
However, if you need to provide explanatory information in advance, such as a warning or recommendation, then include it here. Otherwise, it’s hard to justify.
For example, if you have three steps as follows:
You could merge this into one line.
Or
Most users will get this.
Shorten the text but make sure nothing is lost.
There is no one size fits all when it comes to good procedure writing. Use this checklist as a reference and adapt each item to your materials. Any questions, drop me a line.
What do we mean by the location in procedures? It’s WHERE the user performs the actual task. Inexperienced procedure writers often assumes the reader will know where to perform the action. But this is not always the case. Often readers are starting cold. How can you fix this?
Learn more about this Standard Operating Procedure (SOP) template
Download this template – MS Word
Download this template – Apple iWork Pages
Procedure writers need to put themselves in the reader’s shoes, for example:
What else would you add?
Should I add screenshots to my procedures? It depends for several reasons.
For example, when writing SOPs, I prefer to add a high res process diagram at the end of the procedure. This shows it connections to other procedures and exchanges between actors. However, sometimes it helps to include a procedure in the procedure if, at that specific steps, the user needs a visual cue to help them understand how to progress.
Learn more about this Standard Operating Procedure (SOP) template
Download this template – MS Word
Download this template – Apple iWork Pages
Mistakes to Avoid
When to avoid:
Action steps are the individual steps performed in a procedure. Most procedures are performed in a sequence, however, you also need to consider other factors, such as multiple choices when performing a task, its secondary tasks, and other related procedures. To round off the procedure, it helps to put it in context – where does this occur in the larger scheme of things – and also things the user should do before getting started (prerequisites) and warnings (things to avoid or).
Learn more about this Standard Operating Procedure (SOP) template
Download this template – MS Word
Download this template – Apple iWork Pages
In procedures, the following five words are often used incorrectly. To avoid these mistakes, do as follows”
What other terms or phrases are often written incorrectly in procedures? Let me know and we’ll discuss it in a future blog post.
Learn more about this Standard Operating Procedure (SOP) template
Want to improve the title of your procedures? Let’s look at some ways to make the title more useful to the reader and also reflect the exact nature of the task.
The title of your procedure serves several purposes:
Two other ways to improve your procedures:
What else would you add?
In this procedure writing course, we look at different ways to improve your SOPs, processes, and instructions materials, so you have a consistent and effective writing style. Sometimes, it’s the small things that make a difference. And a good example of this is when to do with OK, Ok, and Okay. Which one should you use when writing procedures?
Something to consider is that each has it’s own place. The more you write procedures, the more you’ll understand when and where to apply these.
Note: do not use the and button when documenting the OK button in procedures.
If you are new to writing procedures there can be a temptation to dress up the language of the SOP to disguise your lack of experience or make the procedure sound more ‘professional’.
The opposite usually happens. The procedure sounds stiff, doesn’t flow, and is often unreadable. Instead, use short words, keep to the point, and help the reader understand the procedure as quickly as possible. In addition, avoid using jargon or industry speak that will confuse reader. And remember that are not everyone reading your procedure is not a native English speaker avoid using phrases or figures of speech that will trip people up. Aim for simplicity.
What’s important here is not whether the procedure is long or short. Instead, look for ways to explain how the procedure works as clearly as possible. In most cases, this means using simple, direct, and concise language. Get past trying to impress the reader – or your boss – and zero in on the task.
Before you start writing your procedure, give some thought to how this will benefit them both from a personal and business level. In other words, you can encourage the reader to use your procedures if you describe the ways their life will be easier if they follow the steps exactly as you have written them. Make sense?
Here’s a few examples.
Look for ways to emphasize these in the benefit section but keep it simple. Don’t distract the reader from their main purpose, which is to perform the task. However, a few sentences at the start helps orient them, place things in context, and creates an expectation of how the procedure will help them perform their tasks.
If appropriate, give a short example, but keep this brief. You can also consider having a follow on section – ie what to do next – at the end of the procedure, suggesting what the reader should do next.
If you are creating online help, you can add these under the For More Information section.
How much information do you need to include in your SOP? One of the dilemmas for procedure writing is working out what level of detail is required when creating SOPs (standard operating procedures).
How do you get the right balance?
The golden rule is to give readers… the appropriate level of detail.
This means you need to outline the procedure in sufficient detail for the user to perform their tasks but not overwhelm them with superfluous information or text that distracts them from their objective.
When I’m working with clients – for example refining an existing set of procedures – I ‘warn’ them that the final document will be shorter, not longer, than what they have today.
Why?
Because I distill the instructions, merge action steps and remove redundancies. The end result is a short, more useful SOP Manual.
What’s our aim?
To write procedures to a level of detail that aligns with the user’s qualifications and training.
How do you find this?
Use task analysis techniques to assess the level of information required.
You may also find that you need to write for several, not one, audiences. If this is the case, consider creating entry level and advanced procedure manuals.
Note: When in doubt, write to the lowest common denominator.
To provide the correct level of detail, examine the following:
Next, examine if the amount and type of information provided are adequate for
intended users. For example:
Conclusion
Your goal is to ensure that users have enough information to complete the procedure… without asking for help or looking at another document.
If they have to do that, then you’ve under-written the document or possibly assumed that the reader would be able to perform these steps.
One of the challenges for procedure writers is to determine the user’s skill-sets, experience and knowledge of the system. If it’s hard to determine this, then err on the side of caution and prove steps for all level of users.
When writing procedures, should you write one or 1?
It’s a small detail but how you use numbers in SOPs influences how others interpret your instructions and perform tasks correctly. In some situations, you should use one whereas in others 1 is the correct word to use. So, which one should you use? And where?
Let’s look at four ways you can write numbers correctly and also some mistakes to avoid.
Unlike other types of documents, you need to be very exact when providing information in procedure manuals.
After all, the person using the manual may be in an emergency situation, struggling to install an application, and under stress. You don’t want to compound the problem by writing vague or ambiguous text.
Here’s how to write clear instructions when you need to provide numerical information.
In this example, we look at when to use a ‘spelled out’ number, for example, two instead of 2.
Here’s the rule:
Use spelled-out numbers when one number – WITHOUT a specified unit of measure – is followed by one WITH a unit of measure.
For example:
Use: “Turn on one 3.25 kV bus.”
Do not use: “Turn on 1 3.25 kV bus.”
In the second example, it’s hard to tell if it’s one 3.25 or 13.25. The first example is much easier to read. It’s the 3.25 kV bus you need to turn on, right?
Along the same lines, use spelled-out numbers when a number, typically a single digit number, is
emphasized.
Do
“Use one of the following:”
Don’t
“Use 1 of the following:”
In the second example, the use of 1 feels incorrect. The problem here is that, although the information is technical valid, the reader will slow down and possible re-read this section.
“Why do they say, ‘Use 1…’ ”
In the final example, this construction
“Reduce speed by 10 kilometers.”
Is preferred to:
“Reduce speed by ten kilometers.”
In the first example, the number 10 is stands out from the text and highlights to the readers, ‘Look, you need to slow down by 10 kilometers.’
In the second example, it doesn’t have the same affect.
Be consistent when using Arabic numbers (e.g., 0, 1, 2, 3) and spelled-out numbers (e.g., zero, one, two, three). Don’t get ‘creative’ and start changing the numbering system throughout the document.
Conclusion
Help the reader become familiar with your writing style and format. Don’t spring surprises!
One way to do this when writing procedures is to remove any possible misunderstanding from your instructions. In other words, look at the numbering systems you’re using and ask yourself if the person reading this could be confused by the way you’re written it.
If the numbers could be misunderstood, then revise the text and use numbers that clarify how the process works.
Why are naming conventions so important in procedure writing?
If you’re responsible for writing SOPs, then you need to develop naming conventions that help you control how procedures are written, reviewed, published, and archived.
Don’t worry – it’s not as difficult as it sounds.
The first question is: what are naming conventions?
In simple terms, this is how you name your documents in a structured manner.
For example:
If you track your documents in an Excel file, they might look like this:
That’s the basics. How about when things get a bit more complicated?
The key is have consistency across the SOPs. In other words, use a naming convention that’s easy to follow, understood by all writers, and meaningful.
Avoid obscure or cryptic terms. Keep it practical. If you don’t, SOP writers may stop using the guidelines and you’ll find it very hard to trace documents.
With that in mind, here are some naming conventions I created for a software company:
ABC-US-0512-D-1
XYZ-UK-0712-P-2
TNT-GBL-1212-A-1
Let’s look at each one.
ABC-US-0512-D-1
This means
ABC – name of the client
US – for the US offices
0512 – published on May 5th
D – Draft status
1 – Revision one
XYZ – name of the client
UK – for the UK offices
0712 – for December 7th (not July the 12th)
P – Published
2 – version two, i.e. It had been revised twice
You get the idea.
By creating a naming convention like this, we can apply these guidelines to all document types. But there are a few pitfalls to avoid. More on this later.
Here are some guidelines for naming your documents. Name the SOPs in the following manner:
This means that the official name of the SOP will be:
XYZ_SWD_SOP_BankCreditCardApplication_v1_2_616
Use underscores to separate SOP naming elements.
Also, use this SOP naming convention in the header and/or footer. I’d also suggest that you place it on the cover sheet.
The next question is how to update SOPs.
Most SOPs are living documents and will go through different revisions until they are archived or purged.
In either case, you need to watch out for a few things when controlling these documents. Most procedure writers focus on the first part of the naming convention:
But may pay less attention to the following three, especially if they’re using File, Save As to create new documents:
There are a few mistakes to watch out for here.
Make sure you increment (i.e. go up one level) when the document is revised.
But, make sure you change the first or second character. The first 1 refers to the final version for that release. The second number refers to minor revisions made to the document, such as small text changes. So, be careful here in case and don’t change 1_1 to 2_0 if it should be 1_2.
In some countries 0507 means the fifth of May. In others, the fifth of June.
It depends where you are. Europeans and Americans use different conventions for dates of the year. So, double-check before you assume it’s the fifth of May….
When a SOP is archived, make sure to add an A to indicate Archive and, if possible, add a watermark highlighting that this document is not to be used.
MS Word and Adobe PDF both come with watermark tools. You can also use these for Draft documents.
The key to controlling SOPs are to create guidelines that are easy to follow, manage, and share.
This means when it comes to naming them:
Conclusion
Before you start writing your SOPs, give some thought to how they will be managed a year from now.
How will hundreds of documents, with different versions, and status controls be managed effectively. Possibly by someone else.
Create a meaningful naming convention and then explain to the procedure writers how it works. Don’t assume everyone will understand it. Share examples and make yourself available to help others, especially those who are new to procedure writing.
Any questions, drop me a line.
What’s the simplest way to control numerous SOPs documents, especially if you’re managing a team across different business units?
My first suggestion is to keep it simple.
I’ve used some very complex Document Control software. The problem is that larger systems are so feature rich that you can spend more time learning how it works than actually managing the procedures.
I prefer to use an Excel spreadsheet. This is something I can share with colleagues, has no learning curve, and is available on most all PCs. Expensive software locks out many users and also requires training, which is more time gone.
In the Excel file, create rows for all the items you want to track.
Again, keep it simple and use Low, Medium and High for each procedure.
L/M/H – in one column, enter Low, Medium or High next to each procedure. This helps you capture each SOPs as you write them and also make sure that the most important ones are done first. Some SOPs are more critical than others.
When I’m reviewing and/or controlling documents I usually assign a status to the document depending on its level of importance.
These three – L/M/H – help me prioritize those that need to be actioned first, whereas others can wait a while.
Also, I use this field to highlight to other writers which documents need to be completed first and also highlight what’s most urgent.
What have I missed? How do you prioritize your SOP documents?
The best way to implement policies and procedures is to ensure they are well-written, useful, and simplify things for the reader. Use this checklist to ensure that your SOPs get implemented correctly.
Put yourself in the reader’s shoes. All they see is another email telling them they have to do something. Or worse. Do something different. This makes people resist even BEFORE they’ve opened the email. So, step back and see how you can make the reader WANT to read your policy or procedure. How? Highlight the benefit.
Don’t just ask it, mean it. Ask the frontline staff who will use the document, does it work for them. In large organizations, these folks are often the last to see the new policy or procedure. Yet, they are expected to use it. Something doesn’t add up here. Ask them what they think, take their comments onboard and make the changes.
Then send a nice email thanking them for making the effort to get back to you.
If you can… walk over and thank them in person.
Once you get folks onside, it’s much easier to implement, change and enforce a policy. Their on your side. They want to help. But you’ve got to keep them in the loop.
Have you ever avoided doing something not because you didn’t want to do it but because you didn’t know how to? We’re all like that. Sometimes people want to help but don’t know how. You need to give them direction. There are different ways to do this.
Schedule assessments every quarter. Check that the team are following the procedures correctly. If not, don’t reprimand them instead look for ways to make the process easier to understand. Again, people want to do things write but sometimes they need direction.
For example?
We created a set of Procedure documents. These were converted into PDF and uploaded to the intranet.
So far, so good.
But the PDFs had fields and text boxes. The staff were meant to fill in the fields when performing different tasks. The problem was that they couldn’t see the Save button.
There was a shortcut key but most didn’t use it as they often got it mixed up and did more harm than good.
We changed the design on the forms in the PDF and suddenly everyone was using the procedures correctly.
The message here is that while the Policy/Procedure document may be fine, the tasks associated with using it may confuse the staff.
Keep your eyes peeled and see where staff are getting tripped up when following instructions.
Those are some ways I implement Policies and Procedures.
One last thing.
I try not to say that I ‘enforce’ policies.
Why?
The word enforce sounds like I’m policing people. That’s not my job. I don’t have a badge!
How about you?
What do you do to implement procedures and other business documents? What mistakes do others make when doing this?
Yesterday we looked at the steps involved in getting the procedures signed-off. Once the documents are signed off, we can now look at how to publish the SOPs.
This process is relatively simple… if the correct guidelines are in place. But guidelines I mean naming conventions, track changes have been applied correctly, the document is converted to PDF correctly, uploaded to the Document Management System, and outdated documents are moved to the Archive folders.
Think about it for a second. You’ve just revised an existing document that may be on the desks, hard-drives and server across the company.
How do you get the new version in front of people AND take the old version back off them. That’s it in a nutshell. And there are different ways to do it.
If you are the Document Owner, then it’s your responsibility to ensure the correct version is published – not only to the intranet but all places where you know people download and share the SOPs. To do this, you need to use a three-pronged attack:
Give advance notice that the SOPs are about to be changed. A short email with an attention grabbing headline should warn readers that the SOPs they are currently using will soon be out of date. If possible, give the date for the new, revised publication.
Email all Dept heads who use the SOP when it has been updated. Note: if the changes are minor, don’t annoy the team leads with these emails. Instead email those who use it most frequently. CC the Team Leads if you want.
Remind the Team Leads and Users a week after the document has been published that out-dated documents should be purged from their PCs. For major releases, you may need to find other ways to harvest out-dated documents.
Ensure that the correct naming conventions has been applied to the procedures. At a minimum, the documents should include details of the Document Type, Department, Date, and Status. For example, SOP-IT-070512-F.
This allows you to control documents and ensure that you can manage them more effectively. You may need to spend time teaching your Procedure Writers how to use Naming Conventions. Keep an eye on how they do this as there will always be teething pains. Don’t assume the ‘experienced’ writers know how to do this correctly. Some samples and Style Guides always help.
If you use MS Word, then you probably use Track Changes to add comments when reviewing the documents. This is usually easy to manage if there is only one document review. You simply accept the changes and update the document.
However, be careful if there are multiple changes from different authors to the same document. This can look like a spider’s web of scribbles. Look at each review one by one and make sure the correct text is updated. When three of four reviewers add their own comments, check that the final text agrees with ALL comments, not just the last one.
Most MS Word documents are then converted into Adobe PDF. This lets you share the document over the web without others changing the text.
You can apply a range of security settings to the PDFs. This include:
Once the PDF is in good shape, upload it to where you store your SOPs. In general, you should had a dedicated area on the network where all SOPs are filed.
Not only is this best practice, but it helps you control the documents and simplify the management process. If your SOPs are scattered across the network, they become very difficult to control. Outdated documents will stay in circulation under-mining the good work your team has put in and possibly jeopardizing the safety of those who use the SOPs.
Here’s one approach:
A simple filing structure lets others see where the correct documents are stored. Avoid the temptation to create complex filing structures. You’ll end up in knots trying to work out where you put things.
Move outdated documents into the Archive folder. Note that this folder may have several versions of the same document. Check that the naming conventions have been applied correctly. All documents should following the same numbering system. If not, look into it as one of your team may understand how to apply these correctly.
Is it 0705 or 0507?
It depends where you are?
In some parts of the world, it’s Month and then Day. In others, it’s Day and then Month.
Watch out for this when the Dates can be interpreted either way.
0705 could be the seventh of May or the fifth or July.
Depends where you are…
Consider purging documents when they are over X number of years old. Or remove them from the network and keep them backed up on tape, just in case someone wants to see them for compliance or audit reasons.
If you keep all your documents on your own server (or PC), then pretty soon you’ll run out of space.
Your success in managing SOPs in a combination of things. It’s about writing, of course. But, it’s also about the other activities that interact with the writing process, such as getting Management support, Reviewing the documents and Publishing them to the Internet/Intranet.
One of the paradoxes for me as a Procedures Writer is that the more I work in this field, the less I write. Most of my time is spent as a ‘Mother Hen’ watching my baby documents and make sure they do to the right place at the right time.
How do you manage procedures after they have been written? What do you do to make sure others use the right document and that the old versions get purged?
We’ve now completed seven stages in the Procedure writing process. From gathering the requirements, interviewing the Subject Matter Experts, drafting the procedures and getting them reviewed. This takes us up the stage where the documents must be signed off by the Project Stakeholders. While this seems straightforward, there are a few hazards that need to be avoided.
Now that you have finished writing the procedure, you need to get it approved and sent out to those who will use it.
How to get it approved:
Finally, to make sure those who need to use the procedure can find it, add it to your Document Management System and, if applicable, to your Intranet.
Procedures must be reviewed on a scheduled basis and also when IT systems are upgraded or changed.
Factor this into your project schedule and highlight whatever resources you may need in advance. Procedures are living documents and must be treated as such. When any step changes, the procedures must be updated to reflect these changes.
What do you look for when approving documents? How do you know you’ve got it right?
In Part 7 in our series on writing Standard Operating Procedures we look at how to test the Procedures.
The first question is who tests the procedure?
One of the risks of testing your own procedure is that you’ve become snowblind to how the process actually works and fail to see steps that need to be captured. Also, you may take things for granted which the reader needs to be aware of, such as security precautions or items that need to be in place for the procedure to work.
Finally, if possible, get someone who will perform the actual procedure to test it.
Using the Track Changes feature in MS Word is a simple and effective way to enter comments. To turn this on, click Tools, Track Changes. The recipient can accept or reject the changes and then save the final version with the correct text.
PS – If you’ve missed the other six tutorials, sign up for the newsletter and the whole set of tutorials will be sent to you automatically.