Standard Operating Procedure Tips

SOP Writing – How Much Detail Is Required?

admin — Sat, 22 Oct 2011 08:14:21 +0000

How much information do you need to include in your SOP? One of the dilemmas for procedure writing is working out what level of detail is required when creating SOPs (standard operating procedures).

Too little and the user can’t perform their tasks correctly.
Too much and the documents seem so dense that nobody wants to use them.

How do you get the right balance?

The golden rule is to give readers… the appropriate level of detail.

This means you need to outline the procedure in sufficient detail for the user to perform their tasks but not overwhelm them with superfluous information or text that distracts them from their objective.

Why Less is More in procedure writing

When I’m working with clients – for example refining an existing set of procedures – I ‘warn’ them that the final document will be shorter, not longer, than what they have today.

Why?

Because I distill the instructions, merge action steps and remove redundancies. The end result is a short, more useful SOP Manual.

SOP Writing Guidelines

What’s our aim?

To write procedures to a level of detail that aligns with the user’s qualifications and training.

How do you find this?

Use task analysis techniques to assess the level of information required.

You may also find that you need to write for several, not one, audiences. If this is the case, consider creating entry level and advanced procedure manuals.

Note: When in doubt, write to the lowest common denominator.

To provide the correct level of detail, examine the following:

Task Complexity – The level of detail increases as task complexity increases. In other words, as the task gets more complex, you need to provide additional information to explain how this part works.
Frequency – The level of detail decreases as task frequency increases, i.e. as the user becomes more experienced they don’t need to be reminded of the basics all the time.
Proficiency – The level of detail decreases as the user’s level of proficiency increases.

Next, examine if the amount and type of information provided are adequate for
intended users. For example:

Sequence – Can the procedure be performed in the sequence it is written? If not, write more action steps.
Equipment – Can the user find the equipment referred to in the procedure? Monitor a user when testing the SOP and see if they can perform this unaided.
Understanding – Can the user explain how to perform the instructions? Interview the user and ask them to explain how the process works without referring to the document all the time.
Independent – Can the user perform the procedure without getting help from other individuals or looking at other documents? If they have to ask for assistance, then identify where they’re getting confused and expand this section. Sometimes a process flow diagram is very helpful.

Conclusion

Your goal is to ensure that users have enough information to complete the procedure… without asking for help or looking at another document.

If they have to do that, then you’ve under-written the document or possibly assumed that the reader would be able to perform these steps.

One of the challenges for procedure writers is to determine the user’s skill-sets, experience and knowledge of the system. If it’s hard to determine this, then err on the side of caution and prove steps for all level of users.

How to Use Numbers in Procedures Correctly

admin — Thu, 20 Oct 2011 08:07:04 +0000

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.

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
emphasized.

“Use one of the following:”

Don’t

“Use 1 of the following:”

In the second example, the use of 1 feels incorrect. The problem here is that, although the information is technical valid, the reader will slow down and possible re-read this section.

“Why do they say, ‘Use 1…’ ”

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.

Conclusion

Help the reader become familiar with your writing style and format. Don’t spring surprises!

One way to do this when writing procedures is to remove any possible misunderstanding from your instructions. In other words, look at the numbering systems you’re using and ask yourself if the person reading this could be confused by the way you’re written it.

If the numbers could be misunderstood, then revise the text and use numbers that clarify how the process works.

SOP Naming Conventions

admin — Tue, 18 Oct 2011 14:27:12 +0000

What are naming conventions and why are they 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:

ABC-US-0512-D-1
XYZ-UK-0712-P-2
TNT-GBL-1212-A-1

Let’s look at each one.

ABC-US-0512-D-1

This means

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

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

You get the idea.

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

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:

XYZ_SWD_SOP_BankCreditCardApplication_v1_2_616

Use underscores to separate SOP naming elements.

Also, use this SOP naming convention in the header and/or footer. I’d also suggest that you place it on the cover sheet.

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.

Dates

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….

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.

Conclusion

Before you start writing your SOPs, give some thought to how they will be managed a year from now.

How will hundreds of documents, with different versions, and status controls be managed effectively. Possibly by someone else.

Create a meaningful naming convention and then explain to the procedure writers how it works. Don’t assume everyone will understand it. Share examples and make yourself averrable to help others, especially those who are new to procedure writing.

Any questions, drop me a line.

Warren Buffett’s 10 Steps To Better Report Writing

admin — Tue, 12 Oct 2010 23:32:00 +0000

Buffett writes like he speaks. Direct, immediate and without pretension.

