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:Re: QA Techniques in Writing and Production From:Robert Plamondon <robert -at- PLAMONDON -dot- COM> Date:Thu, 27 Feb 1997 22:17:57 PST
M. David Orr writes:
>Using proofreading to correct writing errors is no different than using
>QA inspectors on a manufacturing line to inspect for product defects.
>Correcting a defect is typically much more expensive than doing
>something right the first time. This insight is not my opinion alone,
>but is at the very heart of the Quality Movement.
You can overdo the "tech writing is the same as making hubcaps" analogy.
Creating documents is not an assembly-line process. The end products
are not identical, and many of the subassemblies are not interchangeable:
you can't swap prefaces between two documents without affecting their
function.
Still, I like the analogy when taken to a point that isn't too ridiculous.
(I certainly wave Deming around enough.)
>The real question is "How do we eliminate defects in our writing from
>the very beginning?" Some quality-oriented answers I might suggest are:
>* Screen prospective employees carefully to eliminate sloppy writers
>* Train existing writers in quality principles
>* Train existing writers in writing skills
I'm curious as to how you deal with the first bullet item. Since
outside writers are, by your standards, largely untrained, how do you
screen them? (My temptation would be to hire young hotshots straight
out of school. They're less expensive and have acquired few professional
bad habits.)
>* Use automated standards by means of templates that do virtually all
>formatting through macros, toolbars, wizards, and AutoText
>* Develop in-house stylesheets and train everybody in their use
All very sensible, though surprisingly nonstandard (though I helped put
such a system in place over a decade ago).
>* Create the expectation that copy will be perfect when submitted
Does it work? How much of your copy is perfect when submitted?
>We tried the old copyediting-everything route years ago. If writers know
>there will be a copyedit, many tend to let things ride that they would
>normally fix. We found the quality of first drafts seriously declining
>and costs rising.
Really? I hate having red ink on my copy. Having a copy-editor makes
me LESS likely to write things that the editor will mark up. That's
a common reaction among the other writers I've worked with.
>Now we try to hit drafts right on the mark the first time. I'm not
>saying we don't proof, but we expect not to find much when we do.
Isn't training a wonderful thing? One of these days, it's really going
to catch on.
-- Robert
--
Robert Plamondon, High-Tech Technical Writing, Inc.
36475 Norton Creek Road * Blodgett * Oregon * 97326
robert -at- plamondon -dot- com * (541) 453-5841 * Fax: (541) 453-4139 http://www.pioneer.net/~robertp
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