Keys to Avoiding Poorly Written Procedures
| by Editor |
During our Well-Defined Processes course we spend a significant amount of time talking about procedures. The role of procedures in documenting processes as well as positive and negative attributes of procedures.
At the very beginning of the course, we ask the participants, “What is wrong with procedures in your organization?” The things that appear on the list are predictable. They include:
- Hard to find,
- Hard to read,
- Not used,
- Not followed,
- Too long,
- Poorly written,
- Poorly formatted,
- Out of date, and
- Not accurate.
Wow! That’s a lot of baggage!
Two Categories of Procedure Problems
As we go through our discussion on processes and procedures, we discuss possible solutions to these problems. Some solutions are easier than others. We can actually divide this long list of issues into two broad categories:
- Writing/development issues; and
- Implementation/integration issues.
Writing and development issues are the first we’ll tackle. Why are there so many problems with accuracy, poor writing, and consistent formatting and language? The answer to this question can be found by considering who writes procedures: too often the task of developing and writing important organizational documents falls to those who have little experience or training in process documentation. Documenting business processes is a much different kind of writing from any other.
They may have extensive process and organizational knowledge, but without proper experience or training, these writers often do a poor job of translating their expertise. Now consider that procedure writing is usually spread across a number of non-experts who are given little or no coordination and direction. What kind of a result would you expect from this crew?
Would You Hire A Plumber to Do Your Wiring?
Hiring or developing a central internal resource with expertise in technical writing and/or developing procedures is key to creating or updating procedures that are readable, useable, and accurate. With an expert individual or a staff in charge of developing operational documentation (like procedures), and process owners and experts as key resources, the result is a more consistent, useful, and professional-looking document.
When we talk about this issue in the Well-Defined Processes class, we lay out what a typical documentation team might look like (Figure 1).
Figure 1: The Document Team
Here we have clearly defined roles, where the Quality Manger oversees the quality management system, of which documents like procedures are an important element.
Process owners are typically department heads or managers, who are ultimately responsible for ensuring processes are carried out in ways that meet organizational requirements. The technical writer works closely with the process owner and those who have the ultimate process expertise — the ones responsible for carrying out the process — to properly document the process.
The final piece of the puzzle is the person responsible for managing the document system, such as release and control. Properly implemented document management systems can remedy the “procedure not found” issue.
Understanding Roles Leads to Proper Development
For a document project to be a success, all roles must be filled by qualified personnel. While some roles may overlap, and some may even be filled by the same person, it is important that all the various roles and associated tasks are recognized. You cannot realistically expect the process expert or process owner to magically transform into a technical writer and give you consistently outstanding results.
The key is to assemble the right people to document the process; in particular, do not overlook the role of the technical writer. A good technical writer can help you overcome many of the issues associated with procedures; poor writing, confusion, inaccuracy, procedural inconsistencies, and excessive length.
If your organization is too small to support a full-time technical writer, then other options are to develop a relationship with a freelance or contract writer or to properly develop skills internally though training, education, review, and feedback. While a good technical writer is central to creating good procedures, other elements are important as well, such as a well-defined process that includes a plan, review, and testing.
Next week, we’ll address the other common problem with procedures: not used or not followed.
Categories:
Writing Policies and Procedures
Tags:
business processes • document management • documented procedures • poorly written • Procedure Writing • Process Control • process design • Quality Management System • Well-Defined Processes
Related Articles:
Originally published in 2008 by Bizmanualz, Inc. under the title Keys to Avoiding Poorly Written Procedures. All rights reserved. Reproduction permitted with attribution only. www.bizmanualz.com
September 30th, 2008 at 9:04 am
Chris,
As a matter of interest, I was hired by my company (as small paint company of 56 over three plants) in 1996 to develop, implement and maintain QS 9000. I had no experience, but I came cheap and they got an English/Education degree with me. I was a quick study. My first and major job was to write the 21 Operating Procedures. As a dept. of one, I observed the processes I had to document and interviewed the operators. I took copious notes and converted these into the Operating Procedures. I gave them to the appropriate Dept. Heads and operators to review and revise. I revised these documents and then audited them against the corresponding activities. If they passed muster, I entered them into doc. and data control. Work Instructions were generally written by those that performed the procedures then I would spot audit the WI’s, clean them up, and enter them into the QMS. These documents were used, especially the WI’s. as they proved to be excellent training tools.
When we switched to ISO 9001:2000, we maintained our documentation process as they were working for us. We now have 20 sections instead of 6. In the transition, we realized that some of our OP’s were as long as 9 pages which we realized made no sense. Most of our OP’s were made up of a series of mini WI’s. I broke down these OP’s into realistc OP’s and made WI’s out of the main body of those OP’s. Talk about simplification! This process revolutionized our documentation process.
I also went one step farther. I made our entire documentation system paperless. OP’s and WI’s are stored in read only files on the server making them accessible throughout the organization, even the plant. Everyone has a computer. I wrote databases for Doc. and Data Control Processes, Corrective Actions, Non-conforming Products and Returned Goods, Internal Audits as well as a majority of our metrics. In the end, I threw away about 15 manuals. The only ones left will disappear through attrition as their retention times are exceeded (next year). The only manual which will remain is the Quality Manual as I feel it is important to be able hand it to appropriate individuals rather than having them stare at a computer monitor.
Why all this? Simple, it proves that all you have been saying these past weeks works even for a quality dept. of one. Thinking about it, I guess I did have teams which changed as the document requirements changed.
(See Quality Progress, September 2001, p.73 – “QS-9000 for a Small Paint Company”. It’s in the ASQ Website archives, I think. You may try a search for “Andrew M. Brody”.)
November 25th, 2008 at 11:11 am
We appreciate your feedback and input, Andrew. Sounds like you are doing a great job implementing a lean ISO system.
March 31st, 2009 at 1:50 am
I work for a water purification organisation in Durban,SA. our main customers are the eThekwini Municipality who purchase 85% of the processed water. I want to find out
“How do we satisfy our customer” (eThekwini Municipality ) as it is only water and can we get “customer feedback” to know that we are doing a good job?
We want to improve our service to eThekwini and want to know our short-comings to improve.
Regards
T.MOODLEY
April 7th, 2009 at 1:51 pm
Tony:
There are no simple answers to the questions you ask. But we just posted an article on this topic that you might find helpful.
http://www.bizmanualz.com/information/2009/04/06/the-voice-of-the-customer-is-the-sound-of-success.html
April 9th, 2009 at 10:12 pm
Most companies start with surveys of their customers. But voice of the customer work goes beyond surveys to capturing all sorts of feedback like customer comments, individual interviews or focus groups to capture real conversations about how the customer uses your product. Sure it’s water but, what is the water used for? Drinking, cooking, farming, chemical processing, manufacturing, etc. There are a lot of uses for water and each one may provide you with insight into measures for customer satisfaction. Metrics for taste, mineral content, water pressure, volume, or maybe additives like fluoride, corrosion and scale control, or microbiological control. Of course you can also consider waste water treatment, infrastructure support, or growth issues that may constrain future water usage. As a consumer I like my water clean, plentiful, and cheap with no minerals that scale or corrode my plumbing. That’s my two cents.