“For more than forty years, I’ve studied the documents that public companies file. Too often, I’ve been unable to decipher just what is being said or, worse yet, had to conclude that nothing was being said. If corporate lawyers and their clients follow the advice in this handbook, my life is going to become much easier. “ Warren Buffet

In 2002, I found the Plain Language writing technique almost by accident. It’s also called Plain English, by the way. I was reading a lot about Warren Buffet a few years back and came across a nice, short document he wrote for the SEC. These are the folks who submit legal and business document to Wall Street when going on the stock exchanges.

Ever read an annual report from Warren Buffet. Try it. Easy, isn’t it? Few successful business-people write so clearly. There is no pretension, no haughty references to obscure allusions and no strange acronyms. It’s all there in black and white. Here’s what Buffet had to say about other business writers, though,

Audience Analysis worksheets.

From the handbook:

There are several possible explanations as to why I and others sometimes stumble over an accounting note or indenture description. Maybe we simply don’t have the technical knowledge to grasp what the writer wishes to convey. Or perhaps the writer doesn’t understand what he or she is talking about. In some cases, moreover, I suspect that a less-than scrupulous issuer doesn’t want us to understand a subject it feels legally obligated to touch upon. “

He adds that “Perhaps the most common problem, however, is that a well-intentioned and informed writer simply fails to get the message across to an intelligent, interested reader. In that case, stilted jargon and complex constructions are usually the villains.”

It’s a great read and you can download it here www.sec.gov/pdf/handbook.pdf in PDF.

Write Business Proposals in clear English

So, with this in mind, I wrote this short guide to help you write Business Proposals in clear English. It explains how to prepare an business documents that readers can digest in one reading. That’s the acid test. They shouldn’t have to read them twice and three times to get the meaning. It also covers how to use Plain Language writing techniques to win more business, accelerate your tender process, and encourage staff to contribute to the overall tender process.

1. Start Early

Developing a Plain English document takes time – the first time!. For your first Plain English proposal, allow extra time to write, edit, and revise. Add more time than you would expect to your usual schedule if possible. The next time it’s easier.

2. Study the principles of Plain English

Remember: you want your request for proposal to be understood in one reading. This means you need to:

Identify your target audience i.e. Government departments.
Consider what they need to know.
Consider the technical terms they may, or may not, know.
Develop plain English writing guidelines for your staff.
Think about how to organize and format your Proposal.

3. Promote Plain English amongst your Staff

Once you’ve seen the benefits of plain English compared with other writing styles, you can promote its values to your own staff and senior management. You need to get your staff onside so that they will begin writing in this style. Likewise, you also need to convince your managers of its values and possibly funding for a training program. Explain to both camps how they will benefit. Outline a high-level roadmap with timelines for the overall program.

4. Contact an experienced proposal writer

The first time you write a plain English proposal, you may find it time-consuming and more difficult than you thought. If this is the case, you’re on the right track! Everything worthwhile is difficult the first time round – soon you will get the hang of it.

You can also approach a writing consultant, especially someone who has a proven track record of writing good, clear English.

5. Review previous Proposals and see where you can improve

Before you start writing, consider the following:

Literacy level. What level of education is required to understand the Proposal? Use the Fog Index to test your proposal’s readability.
Clarity. What parts of the Proposal are hard to understand? Are the sentences too long and complex? Does it use technical terms and acronyms that the target audience will not understand?
Organization. How easy can you find relevant information? Would the Proposal be clearer if you reordered the main sections and possibly the sub-sections within it? Does the table of contents and index need sharpening? Are there too many/too few levels of information in the TOC.
Repetition. Is the same information repeated in several sections? Does it have any real benefit?
Headings. Should the headings be re-written in the form of questions that each section answers?
Format. Do you need to add more bullet-point lists? Put keywords in bold? Use more white space?

6. Create an outline to help readers find information faster

One very effective writing style is to write headings as questions,which each section answers. If you include sub-sections, use a numbered outline format (e.g. 1.2, 1.3) for the section headings. This helps the reader find the main sections quickly and see the relationship among subsections.

7. Write the RFP, section by section, using plain language techniques

If some sections are hard to write, read them aloud and see where they are difficult to understand. Go through the document section by section.

Write the first draft of key sections first, and then work on the inside sections. Once you’ve written these, refine the text by editing each section tightly. However, make sure your text does not become too cold and dry. Write as if you were speaking to a colleague whom you respect; this often helps control the tone of the document.

8. Review and Revise

