A procedure is a “description of a process”. A procedure can take any number of forms, from text to still pictures to an audiovisual demonstration. There is no one correct way to describe a process, except that every procedure should be easy to understand and execute.
Look at any of your organization’s processes. Can you sum up that process in fewer than 30 words?
- What is the input? What materials, information, etc., does one need to begin the process?
- What are you doing to/with every form of input during the process? How do you transform input into output?
- What is the result of the process, also known as the output or the product?
If you could draw a map of the process in question, how simple – or complicated – would it look to the uninitiated?
If you brought in someone from outside who doesn’t know your company’s way of doing things – but has the experience and training needed to perform the process outlined in your procedure – how long would it take them to get up to speed?
If you promoted someone in-house – where, obviously, you believe fairly strongly that they have the necessary training and experience AND they know your company pretty well – how long would it take you to train them using the procedure as the primary training tool?
The problem with most procedures is that they are not developed or written as training tools – at their best, procedures are a means of training and indoctrination. Unfortunately, procedure writers sometimes write to themselves, as if they are the target audience. Compounding that problem, organizations sometimes fail to have their intended audience test and verify procedures before they are approved and released.
Furthermore, three-quarters of the Deming Cycle – the “plan”, “check”, and “act” of the cycle – is left completely out of way too many procedures.
In the vast majority of cases I’ve seen, the procedure writer – and their cohorts in crime – are only telling the document’s audience what to do. That’s what we in quality normally call a “work instruction”.
While work instructions have their place, they aren’t the same as procedures. They typically lack information like:
- Why the intended audience is doing what it’s doing;
- How to monitor and measure the process;
- How to know if the process is yielding the correct results (conforming to requirements, meeting goals, etc.);
- What to do in case of process error, or nonconformity; and/or
- How to prevent – or at least, reduce the likelihood – of nonconformities.
Such information need not – rather, it should not – complicate your procedures. Briefly explain – even give examples – but don’t go into a long-winded philosophical essay.
Remember the KISS principle – keep it simple, stupid.
Thanks for your input. Happy Holidays!
* * * * * * *
Would you like to have one of your procedures evaluated? The first three who contact me by email will receive a free evaluation!