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 the design and development process — procedure review.
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 a procedure review, the end product will meet requirements only through luck. Luck being notoriously unreliable, inconsistent, and uncontrollable, you’re clearly better off with a review.
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.
Objectives
Always start with the 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?
Review
Did the technical writer achieve the stated objectives/requirements? (Have a list of the objectives in front of you as you review the document.)
Also, list some important, yet unstated, objectives. For example, correct spelling and good grammar are often taken for granted. Don’t make that mistake. Make up a 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?
Reward
In your review, whether its written or oral, be sure to lead with those aspects of the procedure where objectives were met or exceeded. If critical 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.
Respond
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 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 policy and procedure review 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 document, review it again.
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.
And as one of my favorite sports announcers (Jack Buck) used to say after every broadcast, “Thanks for your time this time. ‘Til next time — so long.”
* * * * *
For more on evaluation, see “The Three R’s of Evaluating“, by David Hobson, DTM (“Toastmasters” magazine, Nov., 2007).
