How to Review Business Policies
Many problems with procedures that crop up after they’ve been implemented are traceable to inadequate or no policy review process. Let’s say a procedure as written describes an deal process, performed under ideal conditions (i.e., real-world conditions aren’t taken into account). If this isn’t caught in the policy review process, the end product will meet requirements only through luck. Luck being notoriously unreliable, inconsistent, and uncontrollable, you’re clearly better off if you review business policies. Learn how to Review Business Policies.
An Effective Process to Review Business Policies
Very little is said about an important part of policy and procedure design and development — the policy review process. Why do you review anything? To ensure the accuracy and completeness of whatever it is you’re reviewing and to make sure everyone has the same understanding of the policy, process, or situation. In short, to ensure effective communication, which will lead you to the desired outcome.
Effective communication is a big reason why the international quality standard, ISO 9001, mandates design and development controls (clause 8.3.4). If you don’t review, you risk missing any number of product requirements, both stated and unstated, and you risk losing customers.
Need another reason to review policies and procedures? No one is perfect and no process is perfect. No one will write the perfect procedure the first time, every time. Furthermore, no one can multitask. Your technical writer wears several other hats, right? That person is bound to temporarily lose focus on the policy or procedure they’re writing when other projects and other managers are continually demanding that their stuff is mission critical, “…so drop everything and work on this.” (Now, where was I?)
We all agree, then, that policies and procedures have to be reviewed, right? So, how’s it done? Well, one method that works is based on speech evaluations as done by Toastmasters. For a Toastmaster, learning how to evaluate a speech – or a written document – is as critical as learning how to give a speech or write one.
Policy Review Objectives
With the policy review process, start with objectives or requirements. Were they clearly communicated to the technical writer? Did he/she understand them? Do you? Were the objectives prioritized and categorized? Were they SMART objectives?
Policy Achieved?
Did the technical writer achieve the stated policy objectives/requirements? (Have a list of the objectives in front of you as you review the document.) Also, list some important, yet unstated, review objectives. For example, correct spelling and good grammar are often taken for granted. Don’t make that mistake. Make up a Seven C’s checklist for often overlooked items, like “Are important terms defined?” and “Is ‘active voice’ used?”
Did the tech writer go beyond the stated objectives? For example:
The procedure mentions a packaging machine that a first-time reader may not be familiar with. The tech writer includes a long shot (photo) of the machine and a closeup of the control panel. The pictures aren’t a requirement; furthermore, they (and additional photos) push the document beyond the stated requirement of “six pages, maximum”.
Which is the SMARTer objective, user understanding or document length?
Policy Review Feedback
During the policy cycle, review processes and be sure to lead with those aspects of the procedure where objectives were met or exceeded. If critical procedure review objectives were not, consider possible explanations for that (the writer’s level of experience, competing projects, the amount of information provided them, clarity of the objectives, etc.).
The point is not to let the writer “off the hook” (or to find a hook to hang them on). It’s about encouraging the writer – praising what they did well and asking them to do better. Tell them, “Here’s what you did well.” It is important to provide policy review feedback to the writer.
Don’t be vague or insincere, either. Don’t fish for compliments — you’re not helping them by telling them that their capitalization was great, or they had all the commas in the right places. Be truthful, be specific, and give them something to build on.
Procedure Flow
Tell the writer exactly what you see in the procedure (ex., will the reader know who’s supposed to do what, when, and why?) Restate the review objectives and indicate which were met, which were exceeded, and which weren’t met. Use a numeric scale in your review (rarely is anything “black or white”).
Beyond that, does the procedure “flow”? Did they use the PDCA model correctly? Did she or he use words, voice, style, grammar, etc., effectively? Does the story – and the message – come across clearly? Tell them what they did well and point out specific opportunities for improvement. Hand the document back to them with another objective: you need the revision back for a “final” review by a specific date.
After you’ve reviewed the document, the writer will probably have to make some changes. After the writer has revised the policy procedure document, review it again for errors. Don’t review it to death, however. Four or more reviews of the same document should tell you that the review process has broken down…somewhere. It might be time – at least temporarily – to bring in another pair of eyes.
As a reviewer, you’re obliged to:
- Be sure that stated and unstated objectives were met;
- Be fair;
- Be consistent;
- Be thorough; and
- Point out strengths and opportunities for improvement in the document and in the process.
Review Business Policies
Now you can reduce problems with procedures that crop up after they’ve been implemented using an adequate policy review. Remember that the policy review process is an integral part of the design and development process of writing policies and procedures.
Nice write up.
I have been following your post for more than a year now, one point I noted was the model you frequently used on your procedures write-up. This model is the PDCA. From my experience, this model best work on Quality control Procedures. Is there no other models that suit both quality control process and other management process?
Also, the write up is an academic base not a practical base because, I could not sight samples on objective assessment, faulty flows, etc. Where this sample intentionally kept silent with a purpose?
PDCA is THE MODEL. It is used as the learning loop in education, the scientific method in science, and as a best practice in managing processes — any process not just quality. I am not sure what your second question was regarding “samples on objective assessment”, perhaps you could clarify.