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.
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.
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.
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.
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?
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?
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.
This is the part I like the most about writing procedures. It involves walking around and getting to know those who work with the actual procedure and know how it works ‘warts and all’.
The Tale of the Information Gathering Phase
One of the mistakes many writers make is to work at their PC and assume that the knowledge they need will come to them. All they have to do is send out some emails, right?
Not really. You need to get out and make connections with people. Once they can put a ‘name to the face’, it gets easier to arrange meetings. You’re not a stranger anymore. They know who you are and why this project means so much to you.
Also, by going to their desk, you’re showing that you’re making the effort to reach out to them. It’s also harder to say No to a person when they are in front of you. Deleting emails is a lot easier.
What Information Are You Gathering?
Let’s think about this for a second. The end goal is to be able to:
To get to that point you have to do a Sherlock Holmes.
Do a Sherlock Holmes?
What I mean is you need to look at this procedure as neutrally as possible. Think of yourself looking for clues, trying to find information that will explain exactly how the process works.
Many business analysts, maybe new to this field, think they know how a process works after a quick assessment. When they get into how it works – and when eagle-eyed team members review the first draft – it becomes clear that the process needs to be re-examined.
To recap: the information gathering phase is where you go out and collect all the information you need to prepare the procedures.
Shouldn’t it be obvious what you need to capture?
Not really. If you ask ten people how to get from your house to the city centre, they’ll all give you different routes. Everyone knows different shortcuts, different schedules, and better ways to get from A to B.
It’s the same with writing procedures and work instructions.
You don’t write Procedures in a vacuum. Meet up with other people and ask them how the procedure works. Let’s say, as an example, that you’re writing procedures for a bank. You want to know how mortgages applications are processed.
This process will typically involve numerous activities, all handled by different people, many of which are performed by different functions and disparate IT systems.
To capture each step in the process means sitting down with those who understand each task.
There are two parts involved in capturing how a process works.
Capture the As Is Process – The first is to ‘photograph’ how the actual process works. This is often called the ‘as-is’ process. In other words, you’re aim is to capture exactly how the process works, warts and all. You’re not concerned with finding faults, looking for improvements, or exploring alternative options. The as-is process shows how the process works, just as a photograph would.
Define the To Be Process – The second is the ‘to-be’ process. This involves looking at alternative ways of performing the process and different contingencies you can take if/when a specific action occurred. Exploring the to-be process is often called process redesign or process reengineering.
However, to get to this point, you need to understand the ‘as-is’ process very clearly.
If you start the second step without going through the first, you’re likely to make assumptions or overlook factors that will undermine the accuracy of the process.
How to get started?
You can speed things along by arranging workshops with the necessary subject matter experts. It’s unlikely that all will be able to attend; don’t worry. Get as many into the workshop as possible and go through the processes.
Make sure you have:
Overhead projectors and
If necessary, arrange for lunch to be delivered as this will give you more time with the attendees, instead of them splitting up for lunch. I’ve seen people go for lunch and not return for the afternoon session; do your best to keep them in the room. You mightn’t get a second chance.
If possible, get another team member to make notes as you’re running the workshop. You can compile these notes the next day and then circulate them to the attendees for their review.
The third stage of the procedure writing process involves setting up a framework whereby all the different writing activities are formalized.
This means that before the team starts writing the procedures, you can explain to them how the writing process to works and what is expected of each person.
SOP Writing Guidelines
To ensure that the procedures are written to the company standard, reviewed correctly, and reports are generated on time, establish a set of guidelines that shows each writer how the process works.
What is expected of each writer?
Not everyone is expected to write all the material. Some will develop process flows, while others may specialize in editing the documents or submitting them to the Document Management System.
How should they circulate the procedures?
Most documents will be written in MS Word or another writing tool. After the first draft is completed, is must be circulated for review. Show the writers how to do this, how to number the document correctly and how to use Track Changes.
What tools to use to write, edit and create the procedures?
If you use specialist tools for documenting the procedures, for example, open source tools, give each person adequate training and some best practices on how to use the product. You can save time over the long run by sharing this information upfront rather than expecting everyone to find out by themselves.
Likewise, make sure that all team members use the same version of the product to avoid backward compatibility issues. Procedures written in MS Word 2007 may not open in MS Word 2003, for example.
How to update the documents after each review?
During the Review Phase, each of the writers examines the draft document. What the writers look for on a low level are things like typos, incorrect spellings, and formatting issues. All of these are important to ensure that the presentation is correct, but really they need to go deeper.
They need to stress test the procedure so that the steps in the correct sequence, that there are no ambiguities, and that key steps have not been omitted. None of this has to do with presentation – it’s to do with accuracy.
Is the procedure correct in ALL respects?
Can the user use this procedure follow these instructions and achieve their goal?
Has the Reviewer explained exactly what needs to be changed to correct the document?
Also, the Reviewers must update the Change Log and show that it’s status is D fro Draft or R for under Review.
Other areas that we will examine in the coming weeks include:
How to file, store, and archive procedures?
How to work with the SMEs?
How to submit status reports?
How to arrange interviews?
Where they can find templates, style guides and other support material?
Do I have to do this? Shouldn’t they know how to do this already?
Maybe yes, maybe no.
Not everyone on the team has the same level of experience that you do. Try to gauge their level of expertise (especially if you ‘inherit’ writers from other teams) and walk through how the documentation process works.
Ensure that the team understands their roles clearly. Ask them a few questions to test their knowledge and see if they are comfortable with their duties.
Once a week take a team member to lunch offsite and try to get a feel for how the project is working for them. As a team lead, you’re likely to get wrapped up with deadlines, reports and other duties. Spend time with your team and see where things are working and where they could be improved. Avoid gossiping about co-workers, that’s not the point. Instead ask them how the current process could be improved.
There’s always room for improvement, right?
Next up? How to gather information from Subject Matter Experts.
Yesterday we showed how to get support from the Management team for the Procedure Writing project. We looked at how you need to sell the importance of the quality procedures to the Executive team and how they in turn can pass this message down the line.
Now that we have that in place we can look at the Procedure Writing team. This involves gathering the best writers (or hiring freelance contractors) and then showing them how to write the procedures based on your style guides and SOP templates.
Create a Framework for the Writers
While this seems obvious, not all writer and process designers will have the same understanding that you have.
Also, as different writers will have different tasks, it makes sense to discuss what each writer is expected to do, what to share, and how to report their weekly progress.
Assume nothing. Communication everywhere.
Defining the Procedure Writing Team
The Procedure Writing Team may include some or all of the following:
Full-time Procedure writers, possible yourself, whose primary role is to gather data and write up the procedures.
Part-time writers, such as Technical Writers in other department, who will assist you when/where needed.
Subject Matter Experts who will provide the knowledge you need to write the procedures. For example, in a bank you may have specialists with in-depth knowledge of how the credit card process works. These will be the people to interview when gathering data on how the current process works and also how to improve the process.
Contractors who will be hired for specific pieces of work. This includes Technical Writers, Editors, Graphic Designers, Process Designers, Information Mappers, and others in the publishing field.
Consultants who will also be brought in for special projects, for example those with Compliance or Sarbanes Oxley knowledge.
Those are some of the roles that will be involved in the overall Procedure Writing lifecycle. In some cases, the same person may wear two ‘hats’ or more.
For example, I often wear the hat of the Project Manager, Writer and Business Analyst. Remember, the management don’t care what job title you give yourself as long as the procedures get written on time.
How do I establish the Procedure Writing Team?
As with any team, you need to allocate responsibilities to each task. This means thinking about who is best placed to:
Revise the procedures when there are changes to the business processes
Assigning Writing Tasks
Depending on the resources at your disposal, you may be able to allocate different people to these tasks or if you’re circumstances are more modest, you can allocate multiple tasks to the same person.
In some projects, I handled most all of these tasks except the sign-off. While this is not ideal, the reality for many companies is that there are not enough hands to manage the workload and you have to ‘improvise’.
Warning: don’t give writing and testing tasks to the same person. I know this sounds obvious but writers can’t (or shouldn’t!) be asked to test their own material. After writing hundreds of words explaining how the procedure works, you tend to get ‘snow blind‘ and can’t tell the woods from the trees, so to speak.
Procedure Writing Team: Key Roles
Most projects will require the following roles:
This person is responsible for:
Gathering source material, such as the existing procedures, processes, and work instructions
Interviewing those with knowledge of how the procedure works
Arranging workshops and sessions to explore the material with Subject Matter Experts
Oddly enough, getting sign-off from the project stakeholders can be the hardest task.
Because getting people to approve a document means that they are now partly responsible for its quality. In projects where the SOPs are customer-facing, such as Health and Food related guidelines, it can be very hard to get the final sign-off.
This person is responsible for reviewing the procedure, which is usually sent to them by the Procedure writer.
You (as team lead or Procedure Writer) need to outline:
What is expected of them
How they should test the procedure
How to record errors in the document
How to flag contradictions and ambiguities
How to circulate the reviews to the writing team
How to escalate critical errors, for example, if the procedure is currently is use
How to close the testing cycle
Not all projects will require a Compliance Officer, for example, procedures to do with food handling or food safety would require the approval by a Health expert instead.
However, for procedures that involve banking, IT, government, security and data protection, this person must ensure that the material complies with the company’s
This is critical in pharmaceutical companies where procedures need to align to industry guidelines and official health standards. In the IT and Financial Services, business processes may need to comply with Sarbanes Oxley guidelines.
Flowcharts that illustrate how transactions occur across different departments or different actors
These diagrams are very helpful during sessions and workshop when you want to improve an existing process. Seeing the process as opposed to reading how it works brings the process to life and lets us see how the process works.
This person is typically the Line Manager or the Department Head who sponsored this activity. While this person may not read the procedures line by line, they will typically interview the writers, testers and compliance staff at the end of the project and quiz them on how they gathered the material, wrote the text and ensured that the procedures covers the most important areas.
For example, while minor errors, such as typos, may be overlooked by the auditors, if a procedure contravenes guidelines, such as Sarbanes Oxley controls, the company may fail the audit, which undermines the company’s credibility and is likely to lead to more intensive audits from here on. This person may also be responsible for allocating budgets to the project and ensuring that adequate funding is in place for the project (and/or writers) to succeed.
These are some of the roles you need to prepare your SOPs. Remember that there may be some overlap between different roles and the same person may have to perform multiple tasks.
Yesterday we looked at what needs to be in place before you start writing your procedures. This involves getting the funding, creating a project plan, needs assessment and/or scope of work depending on how complexity of the assignment. Once you have the budget, the next stage is to get support from Management and to find someone at an executive level who will Champion the project.
Why You Need Management Support
Before you start the SOP development process, you need to ensure that you have some level of support from the Management team. Unless there is a commitment from the management layer, your team will have a hard time of it especially when they need to make demands on other co-workers’ time.
What you’re looking for is:
Budget and financial support to get the necessary human resources (e.g. technical writers) and technical resources (new licenses for MS Visio or other diagramming software)
Commitment from the board that this activity will be championed and the necessary support will be provided to drive the project.
Communications from the Management team to inform, update, cajole and direct its staff. Unless other departments highlight the importance of this activity, your team can be seen as an interruption into other’s schedule. To avoid this, work with the Management team and show there how this project benefits their Department. Also, you may need to ‘script’ some guidelines for these Departments to get the ball rolling.
While many colleagues may be willing to help, they may struggle to explain your goals to their colleagues and team members. For example, what your long-term goals are and how these relates to the company’s success.
Otherwise, you’re just writing a bunch of documents, right?
How do I get support from Management?
There are several ways to do this.
Emotional triggers – find ways to demonstrate that the SOPs work will improve the company, not from a financial perspective, but ways that will boost morale, increase employee satisfaction or provide some benefit to customers. Once you have found ways to hit the hot buttons, then getting the funding may not be so hard. The Heather Brothers book Switch gives some good examples of how to do this.
Demonstrate the benefits – after you’ve warmed them up and generated interest in the project, show them how and where the company will benefit with charts, diagrams and other materials that will appeal to the more logical part of their brains. Process flow diagrams are an excellent way to visualize how a business scenario works.
It’s all about winning hearts and minds!
Finding An Executive Champion
Many companies dedicate a high-level executive to ‘champion’ the SOP process. This ensures that the project is given the attention it deserves and that line managers give the procedure writers access to their staff when necessary.
While not every company will have an obvious champion, see if there is someone you can ‘butter up’ and help get the project started. See who would benefit most if there were accurate processes in place. Show them the cost savings, faster turnarounds, and other pain points that could be reduced.
But, I don’t know how to get started
If you are new to procedure writing, then it’s hard to know where to start. There seems to be some many tasks that need attention. Well, the first thing to do is talk to those who currently use the process. This is also called the As-Is process. In other words, this is how the process works – warts and all – right now.
One of the barriers that procedure writers face is getting ‘face-time’ with those who understand how the procedure works and those who helped define the current as-is process. Sometimes they may have left the company and then you have to dig around as best you can.
If the original people are still there, try to contact them in person. Dont email them or leave a voicemail. Walk over to where they work and introduce yourself.
“Sorry, I’m too busy.”
You’ll hear this a lot. It’s understandable. They are already under pressure from other projects and don’t need another to-do added to their list.
Remember the Champion?
See if you can get the Champion to drop over and give them five minutes. If you can show the SME that they’re not doing this for you but for someone much higher up the food chain, they may be more willing to help.
Also, the Champion will ‘bend the arm’ of those who are holding up the project or slow to review the material, ensuring that the project is delivered on time.
As you can see, if you don’t have an executive sponsor, your team are likely to suffer at the hands of unhelpful colleagues. It can be very demoralizing for the procedure team to chase SMEs who drag their heels when reviewing the documents. This is likely to lead to the project missing its targets and running over budget.
Once you have backing from an executive level is becomes much easier to drive the project forward. The endorsement of a senior figure gives your team that clout to open doors and ‘encourage’ others to attend meetings.
Mentioning that the status reports go all the way to executive level is usually enough to motivate folks to attend workshops or give time to your team.
Tomorrow we will look at how to start putting your team together. We will also outline the skillsets they need and the type of non-writing activities involved in procedure writing.
Confused? It will all make sense tomorrow. See you then
Yesterday we looked at the lifecycle of writing Standard Operating Procedures. We outlined ten different stages in the writing process. What we’ll discuss today is what needs to be done before you start the actual writing. This includes the prep work necessary before the writing team is assembled and also other issues such as getting budgets, equipment and other resources.
Before you Start Writing Your Standard Operating Procedures
The process of developing Standard Operating Procedures (SOPs) involves ten key stages. The approach we have used here is to assume that you are starting from scratch and want to develop your SOPs in a structured manner, so that you can share your style guide, templates, and naming conventions across the writing or those who will also be involved in the writing process.
What’s the first step?
The first thing to do is decide who will write the actual SOPs (Standard Operating Procedures).
I know this sounds obvious but in many companies there are no dedicated Procedure Writers and the task is often ‘shared’ with other team members. Some of these will be willing to help, others will resist or may not have the time to assist you.
Where do I find the Procedure Writers?
Tomorrow, we will look at how to get a budget for dedicated procedure writers or access to other professional writers in the organization, for example, technical writers who may be able to offer some:
Specialized writing skills
Proof-reading and peer reviews (you really shouldn’t proof your own work for obvious reasons)
Direction on how to setup the document management systems
Establishing naming conventions and
Procedure writing techniques
Getting a Budget
If you are responsible for this project, then you need to get funding. You can get this in different ways.
The first is to apply to the Finance Dept for the separate funding, for example, if this is a standalone project.
The second is to look for an extension or increase in current funding, for example, if you manage the Technical Communications Dept and need extra funding to hire new writers, contractors, designers, and also get licenses for new equipment and software.
Where to Start?
The bottom line is the cost. How much will it cost to document these procedures?
To get to that figure, you need to scope what’s involved. Here’s one approach.
Identify the number of existing procedures.
Estimate how long it will take to write each new procedure.
Estimate how long it will take to train new writing staff.
Estimate how long it will take to gather information and perform Needs Assessment.
Calculate the approximate number of days required to perform these tasks.
Based on Daily Rates, calculate how much each resource will cost the project.
Add costs for software licenses, equipment, and additional hardware.
Factor in 10% for unknown costs.
Once you have the project costs – or at least an estimate – send it to the Project Stakeholder. You can’t proceed until these are approved. Indeed, if the costs are higher than expected, you may want to be a more in-depth Needs Assessment to see what is involved and to define a Scope of Work document.
Ok, you got the funding, now what?
The next step is to set the wheels in motion. Contact the Procurement Dept and request the necessary software, hardware and equipment.
After this, look at:
Getting the necessary office space for the new team.
Make sure their PCs are setup
Software is loaded correctly
Passwords have been assigned to network drives
Swipe cards are created with the necessary access rights
Technical books and Style Guides are ordered.
Once you have these in place, you can arrange to bring in the writing team and start working on documenting the procedures.
Tomorrow we will look at organizing the Procedure Writing team and what’s involved in this activity.
We’ll start with the fundamentals and then work our way up to more complicated areas. For example, we’ll look at how to get funding for your project, how to write technical writers and how to use naming conventions so that you can find document more easily once they have been archived.
10 Step Plan to Writing Standard Operating Procedures
The process of developing Standard Operating Procedures (SOPs) involves ten steps.
The approach we will use is to assume that you are starting from scratch and want to develop your SOPs in a structured manner. This means that along with writing the SOPs, you will also have them written in a way that allows others to find them, update them and share them where necessary.
Organise the Procedure Writing Team
Get Support from Management
Define Team Procedures, Templates and Style Guides
Information Gathering Phase
Examine As-Is Processes
Explore To Be Processes
Write the Standard Operating Procedures
Test the Standard Operating Procedures
Sign-Off the Standard Operating Procedures
Release the SOPs
Maintain the SOPs
How about Style Guides and Templates?
We will also look at how to setup style guide, templates, and adopt naming conventions for all procedures.
What else will the course include?
Some of the other topics will include:
Role and Function of SOPs
How to conduct a Needs Assessment
How to implement SOPs
How to Evaluate SOPs
How to create SOP templates
How to format SOPs, Process, and Flowcharts
How to define a SOP
At the end of the course, we’ll share some free sample SOPs and other resources that will help you write your procedures.
That’s it for now.
From tomorrow, we will begin to walk you through the entire process and look at each step involved in creating your procedures.
One of the easiest way to write standard operating procedures is to see how others do it. What I’ve done this week is share 7 examples of different standard operating procedures examples (also called SOPs) so you can see how different organizations write, format, and design their own procedures. Over the coming weeks, we will analyze these documents and prepare a series of templates that will help you write SOPs for different industries and different sectors.
Here is the list:
1. FAO – Two examples of various categories of SOPs are given in the ensuing chapters.
MS Word. Click top red arrow to expand/show the Style Menu.
And it’s not just business writers, in the world of technical publishing, Microsoft Word also gets a bad rap. Many feel that it’s unstable and crashing. It can also bloat in size until your operating system grinds to a halt.
the Problem with Bullet Lists & Large MS Word files
The first offender is Bullet Lists. If there is one thing that’s guaranteed to crash Microsoft Word, it’s bullet lists.
Here’s what tends to happen.
When you click a Bullet List from the Word toolbar, Word points this Bullet List to the Normal.dot file. In other words, it uses the default settings in Normal.dot and then applies these. Fine.
No problem! That’s what it’s supposed to do.
If you cut and paste a Bulleted List from one business report into your working file, then Microsoft Word has a problem.
Which Bullet List is the Master Bullet List?
It can’t tell because suddenly you have two bullet lists in your document.
If you add a third bullet style, maybe with nice styling or cool fonts, it has a nervous breakdown. Microsoft Word can’t tell which is which and begins to struggle.
How to stop Word Crashing & Losing your Business Proposal
Here’s what to do:
Open Word and create a separate Style for each type of bullet lists you need. For example create a Bullet Regular, Bullet List Indent, Bullet Square and so on.
When you need to use a bullet list, select the appropriate style from the Styles drop-down menu.
This is the Home tab in Microsoft Word 2007.
If you want to import a bullet list from another document, Copy the text into a blank document.
Select it, and in the Style menu, select Clear All. NB: This removes all formatting.
Paste it into the working document.
Apply the correct style.
I know this seems like more work but it’s not. Just paste into a blank document, remove the formatting and then paste it in. Your files will stop crashing and will be easier to manage.
As some friends on LinkedIn are also moving into business analysis and SOP writing, I thought I’d add a few tips here. While there is some overlap with technical writing, it does require a different mindset, for example, to understand the process flows and narratives that hold the procedure together.
This purpose of this article is to reminds us that our sales, marketing, business, and proposal development do not stand alone. It is all part of a larger process that involves planning, research, writing, editing, proofing, submission and acceptance.
This list gives 37 ways to improve your next set of procedures.
Scroll through it and tell me what I missed.
Show that your procedure is logical and organized
Make the information easy to find.
Include a table of contents for procedures over 10 pages in length
Ensure that your procedure is in compliance with the Security guidelines.
Arrange material in order of priority to the reader
Arrange everything in the order that’s most important to the client
Arrange the procedure in accordance with the user’s requirements
Number pages and sections consecutively; do not re-number each section
Avoid hype, padding and other self-congratulatory drivel. Remember that the proposal is a legal document that becomes part of the contract if you win
By giving specific details and quantifying the benefits whenever possible
Don’t just say that you will comply with a requirement — say how we’ll do so
Use a strong closing statement
Avoid business cliché’s
Avoid hackneyed openings and closings that clients have read a thousand times. Avoid “I would like to take this opportunity to thank you for considering the enclosed . . .” Get to the point: “Here is your proposal.” Avoid “If you have any questions, please feel free to call.” That closing has been done to death, so avoid it and write something more genuine.
Make your procedure easy to understand
Use the same terms and jargon that appear in all SOPs. Don’t try to impress the client with your own special brand of buzzwords or TLA (three-letter acronyms)