Want to improve the title of your procedures? Let’s look at some ways to make the title more useful to the reader and also reflect the exact nature of the task.
The title of your procedure serves several purposes:
Identify purpose – distill the purpose of the task into a single sentence, remove clutter, and prioritize what the objective of this procedure. This helps you as a writer to write more useful instructions, and also clarifies for the reader what they can expect. So, if the title of the procedure is used to create expectations, then develop the text to explain how to achieve this.
Orient readers – this helps them understand where they are and confirms if they are in the correct part of the document set. If not, include links to other relevant procedure in the For More Information section at the end of the page.
Starting Point – as the reader may be new to the company, using your product etc, they may not know which procedures are possible to perform. For this reason, identify all possible procedures on a master page and explain as concisely as possible the benefit and outcome of each one.
Remove ambiguity – write from the user’s perspective. Avoid in-house terms. Remove acronyms. Also, use terms the user will understand. It’s fine to define terms or cross-reference to a glossary.
Two other ways to improve your procedures:
Link to Other Relevant Procedures – avoid making the reader search for information, such as definitions or associated procedures. Your aim is to keep them on the page and help them perform their task at one sitting.
Business Rich Screenshots – only include these if they add value. For example, if it’s not obvious where in the user interface a specific icon is displayed, then take a screenshot, crop it and highlight exactly where the icon is located. Don’t include screenshots unless they provide business information and clarify how this step in the procedure should be performed. A second example is a field that may be ‘hidden’ unless, for example, a checkbox is selected. Highlighting this helps the user use the product and also makes them feel you’re fighting their corner.
Before you start writing your procedure, give some thought to how this will benefit them both from a personal and business level. In other words, you can encourage the reader to use your procedures if you describe the ways their life will be easier if they follow the steps exactly as you have written them. Make sense?
Here’s a few examples.
Business – describe how performing this procedure will benefit your business, for example, from an operational point of view, interacting with customers, or improving your quality of service.
Drivers – if possible, connect this procedure to a business driver or customer request. For example, if customers complained that they wanted invoices delivered as PDFs, then highlight this in the benefit section as this illustrates your responsiveness to customer concerns and also helps the reader understand the purpose of adopting the procedure. It also helps other procedure writer maintain the SOP as it gives them some context.
Productivity – give an example of how this procedure makes their life easier, for example, allowing them to complete a task faster, reducing the number of steps, or gives them more options. These type of benefits warm up the reader and encourage them to read the procedure more carefully. Why? Because they will anticipate that the procedure will remove current obstacles and impediments, making their working day more pleasant. And who doesn’t want that?
Time Savers – everyone is looking for ways to shave a few minutes off their day. Identify the number one benefit this procedure will offer in terms of time saving. In general, procedures help you simplify tasks and clarify how tasks should be performed.
Look for ways to emphasize these in the benefit section but keep it simple. Don’t distract the reader from their main purpose, which is to perform the task. However, a few sentences at the start helps orient them, place things in context, and creates an expectation of how the procedure will help them perform their tasks.
If appropriate, give a short example, but keep this brief. You can also consider having a follow on section – ie what to do next – at the end of the procedure, suggesting what the reader should do next.
If you are creating online help, you can add these under the For More Information section.
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?
Yesterday we looked at the Information Gathering Phase and described different ways you can get that information from Subject Matter Experts and those in the frontline who use the procedures.
Gathering Data For Procedures
In general, Business Analysts gather data through workshops and interviews. Emails work too but I prefer to see the white of their eyes.
You can also collect data from reading historical documents which may give more background to the project. These may include Specifications, Requirements and Flowcharts. Gather all these and hold them in a centralized location.
Does the Process Work?
As mentioned in the previous tutorial, we need to test the procedures (aka SOP) and determine if they work. Your goal at this point is to:
Determine if the procedure works as documented in the SOP.
Identify mistakes or anomalies that have crept into the material.
Determine if the procedure has been updated, version controlled, and also if multiple copies of the same SOP are in circulation. It’s not unusual for multiple copies of the same procedure to be in circulation if there is no known Document Owner or if there are no Version Controls in place.
Once you have captured the existing process, share your notes with the team members.
Looking at Alternatives To The Current Process
The next step is to look at alternative ways of performing this process and contingencies that need to be considered when developing the new process.
At this point, you should understand how the current process works. What you want to do is see:
Where it can be improved.
How the process can be streamlined so there are fewer activities, transactions, manual interactions required.
Who needs to be involved in the revised process.
What technologies are required to perform these tasks.
What parallel processes must be performed for the primary process to work correctly.
What sub-processes need to be developed to support the new process.
There are several ways to approach this. One is to look at the actors in the process, (for example, the Cashier) and see how his role could be streamlined.
What activities can be removed?
What activities could be collapsed into a single activity?
What tasks could be automated?
What activities could be changed so there are fewer activities later on.
What security measures need to be considered, for example, sharing information between department and/or with partners.
Here’s an example from the real world.
When I apply to have my credit card limit increased, the process works as follows:
Ivan contacts his Local Branch.
Local branch tells me to call another number. They can’t forward me for technical reasons.
Ivan called the Credit Card office.
Credit Card Dept ask me to fax in the paperwork, e.g. utility bill. They do not accept documents over the web. Oddly enough, you can apply for a credit card and even a mortgage over the web….
Credit Card Dept faxes this to Relationship Manager at Local Branch for verification purposes.
Local Branch forgets to process my application… Relationship Manager may have moved to different office.
Credit Card Dept don’t follow up.
Ivan calls Credit Card Dept to remind them to chase up Local Branch.
Ivan needs to send over the documents again.
Does Ivan do this? You know the answer, I’m sure.
OK, clearly this process could be improved if I could give the documents to my Local Branch instead and if there was a reminder for the Credit Card Dept to follow-up if they did not hear back from the Local Branch. Otherwise, applications disappear into black hole.
FYI – actually, I did. While re-sending the documents was an inconvenience, I wanted to finish this task and move on to the next thing… which you can read about tomorrow.
This is the part I like the most about writing procedures. It involves walking around and getting to know those who work with the actual procedure and know how it works ‘warts and all’.
The Tale of the Information Gathering Phase
One of the mistakes many writers make is to work at their PC and assume that the knowledge they need will come to them. All they have to do is send out some emails, right?
Not really. You need to get out and make connections with people. Once they can put a ‘name to the face’, it gets easier to arrange meetings. You’re not a stranger anymore. They know who you are and why this project means so much to you.
Also, by going to their desk, you’re showing that you’re making the effort to reach out to them. It’s also harder to say No to a person when they are in front of you. Deleting emails is a lot easier.
What Information Are You Gathering?
Let’s think about this for a second. The end goal is to be able to:
To get to that point you have to do a Sherlock Holmes.
Do a Sherlock Holmes?
What I mean is you need to look at this procedure as neutrally as possible. Think of yourself looking for clues, trying to find information that will explain exactly how the process works.
Many business analysts, maybe new to this field, think they know how a process works after a quick assessment. When they get into how it works – and when eagle-eyed team members review the first draft – it becomes clear that the process needs to be re-examined.
To recap: the information gathering phase is where you go out and collect all the information you need to prepare the procedures.
Shouldn’t it be obvious what you need to capture?
Not really. If you ask ten people how to get from your house to the city centre, they’ll all give you different routes. Everyone knows different shortcuts, different schedules, and better ways to get from A to B.
It’s the same with writing procedures and work instructions.
You don’t write Procedures in a vacuum. Meet up with other people and ask them how the procedure works. Let’s say, as an example, that you’re writing procedures for a bank. You want to know how mortgages applications are processed.
This process will typically involve numerous activities, all handled by different people, many of which are performed by different functions and disparate IT systems.
To capture each step in the process means sitting down with those who understand each task.
There are two parts involved in capturing how a process works.
Capture the As Is Process – The first is to ‘photograph’ how the actual process works. This is often called the ‘as-is’ process. In other words, you’re aim is to capture exactly how the process works, warts and all. You’re not concerned with finding faults, looking for improvements, or exploring alternative options. The as-is process shows how the process works, just as a photograph would.
Define the To Be Process – The second is the ‘to-be’ process. This involves looking at alternative ways of performing the process and different contingencies you can take if/when a specific action occurred. Exploring the to-be process is often called process redesign or process reengineering.
However, to get to this point, you need to understand the ‘as-is’ process very clearly.
If you start the second step without going through the first, you’re likely to make assumptions or overlook factors that will undermine the accuracy of the process.
How to get started?
You can speed things along by arranging workshops with the necessary subject matter experts. It’s unlikely that all will be able to attend; don’t worry. Get as many into the workshop as possible and go through the processes.
Make sure you have:
Overhead projectors and
If necessary, arrange for lunch to be delivered as this will give you more time with the attendees, instead of them splitting up for lunch. I’ve seen people go for lunch and not return for the afternoon session; do your best to keep them in the room. You mightn’t get a second chance.
If possible, get another team member to make notes as you’re running the workshop. You can compile these notes the next day and then circulate them to the attendees for their review.
The third stage of the procedure writing process involves setting up a framework whereby all the different writing activities are formalized.
This means that before the team starts writing the procedures, you can explain to them how the writing process to works and what is expected of each person.
SOP Writing Guidelines
To ensure that the procedures are written to the company standard, reviewed correctly, and reports are generated on time, establish a set of guidelines that shows each writer how the process works.
What is expected of each writer?
Not everyone is expected to write all the material. Some will develop process flows, while others may specialize in editing the documents or submitting them to the Document Management System.
How should they circulate the procedures?
Most documents will be written in MS Word or another writing tool. After the first draft is completed, is must be circulated for review. Show the writers how to do this, how to number the document correctly and how to use Track Changes.
What tools to use to write, edit and create the procedures?
If you use specialist tools for documenting the procedures, for example, open source tools, give each person adequate training and some best practices on how to use the product. You can save time over the long run by sharing this information upfront rather than expecting everyone to find out by themselves.
Likewise, make sure that all team members use the same version of the product to avoid backward compatibility issues. Procedures written in MS Word 2007 may not open in MS Word 2003, for example.
How to update the documents after each review?
During the Review Phase, each of the writers examines the draft document. What the writers look for on a low level are things like typos, incorrect spellings, and formatting issues. All of these are important to ensure that the presentation is correct, but really they need to go deeper.
They need to stress test the procedure so that the steps in the correct sequence, that there are no ambiguities, and that key steps have not been omitted. None of this has to do with presentation – it’s to do with accuracy.
Is the procedure correct in ALL respects?
Can the user use this procedure follow these instructions and achieve their goal?
Has the Reviewer explained exactly what needs to be changed to correct the document?
Also, the Reviewers must update the Change Log and show that it’s status is D fro Draft or R for under Review.
Other areas that we will examine in the coming weeks include:
How to file, store, and archive procedures?
How to work with the SMEs?
How to submit status reports?
How to arrange interviews?
Where they can find templates, style guides and other support material?
Do I have to do this? Shouldn’t they know how to do this already?
Maybe yes, maybe no.
Not everyone on the team has the same level of experience that you do. Try to gauge their level of expertise (especially if you ‘inherit’ writers from other teams) and walk through how the documentation process works.
Ensure that the team understands their roles clearly. Ask them a few questions to test their knowledge and see if they are comfortable with their duties.
Once a week take a team member to lunch offsite and try to get a feel for how the project is working for them. As a team lead, you’re likely to get wrapped up with deadlines, reports and other duties. Spend time with your team and see where things are working and where they could be improved. Avoid gossiping about co-workers, that’s not the point. Instead ask them how the current process could be improved.
There’s always room for improvement, right?
Next up? How to gather information from Subject Matter Experts.
Yesterday we showed how to get support from the Management team for the Procedure Writing project. We looked at how you need to sell the importance of the quality procedures to the Executive team and how they in turn can pass this message down the line.
Now that we have that in place we can look at the Procedure Writing team. This involves gathering the best writers (or hiring freelance contractors) and then showing them how to write the procedures based on your style guides and SOP templates.
Create a Framework for the Writers
While this seems obvious, not all writer and process designers will have the same understanding that you have.
Also, as different writers will have different tasks, it makes sense to discuss what each writer is expected to do, what to share, and how to report their weekly progress.
Assume nothing. Communication everywhere.
Defining the Procedure Writing Team
The Procedure Writing Team may include some or all of the following:
Full-time Procedure writers, possible yourself, whose primary role is to gather data and write up the procedures.
Part-time writers, such as Technical Writers in other department, who will assist you when/where needed.
Subject Matter Experts who will provide the knowledge you need to write the procedures. For example, in a bank you may have specialists with in-depth knowledge of how the credit card process works. These will be the people to interview when gathering data on how the current process works and also how to improve the process.
Contractors who will be hired for specific pieces of work. This includes Technical Writers, Editors, Graphic Designers, Process Designers, Information Mappers, and others in the publishing field.
Consultants who will also be brought in for special projects, for example those with Compliance or Sarbanes Oxley knowledge.
Those are some of the roles that will be involved in the overall Procedure Writing lifecycle. In some cases, the same person may wear two ‘hats’ or more.
For example, I often wear the hat of the Project Manager, Writer and Business Analyst. Remember, the management don’t care what job title you give yourself as long as the procedures get written on time.
How do I establish the Procedure Writing Team?
As with any team, you need to allocate responsibilities to each task. This means thinking about who is best placed to:
Revise the procedures when there are changes to the business processes
Assigning Writing Tasks
Depending on the resources at your disposal, you may be able to allocate different people to these tasks or if you’re circumstances are more modest, you can allocate multiple tasks to the same person.
In some projects, I handled most all of these tasks except the sign-off. While this is not ideal, the reality for many companies is that there are not enough hands to manage the workload and you have to ‘improvise’.
Warning: don’t give writing and testing tasks to the same person. I know this sounds obvious but writers can’t (or shouldn’t!) be asked to test their own material. After writing hundreds of words explaining how the procedure works, you tend to get ‘snow blind‘ and can’t tell the woods from the trees, so to speak.
Procedure Writing Team: Key Roles
Most projects will require the following roles:
This person is responsible for:
Gathering source material, such as the existing procedures, processes, and work instructions
Interviewing those with knowledge of how the procedure works
Arranging workshops and sessions to explore the material with Subject Matter Experts
Oddly enough, getting sign-off from the project stakeholders can be the hardest task.
Because getting people to approve a document means that they are now partly responsible for its quality. In projects where the SOPs are customer-facing, such as Health and Food related guidelines, it can be very hard to get the final sign-off.
This person is responsible for reviewing the procedure, which is usually sent to them by the Procedure writer.
You (as team lead or Procedure Writer) need to outline:
What is expected of them
How they should test the procedure
How to record errors in the document
How to flag contradictions and ambiguities
How to circulate the reviews to the writing team
How to escalate critical errors, for example, if the procedure is currently is use
How to close the testing cycle
Not all projects will require a Compliance Officer, for example, procedures to do with food handling or food safety would require the approval by a Health expert instead.
However, for procedures that involve banking, IT, government, security and data protection, this person must ensure that the material complies with the company’s
This is critical in pharmaceutical companies where procedures need to align to industry guidelines and official health standards. In the IT and Financial Services, business processes may need to comply with Sarbanes Oxley guidelines.
Flowcharts that illustrate how transactions occur across different departments or different actors
These diagrams are very helpful during sessions and workshop when you want to improve an existing process. Seeing the process as opposed to reading how it works brings the process to life and lets us see how the process works.
This person is typically the Line Manager or the Department Head who sponsored this activity. While this person may not read the procedures line by line, they will typically interview the writers, testers and compliance staff at the end of the project and quiz them on how they gathered the material, wrote the text and ensured that the procedures covers the most important areas.
For example, while minor errors, such as typos, may be overlooked by the auditors, if a procedure contravenes guidelines, such as Sarbanes Oxley controls, the company may fail the audit, which undermines the company’s credibility and is likely to lead to more intensive audits from here on. This person may also be responsible for allocating budgets to the project and ensuring that adequate funding is in place for the project (and/or writers) to succeed.
These are some of the roles you need to prepare your SOPs. Remember that there may be some overlap between different roles and the same person may have to perform multiple tasks.
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.
MS Word. Click top red arrow to expand/show the Style Menu.
And it’s not just business writers, in the world of technical publishing, Microsoft Word also gets a bad rap. Many feel that it’s unstable and crashing. It can also bloat in size until your operating system grinds to a halt.
the Problem with Bullet Lists & Large MS Word files
The first offender is Bullet Lists. If there is one thing that’s guaranteed to crash Microsoft Word, it’s bullet lists.
Here’s what tends to happen.
When you click a Bullet List from the Word toolbar, Word points this Bullet List to the Normal.dot file. In other words, it uses the default settings in Normal.dot and then applies these. Fine.
No problem! That’s what it’s supposed to do.
If you cut and paste a Bulleted List from one business report into your working file, then Microsoft Word has a problem.
Which Bullet List is the Master Bullet List?
It can’t tell because suddenly you have two bullet lists in your document.
If you add a third bullet style, maybe with nice styling or cool fonts, it has a nervous breakdown. Microsoft Word can’t tell which is which and begins to struggle.
How to stop Word Crashing & Losing your Business Proposal
Here’s what to do:
Open Word and create a separate Style for each type of bullet lists you need. For example create a Bullet Regular, Bullet List Indent, Bullet Square and so on.
When you need to use a bullet list, select the appropriate style from the Styles drop-down menu.
This is the Home tab in Microsoft Word 2007.
If you want to import a bullet list from another document, Copy the text into a blank document.
Select it, and in the Style menu, select Clear All. NB: This removes all formatting.
Paste it into the working document.
Apply the correct style.
I know this seems like more work but it’s not. Just paste into a blank document, remove the formatting and then paste it in. Your files will stop crashing and will be easier to manage.
As some friends on LinkedIn are also moving into business analysis and SOP writing, I thought I’d add a few tips here. While there is some overlap with technical writing, it does require a different mindset, for example, to understand the process flows and narratives that hold the procedure together.
This purpose of this article is to reminds us that our sales, marketing, business, and proposal development do not stand alone. It is all part of a larger process that involves planning, research, writing, editing, proofing, submission and acceptance.
This list gives 37 ways to improve your next set of procedures.
Scroll through it and tell me what I missed.
Show that your procedure is logical and organized
Make the information easy to find.
Include a table of contents for procedures over 10 pages in length
Ensure that your procedure is in compliance with the Security guidelines.
Arrange material in order of priority to the reader
Arrange everything in the order that’s most important to the client
Arrange the procedure in accordance with the user’s requirements
Number pages and sections consecutively; do not re-number each section
Avoid hype, padding and other self-congratulatory drivel. Remember that the proposal is a legal document that becomes part of the contract if you win
By giving specific details and quantifying the benefits whenever possible
Don’t just say that you will comply with a requirement — say how we’ll do so
Use a strong closing statement
Avoid business cliché’s
Avoid hackneyed openings and closings that clients have read a thousand times. Avoid “I would like to take this opportunity to thank you for considering the enclosed . . .” Get to the point: “Here is your proposal.” Avoid “If you have any questions, please feel free to call.” That closing has been done to death, so avoid it and write something more genuine.
Make your procedure easy to understand
Use the same terms and jargon that appear in all SOPs. Don’t try to impress the client with your own special brand of buzzwords or TLA (three-letter acronyms)
A Standard Operating Procedure is a set of instructions having the force of a directive, covering those features of operations that lend themselves to a definite or standardized procedure without loss of effectiveness.
Standard Operating Policies and Procedures can be effective catalysts to drive performance improvement and improve organizational results. Most quality systems are based on its standard operating procedures (SOPs).