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.
Sara Hassen reports: <<I am trying to develop a document review process
for my division. I am the lone Technical Writer within a group of
scientists (Ph.D. level). It is the common assumption that every
document I produce should be 100% error free. This of course is a
daunting task.>>
It's an impossible task, and thus an unreasonable one. You might point
out to your PhD's that if this were possible even for their superior
intellects (let alone our humble editorial minds <g>), science journals
would not require a peer-review process, and even if they did, they
would always have their manuscripts accepted on the first try, with no
revisions required.
They'll get the message.
<<I strive to maintain accuracy, but without a review process, the
errors are unnoticed until the document is utilized.>>
Who is utilizing the documents? These people should clearly be enlisted
in your review process. Traditionally (I've been doing this for nearly
20 years for a variety of employers and for more international research
journals than I can count), editors do a preliminary review of the
documents to clean them up, the documents undergo peer review to detect
any technical errors, then the editor does a final pass to catch any
errors introduced during revision. That's the minimum.
<<I proof all my documents twice prior to release, but this is
obviously not adequate.>>
For what it's worth, no human ever gets the job done perfectly the
first time. Standard editorial practice is _at least_ two passes
through manuscript, ideally separated by at least one day. Most of us
strive for an additional pass if we have time and energy.
If you're finding that you repeatedly make specific kinds of mistake,
budget an hour every week (at home, if necessary) to focus on
understanding the problem. For each new manuscript that you edit, make
a separate pass through the manuscript looking exclusively for that
problem and ignoring all others. After a couple weeks of this, you'll
find that you have internalized the process of spotting this particular
type of problem and can move on to learning to recognize another
problem.
Also, if you're not already doing onscreen editing (e.g., revision
tracking in Word), start doing so. The various tools that a good word
processor provides can greatly increase both your editing speed and
your accuracy. If you have access to STC publications, have a look at
my quarterly column in _Intercom_) magazine on onscreen editing (which
began appearing back in 2000 or thereabouts). Lots of helpful tips (or
so my readers claim) to teach you the art of onscreen editing.
<<This brings me to the conclusion that a formal review process needs
to be implemented.>>
This is standard, and should come as a surprise to nobody.
<<My question to you is this, how many reviews do your documents
undergo prior to being released for use? Also, who are the people who
review the documents, end-users, fellow writers?>>
Here's one common approach (which I've seen used in both government and
private-sector organizations): editorial review of first draft,
research director (RD) or managerial review, peer (SME) review or
"external" review by people outside your organization, second editorial
review, desktop publishing, final editorial review (proofreading). The
RD and SME reviews may be reversed in order, or may be simultaneous.
There may be no second editorial review if you're publishing your own
materials, in which case your last chance comes after layout. There may
be no final review (proofreading) if a journal or other publisher will
be publishing your materials, or you may be sent proofs to review.
When I do freelance science editing, I only get one kick at the can, so
except when I have an unusually tight deadline, I usually edit on day
1, set it aside, then re-edit on day 2 or 3. This catches enormously
more errors than trying to do everything all on the same day. It's not
just me, by the way; the vast majority of my editorial colleagues
report the same results.
<<I am at my wits end trying to articulate the need for document review
PRIOR to release.>>
All your PhDs will be intimately familiar with the review process that
occurs prior to a thesis defence, and those that publish in research
journals will be equally familiar with the peer-review process. It
should not be hard to convince them of the need for reviews.
WEBWORKS FINALDRAFT - EDIT AND REVIEW, REDEFINED
Accelerate the document lifecycle with full online discussions and unique feedback-management capabilities. Unlimited, efficient reviews for Word
and FrameMaker authors. Live, online demo: http://www.webworks.com/techwr-l
Doc-To-Help 7.5 Professional: New version with new features, improved performance and reliability, plus much more! Download your free trial today at www.componentone.com/techwrlfeb.
---
You are currently subscribed to techwr-l as:
archiver -at- techwr-l -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- techwr-l -dot- com
Send administrative questions to lisa -at- techwr-l -dot- com -dot- Visit http://www.techwr-l.com/techwhirl/ for more resources and info.