Once you’ve finished the first draft, get it reviewed internally by colleagues who can add value to the review process. Don’t choose colleagues who are too close to the Proposal, as they will not see errors. Instead, get a neutral reviewer if possible. After getting the feedback, make the required edits.

If possible, ask volunteers from the target population to review the draft Proposal. Ask them if they can locate information easily. When interviewing ask open questions and you will get a better response.

Avoid closed questions, such as, is this a great RFP? Most will say Yes, just to please you – and make you go away!

Ask how much they could read in one sitting. Again, revise as needed.

9. Create an easy-to-read format

Format the document to make it easy to read and attractive in presentation. If you have time, prepare a template that can be re-used for all future RFP’s. This will reduce the time spend on preparing the document.

Leave a blank line between paragraphs
Use bulleted lists
Highlight main points with bold and italics
Use boxes for examples
Use white space generously
Include margins of at least one inch all around the page
Use two (2) columns to increase readability, if practical

Use several different type sizes for headings. In many documents, the headings are in San Serif font (i.e. Verdana) and the body is in a Serif font (e.g. Times New Roman). Use a contrast in style to add emphasis.

10. Get feedback – and share it

Lastly, see if the Proposal works! Ask the external reviewers how they felt using the ‘new’ plain English Proposal. Get feedback from personnel involved in the review process and collate it for distribution.

Did they find that the plain English Proposal made a better application?
Was it easier to write the application, and what made the most difference?
What worked and what needs more refinement.

Summarize what you learned and share this information with colleagues. Encourage them to try writing plain English Proposals.

Track Your Proposal Wins

Keep a record of all the Proposals written in plain English and see if their success rate is higher than the previous styles of writing. There are more great writing resources are at: http://www.plainenglish.co.uk/

About the Author: Ivan Walsh provides Business Tips for Smart People on Klariti.com. His also runs the popular Business Planning Blog at http://www.ivanwalsh.com. Follow him on Twitter @ivanwalsh

How to Prioritize SOPs When Controlling Documents

admin — Tue, 12 Oct 2010 17:10:17 +0000

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?

Pic: formatbrain

Step 10 – How to Implement Procedures

admin — Wed, 22 Sep 2010 11:08:52 +0000

photo credit: Jinho.Jung

The best way to implement policies and procedures is to ensure they are well-written, useful, and simplify things for the reader. Use this checklist to ensure that your SOPs get implemented correctly.

Sell the Sizzle

Put yourself in the reader’s shoes. All they see is another email telling them they have to do something. Or worse. Do something different. This makes people resist even BEFORE they’ve opened the email. So, step back and see how you can make the reader WANT to read your policy or procedure. How? Highlight the benefit.

Ask for Feedback

Don’t just ask it, mean it. Ask the frontline staff who will use the document, does it work for them. In large organizations, these folks are often the last to see the new policy or procedure. Yet, they are expected to use it. Something doesn’t add up here. Ask them what they think, take their comments onboard and make the changes.

Be Grateful

Then send a nice email thanking them for making the effort to get back to you.

If you can… walk over and thank them in person.

Once you get folks onside, it’s much easier to implement, change and enforce a policy. Their on your side. They want to help. But you’ve got to keep them in the loop.

Give Instructions

Have you ever avoided doing something not because you didn’t want to do it but because you didn’t know how to? We’re all like that. Sometimes people want to help but don’t know how. You need to give them direction. There are different ways to do this.

Hold workshops for their team leads and show them how the new procedure works
Arrange 1-1 sessions with the frontline staff so they all feel comfortable with the documents.
Highlight any special responsibilities that they need to be aware of. Be kind. Don’t strike fear into their soul. Help them to do their job that little bit better.
Email people after a week or two and see if they’ve seen anything that you need to change in the procedures. Again, it’s not that they are lazy but most staff don’t feel it’s their place to approach you. So, you need to make the first move.

Schedule Assessments

Schedule assessments every quarter. Check that the team are following the procedures correctly. If not, don’t reprimand them instead look for ways to make the process easier to understand. Again, people want to do things write but sometimes they need direction.

For example?

We created a set of Procedure documents. These were converted into PDF and uploaded to the intranet.

So far, so good.

But the PDFs had fields and text boxes. The staff were meant to fill in the fields when performing different tasks. The problem was that they couldn’t see the Save button.

There was a shortcut key but most didn’t use it as they often got it mixed up and did more harm than good.

We changed the design on the forms in the PDF and suddenly everyone was using the procedures correctly.

The message here is that while the Policy/Procedure document may be fine, the tasks associated with using it may confuse the staff.

Keep your eyes peeled and see where staff are getting tripped up when following instructions.

