How to Review Business Policies

Much has been made of procedure writing, both here at Bizmanualz and around the Internet, but very little is said about an equally important part of design and development — the policy review process. 

Many problems with procedures that crop up after they’ve been implemented are traceable to inadequate or no review.

Let’s say a procedure as written describes an ideal 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.

An Effective Process to Review Business Policies

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 reviews (clause 7.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 — 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

In your policy review process, whether its written or oral, 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.”

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.

Remember that the policy review process is an integral part of a design and development process. 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.