Posted on

Procedure Writing: How to Write the Narrative Section

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.

Posted on

SOP Procedures: 5 Ways to Improve the Title

Recently, we looked at how much detail is required when writing procedures. Let’s look at the title section of your procedure.
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.

Procedure Titles: 5 Ways to Improve

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
Posted on

5 Procedure Writing Guidelines (with sample template)

Want to improve your procedure writing? Today we look at five simple ways to sharpen your SOPs. Let’s look at five terms frequently used in procedure manuals, instructional guides, and process design.

5 Procedure Writing Guidelines

In procedures, the following five words are often used incorrectly. To avoid these mistakes, do as follows”

  • Button Names – avoid using the, button name, or icon name. Write “Click Print.” Instead of “Click the Print button.”
  • Turn on/off – use ‘turn on’ or ‘turn off’ when activating or deactivating a command. Use Click to turn something on or off, for example: To turn on Web view, click Web.
  • Click OK – don’t write “Click OK” at the end of a procedure if it’s obvious that you must click OK to complete it.
  • When to use From – if your procedures refer to a keyboard, use ‘from’ to highlight the menu from where you can choose a command. For example, say “From the File menu, choose Print.”
  • When to use On – use ‘on’ to highlight where the command or option starts: “On the File menu, click Print.”

What other terms or phrases are often written incorrectly in procedures? Let me know and we’ll discuss it in a future blog post.

Learn more about this Standard Operating Procedure (SOP) template

Download this template – MS Word

Download this template – Apple iWork Pages

Posted on

FAQ SOP Writing: How to Improve the Document Title

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:

  1. 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.
  2. 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.
  3. 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.
  4. 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:

  1. 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.
  2. 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.

What else would you add?

Posted on

How to Write the ‘Benefits’ Section in Procedures

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.

  1. 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.
  2. 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.
  3. 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?
  4. 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.

Posted on

SOP Writing: How To Number Procedures Correctly


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.

Standard Operating Procedures (SOP) Template

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.

For example:

Use: “Turn on one 3.25 kV bus.”

Do not use: “Turn on 1 3.25 kV bus.”

In the second example, it’s hard to tell if it’s one 3.25 or 13.25. The first example is much easier to read. It’s the 3.25 kV bus you need to turn on, right?

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.

4. Consistency

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.

Posted on

Procedure Writing: Naming Convention Guidelines and Examples

Why are naming conventions so important in procedure writing?

If you’re responsible for writing SOPs, then you need to develop naming conventions that help you control how procedures are written, reviewed, published, and archived.

Don’t worry – it’s not as difficult as it sounds.

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.

For example:

  • 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:

  • MyBank-SOP-0512-D
  • MyBank-SOP-0512-P
  • MyBank-SOP-0512-A

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:


Let’s look at each one.


This means

ABC – name of the client
US – for the US offices
0512 – published on May 5th
D – Draft status
1 – Revision one

XYZ – name of the client
UK – for the UK offices
0712 – for December 7th (not July the 12th)
P – Published
2 – version two, i.e. It had been revised twice

You get the idea.

By creating a naming convention like this, we can apply these guidelines to all document types. But there are a few pitfalls to avoid. More on this later.

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
  • Project Name
  • SOP

But may pay less attention to the following three, especially if they’re using File, Save As to create new documents:

  • Abbreviated Title
  • Version Number, e.g. V1_0, v1_1, v2_0
  • Document Number

There are a few mistakes to watch out for here.

Version Number

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.

Any questions, drop me a line.

Use this Excel spreadsheet to manage your SOP version history, document contributors, and clarifications
Posted on Leave a comment

How to Prioritize SOPs When Controlling Documents

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?

Posted on Leave a comment

Stage 9 – Publishing the Standard Operating Procedures


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.

Communicate Frequently

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?

Posted on Leave a comment

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


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

Gathering Data For Procedures

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

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

Does the Process Work?

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

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

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

Looking at Alternatives To The Current Process

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

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

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

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

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

Here’s an example from the real world.

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

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

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

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

Posted on Leave a comment

Stage 4 – Sherlock Holmes & The Tale of the Information Gathering Phase


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

Walking around?

That’s right.

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.

  1. 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.
  2. 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:

  • Flip-boards
  • Overhead projectors and
  • Writing materials

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.

Tip: Try to capture things while they are still fresh in your memory. If you leave it until tomorrow, you’re likely to forget large chunks of what you’ve heard. Give yourself an extra hour after the session to write up your notes.

What other suggestions do you have for this phase? What’s the best way to get information from those who are reluctant to share information? Why do you think they hold the information back?

Posted on Leave a comment

Stage 3 – Establishing SOP Writing Procedures


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.

For example:

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.

For example?
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.

Posted on Leave a comment

Stage 2 – Organizing the Procedure Writing Team


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:

  • Gather information
  • Interview specialists
  • Write the procedures
  • Design the process flow maps (if necessary)
  • Review the procedures
  • Update the revised documents
  • Test that the procedure is correct
  • Sign-off the final document and
  • 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:

