TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Megan Rock reports a problem: <<...after the SME has signed off on the
manual, engineers from other segments within the company find out that we're
doing the manual and ask to see a copy of it. Then we end up with several
people who want last-minute changes. With 200-300
developers/engineers/technical experts, it can be a challenge to identify
who should review the manual.>>
The trick is to formally institute a peer-review process right at the start
of development. (We do this early in our production process for technical
reports, at two points in the review.) The manager responsible for a product
must ensure that the SME for the project selects a predetermined number of
peer reviewers who are competent (expert!) enough to perform an adequate
review. Three reviewers should be more than enough; this ensures at least
one review even if up to two reviewers are unably to comply, and adding more
reviewers incrementally increases the quality of the review, but not
necessarily enough to justify the additional complexity. (Most peer-reviewed
science journals work in this manner.) At the time the reviewers are
identified, the manager must confirm their ability _and_ their competence to
perform the review, plus their availability and willingness to _do_ the
review. That's not to say that you can't expand the pool of reviewers:
<<We'd have fewer last-minute changes if everybody who thought they should
review the manual had a chance to look at it before we go to production.>>
The crucial first step in this process is identifying the reviewers who
absolutely _must_ review the document; this is typically at least one peer
reviewer, one editorial reviewer, and one manager, but can include more
reviewers. Make sure these people see the document and review it
conscientiously, and the other reviews become less crucial. To include the
possibility of additional reviews, set up an intranet that contains the
current draft of each manual in read-only format so that anyone who wishes
can have a look and provide comments, without modifying the actual document.
Post a clear cutoff date for reviews, and enforce it; people will learn soon
enough that if they want to participate, it's up to them to meet your
deadlines. The product manager or SME in charge of a product (or portion of
a large product) has the responsibility for determining whether technical
changes are worth incorporating, just as the technical writer decides
whether textual changes are merited. Once everyone understands how this
system functions, you combine the benefits of targeted reviews (with the
three peer reviewers identified at the start of the project) and "me too!"
reviews.
"Technical writing... requires understanding the audience, understanding
what activities the user wants to accomplish, and translating the often
idiosyncratic and unplanned design into something that appears to make
sense."--Donald Norman, The Invisible Computer
