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.
Subject:doc review process From:DURL <durl -at- BUFFNET -dot- NET> Date:Wed, 14 May 1997 11:31:58 -0400
Good luck, Nancy!
As a consultant, what I've found works best is developing a
Purpose and Users Statement and getting it to the people who will be
reviewing my document before I start to write it. This isn't much help
to you at this point (unless, of course, you did it), but perhaps you can
put such a statement together now.
A Purpose and Users Statement serves two purposes for me: it keeps
me focused, and it provides a relatively neutral basis for reviewing the
material; it helps to avoid arguments that basically go "because I'm the
writer" vs. "because I'm the supervisor." (This, of course, works best if
everyone agrees to the Statement up front.)
A typical P&U stmt for me (usually I deliver it in a memo form,
asking people to let me know if I misunderstood their objective) includes:
* the purpose of the document: training new employees?
standardizing procedures? developing a disciplinary standard? reducing
time required to complete tasks? reference manual? getting buy-in to
organizational changes?
* users: new employees? employees with one year of experience?
technical experts? non-technical people? direct employees locally? global
contractors?
By sending it out as a memo, I can refer to the memo of whenever
"that we all reviewed" as my reason for what I put in or left out.
Then, when people review the document, we can look at the P&U stmt
and decide together if particular material (a) fits the guidelines or (b)
if the guidelines
should be revised, along with any implications for revising the whole
document.
I'm also pretty frank about editing changes: I ask people to focus
on their area of expertise, not on punctuation, although I'm always glad
if people find typos or goofs. Once again, tho, I rely on whatever
authority I've used (say, Chicago manual for non-engineering
documents), as the authority--I try to cite somebody other than myself as
the reason for, say, a serial comma. Of course, I always try to find
authorities who agree with me! ;)
Mary Durlak
Erie Documentation Inc.
East Aurora, NY
TECHWR-L (Technical Communication) List Information: To send a message
to 2500+ readers, e-mail to TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU -dot- Send commands
to LISTSERV -at- LISTSERV -dot- OKSTATE -dot- EDU (e.g. HELP or SIGNOFF TECHWR-L).
Search the archives at http://www.documentation.com/ or search and
browse the archives at http://listserv.okstate.edu/archives/techwr-l.html