Procedure Writer

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
  • Writing the procedures in line with the company’s standards and templates
  • Circulating the procedure for review and
  • Ensuring that it gets signed-off.

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.

Procedure Tester

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

Compliance Officer

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

  • Security
  • Compliance and
  • Audit requirements

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.

Process Mapper

This person takes the MS Word documents (i.e. the narratives) and creates a visual representation of how the process works. This is usually done is MS Visio or another diagramming package.

The Process Mapper will create:

  • Use Cases which show different business scenarios
  • 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.

Project Stakeholder

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.

Next Steps

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.

Posted on Leave a comment

Stage 1 – Get Management Buy-In Before Writing Your Procedures


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.

Next Steps

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

Posted on Leave a comment

Stage 0 – Before You Start Writing Standard Operating Procedures


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.

Posted on Leave a comment

10 Step Plan For Writing Standard Operating Procedures

This week we start a series of articles on how to write Standard Operating Procedures (also called SOPs). The aim is to introduce the key concepts involved in:

  • Designing
  • Writing
  • Formatting
  • Testing and
  • Maintaining Standard Operating Procedures (SOPs)

These tutorials will look at how you can put together a team of writers who can write procedures to an acceptable level so that your company is better organised, both internally and customer-facing.

Learn more about this Standard Operating Procedure (SOP) template

Download this template – MS Word

Download this template – Apple iWork Pages

Is it for experts of beginners?

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.

Posted on Leave a comment

6 Examples of Standard Operating Procedures (with Office template)

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.

2. Biotechnology Program, Montgomery College – SOP

Sample Standard Operating Procedures. SOP. Formats. Doc. PDF (Requires Acrobat Reader ).

3. Safety Training Resources

4. Emergency Management Program Standard Operating Procedure (SOP)

5. Employee Training and Development

6. Developing Effective Standard Operating Procedures

Let me know if you can recommend other quality SOPs that we can share with our readers.

Learn more about this Standard Operating Procedure (SOP) template

Download this template – MS Word

Download this template – Apple iWork Pages

Posted on Leave a comment

How to Stop SOP Templates From Crashing


Is there anything worse than writing Standard Operating Procedures all afternoon and then… Word crashes! If your Microsoft Word files suddenly become huge and start crashing, here’s one way to fix it. I’ve creating some very large SOPs in Microsoft Word and learnt a few ways to control these documents.


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 file. In other words, it uses the default settings in 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:

  1. 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.
  2. 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.
  3. If you want to import a bullet list from another document,
    Copy the text into a blank document.
  4. Select it, and in the Style menu, select Clear All.
    NB: This removes all formatting.
  5. Paste it into the working document.
  6. 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.

You can get a set of User Guide templates with pre-formatted style here.

In the next article, we’ll look at other ways to reduce large Microsoft Word files.

Let me know if you’ve any problem with this. Our Smart Business Tips page on Facebook is here.

About the Author: Ivan Walsh shares Business Planning Tips at Klariti. He also runs a Video Marketing Blog for videographers and video makers.

Posted on Leave a comment

29 Ways to Write SOP Procedures Faster


Doing business in China has meant more business analysis, process design, proposal development, case studies and writing standard operating procedures.

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.

  1. Show that your procedure is logical and organized
  2. Make the information easy to find.
  3. Include a table of contents for procedures over 10 pages in length
  4. Ensure that your procedure is in compliance with the Security guidelines.
  5. Arrange material in order of priority to the reader
  6. Arrange everything in the order that’s most important to the client
  7. Arrange the procedure in accordance with the user’s requirements
  8. Number pages and sections consecutively; do not re-number each section
  9. Use headings that make sense to your readers. See Audience Analysis template.
  10. Each section title should stress the main benefits
  11. Each section title should help readers orient themselves
  12. If possible, express the key point of the section in the headline, or immediately after it.
  13. Highlight important points
  14. You can emphasize the most positive points by using bold, underlining, different fonts, spacing, titles, bullets and summaries
  15. Write all action steps. Don’t skip anything.
  16. Avoid banal headings and titles
  17. Rather than say “Development Section,” say “Ten Ways to Improve Your Processes”
  18. Use action verbs in heads, especially verbs that stress a benefit for the client
  19. Avoid boilerplate text.
  20. 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
  21. By giving specific details and quantifying the benefits whenever possible
  22. Don’t just say that you will comply with a requirement — say how we’ll do so
  23. Use a strong closing statement
  24. Avoid business cliché’s
  25. 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.
  26. Make your procedure easy to understand
  27. 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)
  28. Use simple, direct language
  29. Close your business documents on a high note. Don’t be too humble. A little confidence never hurt!

What did I miss?

About the Author: Ivan Walsh is a Beijing-based business writer. He shares business writing tips for smart people at Klariti