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.
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.
Write directly. Speak to the person reading the procedure. You don’t need to the ‘the user’ all the time. The reader is the user.
Reduce verbose 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.
Here are five practical ways you can improve your procedure documents.
#1 Use bullets or text blocks
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.
#2 Use informative headings
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.
#3 Avoid redundant lead sentences
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.
#4 Merge steps
For example, if you have three steps as follows:
Click the Print button.
Click the Yes button.
Click the Ok button.
You could merge this into one line.
Click the Print button, Yes button, then the Ok button.
Click Print, Yes, then Ok.
Most users will get this.
#5 Condense Information
Shorten the text but make sure nothing is lost.
Cross-reference. If writing online procedures, for example for a Help system, consider linking to support information instead of embedding it in the procedure. This streamlines the text. Users who need more information, can find it on the related pages.
Introductory text. Orient the reader but avoid starting the obvious and repeating yourself. Instead, provide business rich information, for example, the benefit of performing this procedure and where it is performed. Keep this short. Focus on benefits to the reader.
Remove clutter. Avoid using marketing terms and clichés, such as easy-to-use, intuitive, and robust. Focus on specifics. What will the user learn to do if they perform this procedure? Remove jargon and industry terms. Mostly these can be deleted without impacting the integrity of the procedure.
Use short words. It’s fine to say get instead of procure, to say fix instead of resolve, and end instead of terminate. Quite often we default to words with Greek or Latin origins to give the text more gravity. The reader doesn’t care. They simply want to know how to perform the task and move on.
Use white space. This may not reduce the word count, but try to lay out the text so it flows, helps the reader identify the key points, and can scan quicker.
Write to be scanned. With more information going online, and with more information read on mobile devices, write to be scanned. Your readers may not be printing out pages anymore but logging into a Help site and using keywords to find a specific issue. Once they find it, they scan the page looking for the answer. With this in mind, use headings, keywords, bullet lists, and short words.
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?
Procedure writers need to put themselves in the reader’s shoes, for example:
Location – identify where in the application the procedure is performed, for example, [this task] is performed on this [tab] on [this] window.
Prerequisites – highlight if it’s necessary to perform any tasks, for example, selecting a checkbox on another window in order to make another window appear. Another consideration is if this window needs to be specified in a configuration file or selected from a menu bar if it’s not displayed out of the box.
Location in user interface – identify where in the application the task is performed. Provide directions to the exact location where the procedure is performed, for example, if the window contains several panes, then highlight either with a graphic or state the name of the pane. Likewise, if the window has tabs, highlight which tab to use. Use the same convention to define the location path in other procedures.
Position in Procedure – decide to add these directions, for example, directly after the first lead paragraph, so the reader can identify the location immediately. Remove any frustration for the user by orienting them in the application. This helps them perform the procedure without having to go to other pages to determine the location.
Links – if linking to the page, for example, in online help, use the same phrasing in your links. Instead of saying Click Here, provide more useful information, for example, to create a report, see the Report window, and then link Report window to the appropriate page.
As this is the first piece of content the reader encounters, so it’s important to give it some thought. You want to make sure it’s accurate but also effective. For example, how long should it be? How do you phrase the procedures? Let’s take a look.
Highlight the main task – for example, if you’re describing the different ways you can print something, start with Print as this is the main activity.
Identify related tasks – for example, list the different ways you can print a document. Then, once these are identified, you can group them. This helps the reader see the different options available to them. If publishing the procedures online, remember to cross link from one procedure to another.
Start with a gerund – for example, write Printing the Report in Landscape. A gerund is a verb that ends with ING. So, printing, deleting, copying, updating etc .Don’t start with nouns, such as Portrait or Landscape as readers don’t think like this. They tend to scan for the action to perform and then which option they need.
Short but not too short – personally, I try to keep procedure headlines between 5-7 words. In some cases, you need to add more words, but I find I can usually distill the procedure into less than ten words most time. Saying that, don’t shorten the title if more words are necessary. Use your judgment. If necessary, add more words but – in principle – try to keep them short.
Scannable – when we’re in a hurry, we scan for information. We look for keywords and phrases that match what we’re thinking of. For that reason, write your title so that readers can scan the title and decide it this is relevant or not. If not, they’ll continue to scan. If that fails, they’ll turn to the Index. Remember him?
They are exceptions of course and cultural preferences need to be factored in.
Note that you can add options such as Portrait and Landscape into your Index. This is where many readers will go when they get lost or don’t know where to start.
So, keep a list of items for your Index and link these – if publishing online – to each related topic page.
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.
Use Two Column Tables – instead of embedded a screenshot after each step, consider using a two column table. In the left column, put the text; in the right, the screenshot. This helps the reader check the procedure as they scan it. It also allows them to ignore the screenshot if they wish. This also works for process design.
Label the images – add the name of the window under the screenshot. This helps the reader confirm that they’re in the right place. Should I be on the Print Options window? Looks at image. Yes, I’m in the right place. And then they continue reading.
Highlight actions – another way to improve your procedures is to highlight, for example, using a red rectangle, the affected area on the user interface. This is helpful if there are many options on the screen and it may not be obvious where a button needs to be clicked or a field populated.
Crop the image – if the image if very large, instead of showing the entire window, crop it using a tool such as Snagit. This helps the user see exactly where the action occurs. It also gives them confidence in the procedure as they can match what’s in the text with what’s displayed on the image.
Screenshot format – make sure all members of your team use the same style guidelines and formatting techniques. For example, use 1 pixel red rectangles, not blue circles. Avoid special effect unless you wanted, for example, jagged edges.
Online procedures – instead of displaying the image in the middle of the procedure, where it may distract the reader, consider using a popup link. The way this works is that when the user clicks the link, the image pops up. When you click on it again, the image disappears. This is ideal for procedures that have several images, which if displayed by default, would clutter up the page.
When to avoid:
If the procedure is straightforward, and you’re relatively sure the reader will know where to perform the task, then it’s fine not to add an image.
If the procedure is one of a series, and screenshots are displayed in other related procedures, then it may not be necessary.
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).
Summary sentence – open the procedure with a short summary sentence that explains what performing the procedure will achieve. This helps orient the reader, so they know at a glance if they’re on the right page. For this reason, keep it short, concise, and avoid waffle.
Main task – Identify the main task in the procedure heading. This defines the starting point for the procedure and should usually be written using a gerund, a verb that ends in ING, for example, printing, deleting, changing and so on.
Sequence – Write the procedures in the sequence in which they should be performed. Number each step.
Sub Steps – If the procedure offers that user a series of options, then, instead of continuing with the numbering, create sub steps, for example, 7.1, 7.2, and 7.3. This helps the reader see these steps occur under the 7 step. Indenting the sub-steps highlights this.
Secondary tasks – Identify secondary tasks, for example, tasks they need to be performed either in parallel with the main task, or if the procedure is rather complex, a second series of steps. This clarifies to the reader that the procedure is really two parts, and prepares them for what’s coming up.
Prerequisites – what should they do before they start? Is there another procedure that should be performed first? Is there a setting that should be turned on? Don’t assume the reader knows everything about the product they’re using. Instead, help them by highlighting the type of issues they are likely to encounter so they can perform the procedure without having to stop and start.
Warnings – similar to above except these highlights potential risks (e.g. you may lose data if you do X), security, or physical risks, for example, if the user is using dangerous equipment, is there some risk they should be aware of? Highlight these and use icons – small warning images – to make them stand out from the text.
Related Information – procedures are not islands that stand alone. Instead, they are usually part of something larger, usually a set of procedures. For that reason, at the end of your procedure, create a For More Information section and list all related procedures. Use the same phrasing and be as specific as possible.
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:
Identify purpose – distill the purpose of the task into a single sentence, remove clutter, and prioritize what the objective of this procedure. This helps you as a writer to write more useful instructions, and also clarifies for the reader what they can expect. So, if the title of the procedure is used to create expectations, then develop the text to explain how to achieve this.
Orient readers – this helps them understand where they are and confirms if they are in the correct part of the document set. If not, include links to other relevant procedure in the For More Information section at the end of the page.
Starting Point – as the reader may be new to the company, using your product etc, they may not know which procedures are possible to perform. For this reason, identify all possible procedures on a master page and explain as concisely as possible the benefit and outcome of each one.
Remove ambiguity – write from the user’s perspective. Avoid in-house terms. Remove acronyms. Also, use terms the user will understand. It’s fine to define terms or cross-reference to a glossary.
Two other ways to improve your procedures:
Link to Other Relevant Procedures – avoid making the reader search for information, such as definitions or associated procedures. Your aim is to keep them on the page and help them perform their task at one sitting.
Business Rich Screenshots – only include these if they add value. For example, if it’s not obvious where in the user interface a specific icon is displayed, then take a screenshot, crop it and highlight exactly where the icon is located. Don’t include screenshots unless they provide business information and clarify how this step in the procedure should be performed. A second example is a field that may be ‘hidden’ unless, for example, a checkbox is selected. Highlighting this helps the user use the product and also makes them feel you’re fighting their corner.
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.
Writing Procedures: Okay v OK
Use okay to mean all right. You can avoid any potential confusion by using all right instead and omitting Okay, which may sound too informal, especially in business documents.
Use OK in relation to the user interface, for example, the OK button.
Note: do not use the and button when documenting the OK button in procedures.
Correct – In the Print window, click OK.
Incorrect – In the Print window, click the OK button. It’s fine to just say OK.
Note: you don’t need to include “Click OK” at the end of a procedure if it’s obvious to the reader that they must click OK to complete it.
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.
Long v Short words – if you have a choice, use short monosyllable words rather than more complex, impressive sounding words. For example, use ‘get’ instead of ‘procure’. The meaning is that same.
Redundant phrases – if you change phrases such as ‘in the event of’ and use ‘if’, the meaning remains the same. Other fillers include ‘at this point in time’, which can usually be deleted and have no impact on the integrity of the procedure.
Fillers – phrases such as just now, simply click, and due to the fact that, can be changed to now, click, and because without changing the meaning of the text. Look for fillers like these in your text and also legacy materials that need to be updated.
You v User – this may depend on your in-house style guide, but it’s worth considering how you address the reader. If you use ‘you’ when talking to the reader, it creates a more immediate impact. However, if you overdo it, it can sound too informal and chatty. Likewise, if you refer to ‘the user’ all the time, it can sound harsh and cold. After all, the reader is the user. Referring to the reader in the third person tends to distance them from you, the writer. So, before you start, consider the tone and phrasing you want to adopt. Then be consistent across all documents.
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.
Business – describe how performing this procedure will benefit your business, for example, from an operational point of view, interacting with customers, or improving your quality of service.
Drivers – if possible, connect this procedure to a business driver or customer request. For example, if customers complained that they wanted invoices delivered as PDFs, then highlight this in the benefit section as this illustrates your responsiveness to customer concerns and also helps the reader understand the purpose of adopting the procedure. It also helps other procedure writer maintain the SOP as it gives them some context.
Productivity – give an example of how this procedure makes their life easier, for example, allowing them to complete a task faster, reducing the number of steps, or gives them more options. These type of benefits warm up the reader and encourage them to read the procedure more carefully. Why? Because they will anticipate that the procedure will remove current obstacles and impediments, making their working day more pleasant. And who doesn’t want that?
Time Savers – everyone is looking for ways to shave a few minutes off their day. Identify the number one benefit this procedure will offer in terms of time saving. In general, procedures help you simplify tasks and clarify how tasks should be performed.
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).
Too little and the user can’t perform their tasks correctly.
Too much and the documents seem so dense that nobody wants to use them.
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.
Why Less is More in procedure writing
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.
Because I distill the instructions, merge action steps and remove redundancies. The end result is a short, more useful SOP Manual.
SOP Writing Guidelines
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:
TaskComplexity – The level of detail increases as task complexity increases. In other words, as the task gets more complex, you need to provide additional information to explain how this part works.
Frequency – The level of detail decreases as task frequency increases, i.e. as the user becomes more experienced they don’t need to be reminded of the basics all the time.
Proficiency – The level of detail decreases as the user’s level of proficiency increases.
Next, examine if the amount and type of information provided are adequate for
intended users. For example:
Sequence – Can the procedure be performed in the sequence it is written? If not, write more action steps.
Equipment – Can the user find the equipment referred to in the procedure? Monitor a user when testing the SOP and see if they can perform this unaided.
Understanding – Can the user explain how to perform the instructions? Interview the user and ask them to explain how the process works without referring to the document all the time.
Independent – Can the user perform the procedure without getting help from other individuals or looking at other documents? If they have to ask for assistance, then identify where they’re getting confused and expand this section. Sometimes a process flow diagram is very helpful.
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.
Adding Numerical Information to SOPs
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.
1. Using spelled-out numbers
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.
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?
2. Use of spelled-out numbers with emphasis.
Along the same lines, use spelled-out numbers when a number, typically a single digit number, is
“Use one of the following:”
“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…’ ”
3. Use Arabic numbers to present numerical information
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.
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.
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.
Naming Conventions 101
The first question is: what are naming conventions?
In simple terms, this is how you name your documents in a structured manner.
Draft documents will end with a D.
When they get published, their status changes to P.
When they get archived, they’re changed to A.
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?
Sample SOP Naming Conventions
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 – 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.
SOP Naming Conventions: Guidelines
Here are some guidelines for naming your documents. Name the SOPs in the following manner:
SOP document owner/client, e.g. XYZ
Project Name, e.g. Fin for Finance or SWD for Software Development
SOP to highlight that it’s a SOP document
Abbreviated Title, e.g. BankCreditCardApplication
Version Number, e.g. v1_0, v1_1, v2_0
Document Number, e.g. 616
This means that the official name of the SOP will be:
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.
SOP Naming Conventions: Updating
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:
SOP document owner / client
But may pay less attention to the following three, especially if they’re using File, Save As to create new documents:
Version Number, e.g. V1_0, v1_1, v2_0
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.
SOP Naming Conventions: Best Practices
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:
Brevity rules – Keep the name of the SOP are short as possible. Use plain english language that describes the content in the file name; avoid vague terms such as file_011.
Use keywords – This helps with searches. Think ahead and remember your documents may get stored on a web server. Naming the documents after clients or projects makes them that bit easier to find.
Avoid Spaces – Don’t use blank spaces, dashes, punctuation or special characters in file names. While it may look easier to read, it creates other problems, for example, readers ‘seeing’ two file names instead of one.
Case Sensitive – Remember that some servers are case sensitive. I’d suggest planning ahead and using all lowercase rather than risking potential issues if you use mixed case.
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.
What’s the simplest way to control numerous SOPs documents, especially if you’re managing a team across different business units?
How to Prioritize SOPs? Keep It Simple
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.
Create an Excel Spreadsheet
In the Excel file, create rows for all the items you want to track.
SOP # – assign a unique number assigned to each procedure. It never changes. Its status or version may change but, like a car registration number, it never changes even when it goes from one owner (writer) to the next.
Date Issued – enter the date when the document was officially released.
Assigned To – for example, the writer been assigned to write the document, or the reviewer whose job it is to review it.
Role – Writers, Reviewers, Tester, Or Project Manager.
Low, Medium or High?
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.
Give it Status
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.
Sell the Sizzle
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.
Ask for Feedback
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.
Hold workshops for their team leads and show them how the new procedure works
Arrange 1-1 sessions with the frontline staff so they all feel comfortable with the documents.
Highlight any special responsibilities that they need to be aware of. Be kind. Don’t strike fear into their soul. Help them to do their job that little bit better.
Email people after a week or two and see if they’ve seen anything that you need to change in the procedures. Again, it’s not that they are lazy but most staff don’t feel it’s their place to approach you. So, you need to make the first move.
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.
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.
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.
How to Control Documents
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.
Use Naming Conventions
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.
Check Track Changes
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.
Convert to PDF
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:
Password protect the SOP.
Adding a navigation menu.
Create hyperlinks to other documents.
Ensure that readers cannot copy and paste text from the PDF.
Stop readers from printing it out. To do this, get the full Acrobat suite (the Reader isn’t enough) or look at other PDF tools that let you control the document settings.
Apply metadata to the PDF, such as the Author’s name, keywords and other file properties.
Optimize the PDF for Print, Web or Screen reading. This may impact the quality of images used in the PDF and the file needs to be compressed for faster downloading.
Uploaded to Document Management System
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:
Create a folder for each department.
In each folder, create two sub-folders. Final and Archive.
Upload the final documents to the Final folder.
Move the out-dated files to the Archive folder.
Create a Trash folder and more all fragments and incorrectly labelled documents here.
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.
Create an Archive
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…
Backup Very ‘Olde’ Documents to Tape
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.
Keep the most essential documents on your PC, just in case.
File the Final documents on the Document Management System.
File the Archive documents on the Document Management System or move to a Backup server.
Remove Old documents to tape.
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.
Getting the Procedure Approved
Now that you have finished writing the procedure, you need to get it approved and sent out to those who will use it.
The procedure should have been reviewed by the SME and others assigned to reviewing the SOP.
Changes have been incorporated.
The Version History has been updated to reflect the changes to each draft.
How to get it approved:
Send the final document to the person assigned to approve the document (usually your manager) with the correct naming structure, for example, ACME-Pharma-D-SOP-05052009. The ‘D’ means the document is still in Draft and is not a Final document.
The approver examines the documents. Their role is not to check the integrity or accuracy of the material (the SMEs should have done this) but rather to ensure that it has been through the correct review process.
The Approver enters the name, date, and any comments to finalize the document. Most SOP templates have a section for the Document History at the start.
The Approver saves the document and change the D to F, so that this is now a Final document.
Tip: Most companies save their official procedures as PDFs. We use CutePDF (www.cutepdf.com) to convert our Word documents into PDF. It’s free and very easy to use. Install it and then click File, Print and choose CutePDF Writer to generate the PDF file.
The Approver returns the document to the Document Owner (possibly you or your team lead) who changes the status from D to F. The document is now Final.
Circulate the procedure to the main contributors, so they have a copy for their reference. I’d suggest you include a nice ‘thank you’ to those who’ve helped with this piece of work. It doesn’t take much time and shows you’ve appreciated their time and effort. And, of course, builds up some goodwill that you may need when you start the next round of procedures.
Encourage feedback and acknowledge users to contact you if they find something that needs to be addressed.
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?
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.
Print out the procedure. Try to avoid reading the procedure from the screen. Many users will have it in their hands when reading the instructions so put yourself in their shoes and see if it makes sense.
Start at the top and sequentially through the steps. Don’t lose patience and skip down to the next section.
Check who does what. Let’s say the procedure has a column (usually far right) for the person or IT system performing the action.For example, in Step 1, the user may enter a credit card number into the ATM. In Step 2, the ATM checks the card. Make sure that this column is correct for each step, especially if there are handovers between people and/or between IT systems.
Check off each step as you test the process. Make notes where there are conflicts or ambiguities that need to be clarified.
Check that the steps in the procedure agree with what should happen. Also, if the IT system generates a message, such as, ‘Enter your PIN number’, then check that this is captured correctly in the procedure.
Note any errors in the margin and add it to the procedure once you’ve finished.
Check every exceptions, warning or and multiple choice presented to the user. When users are offered choices, make sure you capture each choice is a separate section.
Check that the cells in the If Then tables present such material correctly. It should work like this; if the user does this, then he these step 1. Or, if the user does this, then follow these other steps.
Another way to test your procedure is to start at the end and work your way backwards. While this may not be practical for all procedures, try it where possible. It forces you to pay attention and uncovers errors that you may have overlooked when following the ‘logical sequence’ of events.
Getting Others To Test the Procedure
Finally, if possible, get someone who will perform the actual procedure to test it.
Sit down with them and observe how they perform the task. Things you took for granted or assumed the user would know, may stop the user in their tracks.
This could be something minor, such as a small font size (which the web designers think is trendy) but which makes the text almost unreadable.
Once the procedure has been tested, return it to the writer for them to accept the changes you have made. If there are a high level of errors or exceptions that warrant attention, schedule a meeting with your colleague and walk them through the points you’ve raised.
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.