Conclusion

Those are some ways I implement Policies and Procedures.

One last thing.

I try not to say that I ‘enforce’ policies.

Why?

The word enforce sounds like I’m policing people. That’s not my job. I don’t have a badge!

How about you?

What do you do to implement procedures and other business documents? What mistakes do others make when doing this?

Stage 9 – Publishing the Standard Operating Procedures

admin — Mon, 20 Sep 2010 10:04:27 +0000

photo credit: redspotted

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.

Conclusion

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?

Stage 8 – Signing-off the Procedure

admin — Sat, 18 Sep 2010 17:12:30 +0000

photo credit: striatic

We’ve now completed seven stages in the Procedure writing process. From gathering the requirements, interviewing the Subject Matter Experts, drafting the procedures and getting them reviewed. This takes us up the stage where the documents must be signed off by the Project Stakeholders. While this seems straightforward, there are a few hazards that need to be avoided.

Getting the Procedure Approved

Now that you have finished writing the procedure, you need to get it approved and sent out to those who will use it.

The procedure should have been reviewed by the SME and others assigned to reviewing the SOP.
Changes have been incorporated.
The Version History has been updated to reflect the changes to each draft.

How to get it approved:

Send the final document to the person assigned to approve the document (usually your manager) with the correct naming structure, for example, ACME-Pharma-D-SOP-05052009. The ‘D’ means the document is still in Draft and is not a Final document.
The approver examines the documents. Their role is not to check the integrity or accuracy of the material (the SMEs should have done this) but rather to ensure that it has been through the correct review process.
The Approver enters the name, date, and any comments to finalize the document. Most SOP templates have a section for the Document History at the start.
The Approver saves the document and change the D to F, so that this is now a Final document.
Tip: Most companies save their official procedures as PDFs. We use CutePDF (www.cutepdf.com) to convert our Word documents into PDF. It’s free and very easy to use. Install it and then click File, Print and choose CutePDF Writer to generate the PDF file.
The Approver returns the document to the Document Owner (possibly you or your team lead) who changes the status from D to F. The document is now Final.
Circulate the procedure to the main contributors, so they have a copy for their reference. I’d suggest you include a nice ‘thank you’ to those who’ve helped with this piece of work. It doesn’t take much time and shows you’ve appreciated their time and effort. And, of course, builds up some goodwill that you may need when you start the next round of procedures.
Encourage feedback and acknowledge users to contact you if they find something that needs to be addressed.

Finally, to make sure those who need to use the procedure can find it, add it to your Document Management System and, if applicable, to your Intranet.

Procedures must be reviewed on a scheduled basis and also when IT systems are upgraded or changed.

Factor this into your project schedule and highlight whatever resources you may need in advance. Procedures are living documents and must be treated as such. When any step changes, the procedures must be updated to reflect these changes.

What do you look for when approving documents? How do you know you’ve got it right?

Stage 7. How to Test Standard Operating Procedures

admin — Thu, 16 Sep 2010 09:54:43 +0000

photo credit: Charles & Hudson

In Part 7 in our series on writing Standard Operating Procedures we look at how to test the Procedures.

How to Test Procedures

The first question is who tests the procedure?

One of the risks of testing your own procedure is that you’ve become snowblind to how the process actually works and fail to see steps that need to be captured. Also, you may take things for granted which the reader needs to be aware of, such as security precautions or items that need to be in place for the procedure to work.

Print out the procedure. Try to avoid reading the procedure from the screen. Many users will have it in their hands when reading the instructions so put yourself in their shoes and see if it makes sense.
Start at the top and sequentially through the steps. Don’t lose patience and skip down to the next section.
Check who does what. Let’s say the procedure has a column (usually far right) for the person or IT system performing the action.
For example, in Step 1, the user may enter a credit card number into the ATM. In Step 2, the ATM checks the card. Make sure that this column is correct for each step, especially if there are handovers between people and/or between IT systems.
Check off each step as you test the process. Make notes where there are conflicts or ambiguities that need to be clarified.
Check that the steps in the procedure agree with what should happen. Also, if the IT system generates a message, such as, ‘Enter your PIN number’, then check that this is captured correctly in the procedure.
Note any errors in the margin and add it to the procedure once you’ve finished.
Check every exceptions, warning or and multiple choice presented to the user. When users are offered choices, make sure you capture each choice is a separate section.
Check that the cells in the If Then tables present such material correctly. It should work like this; if the user does this, then he these step 1. Or, if the user does this, then follow these other steps.
Another way to test your procedure is to start at the end and work your way backwards. While this may not be practical for all procedures, try it where possible. It forces you to pay attention and uncovers errors that you may have overlooked when following the ‘logical sequence’ of events.

