How to Write Procedures 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 to write procedures for results and how they apply to different procedure users.

Write Procedures For Results

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.

Figure 1. Process Diagram

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 starting to write procedures for results and are ready to begin designing the procedure.

Procedure Design

Figure 2. 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.

New Release of “How to Write a Policies and Procedures Manual” is now available.

Plan-Do-Check-Act (PDCA)

We use PDCA (for “plan-do-check-act”) to review the procedure. One of the review criteria is to verify that the procedure exhibits the PDCA structure, or the process approach. A good ISO 9001 procedure will use the process approach for continuous improvement. In the example above, the procedure has only three steps. Organize Meeting (Plan), Conduct Meeting (Do), Review Meeting (Check/Act), and the CAPA (Corrective Action/Preventive 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 to write procedures for results.

3 Types of Procedure 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. The Vendor Selection Procedure is an example of a written procedure.

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

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

3. 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 and Auditing

Deployment refers to the training, auditing, and continuous improvement of the procedure. After all, did you successfully write procedures for results if the procedure is not used? 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.

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 that the process is in control.

Who Are Procedures Written For?

By now you should be able to answer this question. 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.