|
||
|
|
Save 45% when you buy the CEO Series. It covers the ten core business processes and comes with nine fully-editable manuals for:
|
|
Avoid Poorly Written Procedures
| by Editor |
|
|
|||
| Categories: Writing Policies and Procedures Tags: poorly written, Procedure Writing, Well-Defined Processes | |||||
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 participants, “What is wrong with procedures in your organization?” The things that appear on the list we create are very predictable. They are 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 easiest to solve. Why are there so many problems with accuracy, with poor writing, with consistent formatting and consistent language? The answer to this question can be found by considering who writes procedures in your organization. Too often the task of developing and writing important organizational documentation falls to those who have little experience or training in this area. They may have extensive process and organizational knowledge, but without proper experience or training, this expertise gets translated very poorly into a document. Now consider the fact that the procedure writing tasks are spread around to various non-experts with little or no coordination and direction. What kind of a result do you expect?
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 a key facet to creating or updating procedures that are readable, useable, and accurate. With an expert or expert staff serving as a base for operational documentation like procedures, and using the process owners and experts as a key resource, the result will be a more consistent, professional output.
Figure 1: The Document Team
When we talk about this issue in the Well-Defined Processes class, we lay out what a typical documentation team might look like (See Figure 1). Here we have clearly defined roles, where the Quality Manger oversees the quality 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 on a daily/weekly basis – 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. Proper document control systems can alleviate the issue of procedures not found.
Understanding Roles Leads to Proper Development
For a successful document project, all these 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 can not realistically expect the process expert or process owner to magically transform into a technical writer and expect positive results.
The key is to assemble the right people to document the process, and in particular, do not over look the role of the technical writer. A good technical writer can aid in overcoming many of the issues associated with procedures; poorly written, inconsistent, too long, confusing, and inaccurate. 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 proper process that includes a plan, review, and testing. But those are topics for another day. Next week we will address the other common problem with procedures: not used and not followed.
Related Articles:
This and more articles like this can be found at www.bizmanualz.com. This article may be reprinted freely as long as this resource box is left intact.
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.