Getting Others To Test the Procedure

Finally, if possible, get someone who will perform the actual procedure to test it.

Sit down with them and observe how they perform the task. Things you took for granted or assumed the user would know, may stop the user in their tracks.
This could be something minor, such as a small font size (which the web designers think is trendy) but which makes the text almost unreadable.
Once the procedure has been tested, return it to the writer for them to accept the changes you have made. If there are a high level of errors or exceptions that warrant attention, schedule a meeting with your colleague and walk them through the points you’ve raised.

Using the Track Changes feature in MS Word is a simple and effective way to enter comments. To turn this on, click Tools, Track Changes. The recipient can accept or reject the changes and then save the final version with the correct text.

PS – If you’ve missed the other six tutorials, sign up for the newsletter and the whole set of tutorials will be sent to you automatically.

Stage 6 – How to Write Standard Operating Procedures

admin — Tue, 14 Sep 2010 09:13:30 +0000

photo credit: cristinabe

This is Part 6 in our series on writing Standard Operating Procedures. If you’ve missed the first five, sign up for the newsletter and the whole set of tutorials will be sent to you automatically.

How to Write Standard Operating Procedures

Next up, write the procedure. First, let’s take a deep breath and see where we are.

So far, we’ve:

Shared our vision with the Management team so they understand how all Departments, Business Units, Customers and Staff will benefit from this activity. Getting support from Management is crucial as their support will give the project the attention it deserves especially when you hit bottlenecks.
Defined a writing process for the procedure writers and those involved in all associated procedure-related activities, for example, testing that the procedures work as per the instructions. Note that some procedures can only be tested in a live environment and need to be managed with care.
Gathered the documents, process maps, flowcharts, and other material we needed to assess the procedure
Interviewed those who use the procedure in a working environment, for example, the Call Centre staff if you’re writing Technical Support procedures.
Interviewed those who prepared the current procedure and asked for their recommendations on how it could be improved.
Collated all the material on the shared server (maybe password protected if you’re concerned that others are too curious about works in progress.)
Updated the Project Stakeholders every week with Status Reports.
Sent reminders to other parties that you will need time with their staff in the coming weeks. Always give advance notice. You’re colleagues have their schedules too.

Structure the Writing Project

Large companies have libraries of SOP templates for such projects. They will also have invested in Style Guides, Writing Manuals and other materials to assist their writing teams.

If you don’t have these, buy some professional Procedure templates on the web so you can hit the ground running. Make sure the templates work on your PCs, are easy to modify and within budget.

Of course, you can always create your own – choose whichever is most cost effective. Time lost is money lost. Use common sense and get started.

How to Write Procedures

This week we’ll look at how procedure writing at a high level. In the coming weeks, we will drill down and show you how to write procedures from scratch.

Before you start writing, do the following.

Naming Convention – Establish a Naming Convention for the documents. Think ahead. If you have 200 procedures to manage, what naming convention would work best to track the documents.
Web Friendly – Remember, SOPs may also be published to the Internet, so use a system that is intuitive and easy to follow. Don’t get too esoteric!
Share – Create a Shared Drive where all the writers can post the documents. Password protect the drive, if necessary.
Style Guides- Invest in Style Guides and other support material. Make sure there are enough copies to go around. Some will hog the guides and resist sharing.
Templates – Develop a set of easy-to-use templates. Don’t make them so complex that writers need to be trained to use them. Keep it simple and assume that others (non-team members) will use the same templates to update the procedures.

Tip: Number each procedure. Use Excel to record and track each procedure.

Tell me more about Naming Conventions!

Instead of calling the document, Health Procedure.doc, give it a more meaningful title. For example, ACME-Pharma-F-SOP-05052009.

ACME refers to the name of the company or client or project
Pharma refers to this division within the company
F refers to Final. D can be used for Draft.
SOP refers to the document type.
05052009 is the date the document was signed off.

Using a naming convention will allow you to retrieve documents faster, especially if you have multiple versions of the same document all with different sign off dates. You want to avoid making the reader open each document to determine the version numbers.

If you use MS Word, use the File, Properties option to add further information, such as keywords, Author name, and other comments.

Writing Your First Procedure

Procedures are instructions. So, put yourself in the user’s shoes and write from their perspective. In other words, unlike other types of documentation, you don’t need to give the reader very much background details.

Do the following:

