Writing Procedures for Results !

Part 2 of a Four-Part Series

Part 1: How to Write Procedures to Increase Control?
Part 2: Writing Procedures for Results
Part 3: Who are Procedures Written for?
Part 4: What’s the Difference Between Policies and Procedures?

Last week we talked about writing procedures to increase control. This week we’re talking about writing for results.

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.

Our process diagram to the right depicts a typical process consisting of a supplier, process, customer, and the customer’s customer. During discovery we need to understand:

1. Who are the suppliers and what do they supply to the process?
2. What are the inputs and what outputs are they transformed into?
3. Who are the customers and what do they receive from the process?
4. Who are the customer’s customers and what does the customer provide to them?
5. What are the effectiveness criteria or how do we know if the process is working correctly?
6. 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.

Figure 2 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. Figure 2. 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 or 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 CAPA (Corrective Action / Preventative Action) output represents the Act part.

So, it appears that Figure 2 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.

But first, we need to answer who are the users of the procedures going to be? We will talk about procedure development and deployment next week.

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

Sphere: Related Content

Add to your favorite RSS readers
			Others
Let others know
		EMail This Post

Posted on Wednesday, April 13th, 2005 under Writing Policies and Procedures