How to Write and Test Procedures
by Tamara Martfeld
I am sure that everyone at one time or other has been frustrated by poorly written “procedures”. Frequently “procedures” are simply a step-by-step list of what needs done to complete the job. This is fine if you know what those steps mean. They can serve as a reminder to make sure everything is done once you know how to do the job or if the job is very simple and there is no detail to add. However, a step-by-step list is frequently meaningless for more involved processes. The absolute best instructions are those which enable a person to teach themselves the job.
A good test of any procedure is whether the job can be done if those who know how to do it are suddenly gone. As we want to always focus on the positive on this site we will consider the possibility of a group lotto ticket winning with a prize big enough to enable everyone to retire. Everyone walks out the door. Can the new employees learn to do the job from your procedures?
To write the absolute best procedures assume your audience has absolutely no knowledge of the task and only general basic knowledge of the equipment, and if a computer program or something similar, a beginners knowledge. For example, when writing procedures in the 1980’s it was a good idea to tell the audience how to turn on the computer – what the button looked like and where to find it. At that time computers were fairly new and not everyone had exposure to them or experience with them. Now a procedure can state to turn on a computer without explanation or simply assume that the audience knows to turn it on.
Begin writing the procedure by getting the basic step-by-step process on paper. Next complete the procedure doing only what is written and fill in the detail. For example, if the procedure states to copy from a report what do you do to get the report? Where is it? Do you generate it? Many times it is assumed that one knows all this information. Even if the knowledge exists within the unit, write it down. Your goal is to be able to hand the procedure to a person off the street who has no knowledge of your work and have them train themselves without having to ask questions.
Because you may not know your entire audience, write the procedure to the general public. I generally try to write my procedures as if I am addressing a fourth-grader. It is never really that simple – I doubt an average fourth-grader could be fully competent in a process due to my procedures. However, with that audience in mind higher-level vocabulary words are reduced, jargon is less likely to be used, and every acronym is spelled out when it is first used. Avoiding jargon and acronyms in a procedure is ideal, but sometimes they cannot be realistically avoided. In some situations a procedure is used in audits. An outside auditor is not likely to know internal processes and you want the procedure easy enough to understand to make any auditors happy. If you are in a situation full of jargons which must be used, I strongly suggest a dictionary as an appendix to the procedure.
Once in a while a step is needed which makes no sense unless you have the background knowledge or have already completed the process. For example, on a procedure I currently have a query is run and the result is exported into Excel and then copied to a tab of another Excel spreadsheet to enable the query results to automatically update a master list. Another part of the process requires the master list being used before it is updated. Within the procedure I instruct that the part of the process needing the master list before it is updated be complete prior to copying the query results to the master list. I then explain why it is done that way – that the information will be incorrect for the secondary process. (I discovered this when testing the procedure – more about that later.) The procedure I am working on is very involved and it is intuitive to update the master list first, but there is a good reason for not doing so.
In the above case the process has a special consideration requiring an explanation. Sometimes it is the computer program. For those of us who are not computer geniuses (and maybe for some who are), many computer programs are not intuitive or have quirks which one needs to work around. There can also be steps which seem like they can be eliminated but which are there for a reason which is not obvious, legally required, or just a precaution. It is generally a good idea to explain anything not obvious. One example of a precaution is to require two people to sign checks over a given amount. To a young person without a criminal mind such a step might be considered stupid. One more enlightened knows it protects both individuals from suspicion of underhanded dealings and protects the company from fraud. Yes, nothing is perfect, but such procedures exist for a reason. By explaining why something is happening you reduce the possibility of the step being skipped or eliminated without knowledge of why it existed in the first place. It is especially important to indicate that something is being done because it is the law. Such explanations can be footnoted or placed in parenthesis to make reading the procedure easier, but they should be included.
If the procedure is involving a computer program assume the person has only basic knowledge of that program if it is a common program and no knowledge if it is not common. Most computer programs written now are very powerful and have functions only a few people will ever use. Additionally, training is expensive and many users teach themselves the functions as needed. Step-by-step instructions will make the procedure better. For example, back the 1980’s you would have stated how to save a file, not just stated “save file”. Screenshots within a procedure are very helpful. If a formula is used in a spreadsheet, explain the formula even if it may rarely need updating. If it does not need to be updated on a regular basis the explanation can be in an appendix.
Once you think you have the procedure complete with detail, perform the task doing only what is in the procedure. This is testing the procedure (the first time you did this was to fill in the detail). Adjust the procedure every time you find you are doing something not written down. Once you think is it “perfect”, wait a few weeks and test the procedure again. The more important the task, the more important for it to be tested well. Remember that even experts don’t always get it right. Emergency crews have drills all the time and then emergencies happen and they find something they missed. They then revamp the procedures to address what was missed and run through more drills. Improvements are made all the time. Consider how well emergencies are handled now as compared to 50 years ago.
If it is possible, once you think your procedure is complete have someone who knows nothing about it perform the process using the procedures. Ask them to note any questions they have or areas needing better detail. Adjust if necessary.
By now you should have a procedure which can be considered “absolute best”. Now you can write a check list step-by-step process containing less detail if you desire. That first list you made may have not had all the critical steps needed. Now you have all the critical steps and can eliminate the detail. This check list would be for use by someone once they know how to do the job.
Now you have the tools to write a comprehensive desk manual for your desk. When there are step-by-step procedures in place you can go after those promotions. A common excuse for not promoting given individuals is that “no one else knows how to do the job”. Your desk manual can eliminate that excuse – now anyone can train themselves to do your job. If you enjoy writing procedures you can show your product to your boss and offer to write procedures for processes you do not now know. This would be a good way to learn more functions and be more valuable to your company.
Have a wonderful and successful month!