Write in the Present tense. The user is performing the task NOW. Don’t write in the past, conditional or future tenses unless you have good reason to do so.
Avoid Ambiguity.
Be concise.
Use short words. This isn’t a romantic novel you’re writing. Keep the words short and get to the point.
Move from one step to the next in a logical manner. Steps should follow each other in a logical order.
Highlight Exceptions. Use a symbol to flag that this is an exception and how to handle it.
Highlight Warnings. Again, warn the user that caution must be used in this scenario. Warnings MUST stand out. Use a larger font or a warning icon.
Reduce the word count where possible without altering the meaning of the text.

Do Not:

Introduce acronyms without explaining what it means. What does OLA mean to you? I know but most folks don’t.
Be Vague. Don’t use the work ‘may’ if possible as it implies that the user can do something under certain conditions. Instead be positive and tell them what to do.
Get the sequence wrong. Steps have to be in the correct order.
List steps that should be numbered. What I mean is that some items can be listed, for example, a list of ingredients when cooking. But, you need to number the steps in the correct order so the cook can prepare the dish.

Finally, the process of writing a SOP requires the writer to consider all steps in the procedure and perform a risk assessment before work begins. The best approach to writing a SOP is to perform the procedure, write it and test it, write it again.

Number Each Step in the Procedure

Every procedure lists the actions that the reader must take. To keep things simple, we list the actions (aka steps) is sequential order. Start at 1 and work upwards.

Note that some Business Analysts prefer to start at 0 and continue from there. Starting at 0 is used in Project Management documentation and often crosses over to other business documents.

Which is Right?

What’s important is that you choose one style and be consistent. Don’t change styles. Make sure your co-writers also use the same numbering system.

Also, if you’re using MS Word to write the documents, you can take advantage of the automatic numbering system. If you opt to start at 0, create a unique Style for numbering the steps and use this instead.

One word of warning: if you share writing duties, you may have to remind the other writers to start at 0 instead of 1. I prefer to keep things simple and start all lists at 1.

Why Number Steps?

There’s a few reasons for this:

It ensure that the reader starts at the correct place.
It removes any ambiguity or misunderstanding that could arise if the steps were not numbered.
It ensures that the reader does not ‘interpret’ the procedure as he/she understand it and makes errors when performing the task
It ensures that there is an agreed way for all staff to perform the same task. While this may seem intuitive, in smaller companies staff may performs tasks in different ways as per their understanding, training and preferences. How you backup files may be very different than how your colleagues do it.

How About Exceptions?

There are different schools of thought on this. Number the steps starting at 1 and

Continue upwards, e.g. 2, 3, 4, etc.

Use 1.1, 1.2, 1.3 for sub-steps.

Use If Then Else tables for sub-steps.

If Then tables let you present information is a nice, attractive manner and lets the reader see the different options available to them in a grid format.

How do It Then Tables work?

A simple example is applying for a bank loan.

If	Then	And
If the value of the property is less than $500k	Deposit 10% of value	Minimum deposit is 50k.
If the value of the property is less than $700k	Deposit 12% of value	Minimum deposit is 70k.
If the value of the property is less than $900k	Deposit 15% of value	Minimum deposit is 90k.

The advantage of using an If Then table is that the user can drill-down and find the EXACT piece of information they need. For example, they need to know there is a 50k minimum deposit.

The alternative is to present the information as a list. While this may be easier for you to write (i.e. you don’t need to create tables) it is harder for the reader to locate the specific piece of information.

If the value of the property is less than $500k, you must deposit 10% of value and the minimum deposit is 50k.
If the value of the property is less than $700k, you must deposit 12% of value and the minimum deposit is 70k.
If the value of the property is less than $900k, you must deposit 15% of value and the minimum deposit is 90k.

They have to scan the entire sentence until the locate the information and then read the next line to compare one piece against the other. Not easy to do when you’re tired or in a crowded bank branch with small children running around.

Over the coming weeks, we’ll drill down and look at other ways to write your procedures.

Tomorrow, we’ll look at how to test the procedure.

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

admin — Sun, 12 Sep 2010 15:19:48 +0000

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.

photo credit: pasukaru76

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.

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

admin — Fri, 10 Sep 2010 12:49:28 +0000

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’.

photo credit: horslips5

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:

Document how the process works
Understand where and how it interacts with other processes
Examine where it can be improved
Share this information with everyone on the team

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:

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?

Stage 3 – Establishing SOP Writing Procedures

admin — Wed, 08 Sep 2010 15:46:53 +0000

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.

Stage 2 – Organizing the Procedure Writing Team

