|
Receive Free Weekly Information
Regarding Products, Services,
Specials, & Free Offers
Thru the Web Site!
|
Today's Article is An Excerpt From The Weekly Edition's
Weekly Ask the Editor Column.
 Need Results? Advertise With Us!
We Offer Subscribers Articles, Info, Free
Weekly Ads, & Bonus Items With Subscription.
Click Thru for Subscription Details!
Title: Writing Procedures for Results
Written By: Chris Anderson
Web Site: http://www.BizManualz.com
© 2005 Chris Anderson
So, you have been tasked to write a procedure, but where do you start? I like to break the process into four parts: Discovery, Design, Development, and Deployment. Now let's see how these work together to write the procedure for you.
Procedure Discovery
Discovery means understanding the problem, the system the procedure interfaces with, and the requirements imposed on the process that the procedure describes. A procedure is needed to describe one or more steps to a business process. So, before we start writing the procedure, we need to discover what is expected from the procedure and or the process.
Every process consists of a supplier, the transforming process, customer, and customer's customers. During discovery we need to understand:
- Who are the suppliers and what do they supply to the process?
- What are the inputs and what outputs are they transformed into?
- Who are the customers and what do they receive from the process?
- Who are the customer's customers and what does the customer provide to them?
- What are the effectiveness criteria or how do we know if the process is working correctly?
- What corrective action is taken when the process does not work correctly?
Of course there are a lot more questions we can ask regarding compliance, process control, input and output inspection, etc., but the main idea is to understand the flow of information, what happens, and why. With this information in hand we are ready to begin designing the procedure.
Procedure Design
The design phase is really where we need to spend our time if you want to develop a really good procedure. Given the discovery information you should create a process map showing the steps to the process and what inputs and outputs are produced along the way.
A process map will help us communicate our design and collect feedback before we write out the procedure's text.
I like to use a process flow diagram.
Process Flow Diagram for a Meeting
Format: (Supplier) Input --> Process --> Output (Customer)
Step 1: Topic --> Organize Meeting --> Agenda, Attendees
Step 2: Materials --> Meeting --> Minutes, Action Items
Step 3: All Outputs --> Review --> CAPA*
(*CAPA is Corrective Action / Preventative Action)
The text diagram provides an example of a procedure for holding a meeting. On the left are the inputs, on the right are the outputs, and in the middle are the process steps. Notice that for each process step the specific inputs and outputs are listed. You can also list the suppliers and customers for each to make a more complete diagram.
The last step in design is to perform a design review or walk-through of the draft procedure before we document it in writing. The Process Flow Diagram is sufficient to review the design. Check each input, output, and procedure step to ensure we have not forgotten anything.
Plan Do Check Act (PDCA)
We use PDCA to review the procedure. It's an acronym for Plan Do Check Act and one of the review criteria is to verify that the procedure exhibits the PDCA structure of process approach. A good ISO 9000 procedure would use the process approach for continuous improvement. In this case, the procedure has only three steps. Organize Meeting (Plan), Conduct Meeting (Do), Review Meeting (Check/Act), and the Corrective Action / Preventative Action (CAPA) output represents the Act part.
So, it appears that our Meeting Process Flow Diagram demonstrates the PDCA structure, is complete and passes the review. With our basic design in place we are ready to begin development and write out the procedure right?
Almost, the important question to answer in development is who are the users of the procedure going to be: novices, occasional users, or frequent users? You can write the procedure for all three or determine that only a certain group is going to use it. The editorial style is different for each.
Procedures for Frequent Users
Frequent users are expected to be experienced. They do not require a lot of explanation, technical definitions or detailed step-by-step instructions. Frequent users may only need a checklist. They will skim the procedure and rely on the headlines for each major task to skip through. Therefore, the headlines, sub-heads, and checklists are the most important point for the frequent users. The priority is navigation more than explanation.
Procedures for Occasional Users
Occasional users are not experienced. They may only use the procedure now and then, when they fill-in for someone or perhaps the procedure is only used once a month. So, the occasional user needs what the frequent user needs but they also may require explanation or a reminder as to how and why this step is done. Therefore, explanations are important to the occasional user. The priority is explanation and navigation over detailed step-by-step instructions.
Procedures for Novices
Novices are learning the procedure for the first time and need step-by-step instructions. We sometimes call these work instructions and compose them as a separate document referenced from within the procedure.
The reason is obvious; you don't want to overload the procedure with a lot of detailed instructions that may only be used by a novice once in a long while. Therefore, detailed work instructions are important to the novice. The priority is learning the procedure and transforming the novice into an occasional user.
Are you done? Not yet, you need to perform a review of the written procedure. You can use the seven C's to review and check a procedure for Context, Consistency, Completeness, Control, Compliance, Correctness, and Clarity. After the document review you are ready to deploy the procedure into the field.
Procedure Deployment
Deployment refers to the training, auditing, and continuous improvement of the procedure. After all, if the procedure is not used then why did you write it in the first place? Training is the first step; the users need to be introduced to the procedure and how it is used. Most procedures have a form, checklist, or log of some kind that embodies the procedure. The users need to be introduced to what the inputs and outputs are and how they will be audited for conformance.
Procedure Auditing
Why do we audit procedures? First, to see if they are used, but more importantly, it's to see if data is collected, used and changes are occurring to the process (via revisions to the procedure) demonstrating the process is in control. Remember control was one of our previous topics.
Writing Procedures for Results
By now you should understand how to write a new procedure for results. You start using the processes four parts: Discovery, Design, Development, and Deployment. In discovery, our main goal is to understand the flow of information which, in turn, will tell you what is expected from the procedure or the process. In the design phase, you create a process map which shows the steps, inputs, and outputs of the process. A design review or procedure walk-through prior to development ensures that the procedure is accurate and can be used effectively. Prior to development you answer the question: Who Are Procedures Written For?
Procedures are written for various user-groups: frequent users, occasional users, or novices, in order for them to consistently realize the process that the procedure models. Procedures are written for various user-groups: frequent users, occasional users, or novices, in order for them to consistently realize the process that the procedure models. Procedures are written for auditors to verify to management that the processes are in control. And, procedures are written for the company to ensure that the company is continuously improving, realizing the business objectives, and increasing its future prospects.
And finally, you deploy the process using training, auditing, and continuous improvement for the life of the process. Sounds easy but producing a good procedure takes more thought than action. Spending more time in design and less time in development will produce an easier deployment.
You can always learn more about developing policies, procedures, and processes, or improving your organization by attending the next how to create well-defined processes or ISO 9000 Lead Auditor training class.
About the Author
Chris Anderson is founder and CEO of Bizmanualz (http://www.bizmanualz.com), Inc. Since 1995, Bizmanualz.com has specialized in empowering organizations to consistently produce results. Management Systems help is available via consulting, training, and prewritten policies and procedures for a wide variety of industries.
The author has given full permission to publish today's article either electronically or in print, free of charge, in its entirety, as long as the article content remains unchanged as is published here today, and that the authors copyright with resource box are included.
|
Privacy/Guarantee Policy
© 2000 - 2005 DocumentsCentral.com All Rights Reserved
|
|
