Standard Operating Procedure Tips » Standard Operating Procedure

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

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.

How to Fix Corrupt & Damaged Microsoft Word Documents – Part 2

admin — Fri, 04 Jun 2010 11:37:06 +0000

Last week we showed you how Bullet Lists can crash MS Word. We outlined some techniques to reduce the file size, mostly by creating pre-formatted bullet lists in advance. But what happens if you’re given a Standard Operating Procedure whose file size is already bloated to massive proportions. It’s too late to create new styles at this stage.

Here’s what to do.

1. Open the User Guide in Microsoft Word.

2. Cut and paste every graphic from the file into an image-editing tool, such as Snagit.

Create a naming convention, (e.g. Page1-A.gif, Page1-B.gif etc) and name each graphic using the same naming convention.

WARNING: DON’T SAVE THE FILE YET!

3. In Word, select File, Save As HTML.

Name the file with an HTML extension, e.g. Proposal.html and then close Word.

4. Re-open Word. Select File, Open and select the Proposal.html file.

5. Select File, Save As and save Proposal.html with a .doc extension, e.g. Proposal.doc.

TIP: This process of converting the Microsoft Word file into HTML and back into Word, removes unnecessary (i.e. corrupt) code in the file and will significantly reduce the file size.

6. Insert the graphic back in the correct order.

I’ve seen Word files larger than 20 MB reduced to less than 3MB in less than one minute by using this technique. Might be worth a try! The reason you don’t save the file at Step 2 is because this would trigger Word into action (e.g. I WILL now save this file etc) and as it struggles to save the oversized file, will probably crash the application.

I hoped you enjoyed these articles on fixing corrupt or damaged documents. What’s been your experience using Word?

About the Author: Ivan Walsh shares Action Plan Tips at Klariti. He also creates Business Plans for SMEs