admin — Mon, 06 Sep 2010 14:32:26 +0000

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.

Why?

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.

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

admin — Sat, 04 Sep 2010 13:54:23 +0000

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

Stage 0 – Before You Start Writing Standard Operating Procedures

admin — Thu, 02 Sep 2010 15:21:11 +0000

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.

10 Step Plan For Writing Standard Operating Procedures

admin — Wed, 01 Sep 2010 16:09:49 +0000

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.

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.

If there is something that you’d like us to clarify or expand upon then please share it in the comments section below.

See you then.

PS – you may want to add this site to your RSS reader or subscribe to the Newsletter. That way you’ll get all the blog posts to your inbox and won’t miss any tutorials.

6 Examples of Standard Operating Procedures

admin — Tue, 31 Aug 2010 09:32:38 +0000

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, formant, 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.

www.fao.org/docrep/w7295e/w7295e04.htm

2. Biotechnology Program, Montgomery College – SOP

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

www.montgomerycollege.edu/Departments/biotechnology/sop.html

3. Safety Training Resources

www.ehs.uci.edu/programs/sop_library

4. Emergency Management Program Standard Operating Procedure (SOP)

www.pandemicflu.va.gov/

5. Employee Training and Development

http://www.feedforward.com.au/sop_training.htm

6. Developing Effective Standard Operating Procedures

www.ansci.cornell.edu/pdfs/sopsdir.pdf

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

Business Process Design Tutorial # 1: Why, What & How?

admin — Thu, 12 Aug 2010 10:39:00 +0000

At the end of the workshop, our client confessed, ‘I didn’t know our business worked like that’.

We’d come onsite and over three months mapped out the processes in his Finance, Sales and Operations Depts. For me, one of the most rewarding aspects of Business Analysis is discovering how a business works and then mapping it out in Visio.

Business Process Template – MS Word

Definition: What is a Business Process?

We write the process narratives in Word. In simple terms, business process design is a way of gathering related, structured activities (tasks) that serve a particular goal, usually for customer though it can also be for an IT system. The best way I’ve found to capture the business process is in flowcharts, which show the sequence of activities and where each task inter-relates.

I’ve learnt so much how business models work by taking a business apart, process by process, and seeing where it’s working best and where it needs some fine-tuning.

One definition of a business process is that it’s a ‘set of coordinated tasks and activities that will lead to accomplishing a specific organizational goal’ TechTarget’s Definition of Business Process. In addition, business process management (BPM) is a systematic approach to improving those processes.
The Business Process Management Initiative (BPMI) promotes the standardization of common business processes, as a means of furthering e-business and business-to-business (B2B) development. To realize end, it developed the Business Process Modeling Language (BPML), an Extensible Markup Language (XML)-based meta-language for modeling business processes.
A business process diagram let’s you illustrate activities that are designed to produce specific outputs. For example, if you worked for a bank, you might have a Credit Card application process.That shows what the customer needs to give in, what happens when the application is received, and what results are expected. The customer gets a new credit card or is rejected. You need to design processes for each these scenarios.

Visio Business Process templates

Business Process Example

Let’s look at an example of creating a process flow diagram for a Credit Card application. Like we said, business processes show how to capture (record) the order in which activities occur.

For example.

Customer applies for credit card on the bank site
Or
Customer applies for credit card in the branch
Or
Customer applies for credit card at promotional event
Then
The credit card application is received electronically, but the email is wrong (separate process flow)
The credit card application is received at main office, but address is missing (separate process flow)
The credit card application is received at branch office who send it to head office (separate process flow) Then
The customer gets a new credit card in the post
The customer is offered a new credit card but has to come into the branch (with ID) to pick it up
The customer is offered a new credit card but it send to the wrong address (printing error)
Or
The customer is rejected online.
The customer is rejected at branch.
The customer is rejected at sub-branch.

All of these scenarios need to be mapped correctly and, if necessary, form part of a new process. For example, the credit card rejection process. As a Business Analyst, you need to design business processes for each these scenarios.

Business Process Analysis

A process must have a start, inputs (documents or information) and outputs (reports/forms/results). At its most simple level, every process has a:

Start – what triggers the process into action? I want a credit card.
Middle – what goes on in the process? The different steps, including variations, business rules, and possible exceptions.
End – what conditions are necessary to close the process? I got my plastic friend. Woohoo!

Business process modeling involves designing processes that add value by showing the transformation of inputs into useful outputs.

What inputs go into the Business Process?

