One of the most common mistakes I see is organizations that write procedures to meet an ISO 9001 requirement prior to implementing the process to meet the requirement. There is a widespread belief that if a procedure is written, then it will be followed. Much like the 1989 movie, Field of Dreams, this is fantasy. The movie tag line is “If you build it, he will come.” And while that is a perfectly acceptable belief for a movie in the fantasy genre, it is a ridiculous notion for an organization to believe that if they write procedures, then employees will follow them.
So how should an organization go about documenting their processes in procedures? First, determine which procedures are needed. Procedures require a lot of resources to keep them current and properly distributed and to ensure obsolete versions are inaccessible. So, before using your limited resources to write one, make sure you need it.
Get a team involved to map out the process. This does not need to be some long-standing committee that meets regularly to argue out details of the process. Involve
- the process owner (individual with the greatest stake in the process),
- someone who routinely does the process,
- an internal customer of the output of the process, and
- someone who knows nothing about the process.
“The purpose of this procedure is to describe the process for internal audits.”
That is circular thinking and pure drivel.
State the purpose of internal auditing (not the purpose of having an internal auditing procedure). The purpose of auditing is to ensure the organization is maintaining its quality management system in accordance with ISO 9001 (or other standard), customer requirements, internal requirements, and statutory and regulatory requirements, as applicable.
Next, describe the scope of the process. Internal auditing typically includes all of the QMS processes (and may exclude HR, safety, and/or financial systems). Make sure it is clear what elements, areas, or processes are included and/or excluded from the scope of the process.
Then, using the team, map out the process. Determine the key steps first. Add detail as necessary. Determine who does what and when (how often) and how the relevant information will be communicated. Draft the process as a flowchart, process map, or other conceptual way. Then before committing those steps to a procedure, DO THEM. Practice. It is incredibly unlikely that the process will work out the way it is originally designed. Walk through it a few times and call the team back together. Talk about what went as expected and what did not. Revamp the process map. Test drive it again; make adjustments. When the process is functional, make sure the procedure is written to describe how it actually works (not how you originally dreamed it would work). Make sure everyone involved is in agreement. Provide training upon release and revision.
Lastly, write a high-level summary for the Responsibilities and Authorities that is simply a (brief!) summary of the tasks defined in the process map. This will also show who will need to be in the loop any time the process and procedure are revised, corrected, or improved.
Which comes first – the process or the procedure? The process should come first and the procedure should reflect the process after the bugs have been worked out. Writing the procedure first and hoping it will be followed is a leading reason of why so many procedures are works of fiction.
I've heard from a number of people who have told me that the Field of Dreams quote is "If you build it, they will come." Accuracy is important. (Misquoting it would have made it a better quote for my blog, but it seemed disingenuous.) At no time in the movie does any character say, "If you build it, they will come." (And Kevin Costner looks really young.)