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: technical writing efficiency From:Steven Jong <SteveFJong -at- AOL -dot- COM> Date:Sat, 6 Feb 1999 13:21:16 EST
Dan Brinegar, commenting on measuring page output, wrote:
>> Can the customers use the docs to help them get useful work done?
>> *Do* they use the docs?
>> Did the docs arrive in approximate concurrence with the version
>> they're purported to support?
>> Almost anything else is a red herring 8-)
I think this confuses the issue. A document is the product of a process.
The document (the product) and the process by which it was created
(the writing) are separate, and can be measured separately. Metrics
pertinent to one don't necessarily apply to the other.
If the question is "what is the quality of the product (the book)?"
then considering effectiveness is appropriate, while measuring pages
probably is not. (I would suggest that a 500-page quick-reference guide,
or a 5-page programming language reference,
won't be effective no matter how brilliantly they're executed;
but in general page counts correlate weakly to effectiveness.)
If the question is "what is the quality of the process?" then yes, page counts
are an important metric. I note that the subject line is
"technical writing efficiency." This is a legitimate management concern.
(Imagine that you're the manager of the writing group. Do you have enough
staff? How do you know?)
Even Dan's second point (do the documents arrive concurrently
with the software?) is a process question. If your documents
consistency lag behind the software, there's a problem that
needs to be addressed. Maybe the problem is writer inefficiency.
How would you determine it? What constitutes good efficiency?
Right away you're into measurement.
(Industry-wide, the problem of late documentation is caused
less by writer inefficiency and more by late or changed engineering
specs, but you need to measure your own processes to say for sure.)
-- Steve
=========|=========|=========|=========|=========|=========|=====
Steven Jong, Documentation Group Manager ("Typo? What tpyo?")
Lightbridge, Inc., 67 South Bedford St., Burlington, MA 01803 USA mailto:jong -at- lightbridge -dot- com -dot- nospam 781.359.4902 [voice]
Home Sweet Homepage: http://members.aol.com/SteveFJong