Inputs are whatever enters something into the process, for example, the customer (a human resource) submits a credit card application. In another process, a HR system (equipment) may submit a report to anther IT system, maybe the SAP or Oracle databases. Inputs can be resources (people), materials, energy, and equipment (software).

In UML, a resource is an input to a business process and is consumed during the processing. For example, as each daily train service is run, the service resource is ‘used up’ as far as the process of recording actual train times is concerned. When mapping business processes, an Input link indicates that the resource is consumed in the processing procedure. For example, when customer orders are processed they are signed off and used only once per order.

What are Business Process Analysis outputs?

Outputs are the result, the end product, in the business cycle. Outputs may be a physical product (possibly used as an input to another process) or a service. Outputs are whatever is produced as a result of this action. While this seems obvious, remember that in complexes there may be two or more outputs. You need to decide which is the main output and relegate other outputs to sub-processes. More on sub-processes later.

As a Business Analyst, this means that in the credit card application, the outputs will be the Acceptance of the Credit Card request or a Rejection of the request. When designing the process map, make sure you cover all scenarios so the process flow and all intermediate activities are mapped.

Conclusion

A business process will typically produce one or more outputs to the business, either for internal use of to satisfy external requirements. Outputs may be a physical object (such as a report), a transformation of raw resources into a new arrangement (a daily schedule) or a business result such as completing a customer order.

Remember, business process A’s output may feed into business processes B, either as a requested item or a trigger to start new activities.

Next week, I’ll look at how to use Business Process design techniques for large Software Development projects. You might want to read this if you’re looking at ways to improve your department’s performance, outsource projects, or to improve your knowledge of process design.

Do you enjoy process design or designing flowcharts? Please share your thoughts or lessons learnt below.

About the Author: Ivan Walsh is a contributing editor to the Klariti Small Business Centre. Ivan also shares Business Plan Ideas for SMEs on his business blog. Follow him on Twitter

How to Stop Your SOP Procedure Templates From Crashing – Part 1

admin — Mon, 12 Jul 2010 04:46:00 +0000

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

But….

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.

And…

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.

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.

Standard Operating Procedure Tips

SOP Writing – How Much Detail Is Required?

Why Less is More in procedure writing

SOP Writing Guidelines

How to Use Numbers in Procedures Correctly

Adding Numerical Information to SOPs

1. Using spelled-out numbers

2. Use of spelled-out numbers with emphasis.

3. Use Arabic numbers to present numerical information

4. Consistency

SOP Naming Conventions

Naming Conventions 101

Sample SOP Naming Conventions

SOP Naming Conventions: Guidelines

SOP Naming Conventions: Updating

Version Number

Dates

Archives

SOP Naming Conventions: Best Practices

Warren Buffett’s 10 Steps To Better Report Writing

Write Business Proposals in clear English

1. Start Early

2. Study the principles of Plain English

3. Promote Plain English amongst your Staff

4. Contact an experienced proposal writer

5. Review previous Proposals and see where you can improve

6. Create an outline to help readers find information faster

7. Write the RFP, section by section, using plain language techniques

8. Review and Revise

9. Create an easy-to-read format

10. Get feedback – and share it

Track Your Proposal Wins

How to Prioritize SOPs When Controlling Documents

How to Prioritize SOPs? Keep It Simple

Create an Excel Spreadsheet

Low, Medium or High?

Give it Status

Step 10 – How to Implement Procedures

Sell the Sizzle

Ask for Feedback

Be Grateful

Give Instructions

Schedule Assessments

Conclusion

Stage 9 – Publishing the Standard Operating Procedures

How to Control Documents

Communicate Frequently

Use Naming Conventions

Check Track Changes

Convert to PDF

Uploaded to Document Management System

Create an Archive

Backup Very ‘Olde’ Documents to Tape

Conclusion

Stage 8 – Signing-off the Procedure

Getting the Procedure Approved

Stage 7. How to Test Standard Operating Procedures

How to Test Procedures

Getting Others To Test the Procedure

Stage 6 – How to Write Standard Operating Procedures

How to Write Standard Operating Procedures

Structure the Writing Project

How to Write Procedures

Writing Your First Procedure

Number Each Step in the Procedure

Why Number Steps?

How About Exceptions?

How do It Then Tables work?

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

Gathering Data For Procedures

Does the Process Work?

Looking at Alternatives To The Current Process

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

The Tale of the Information Gathering Phase

What Information Are You Gathering?

How to get started?

Stage 3 – Establishing SOP Writing Procedures

SOP Writing Guidelines

Stage 2 – Organizing the Procedure Writing Team

Create a Framework for the Writers