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.
No matter what method you devise, the best is simple accounting. What saves
the company money. Reduced costs while keeping the customer happy.
Jon Leer
----------
> From: Michael Johnson <michaelj -at- OECMED -dot- COM>
> To: TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU
> Subject: Re: Productivity Measurements
> Date: Monday, February 02, 1998 10:39 PM
>
> Earlier today Tony Rocco asked us how to measure tech writer =
> productivity. =20
>
> I wish I had a good answer to this one. After 20 years in the business =
> I have seen just about every kind of measure used, very little of it =
> accurate to any usable degree. Tony, I can tell you what to avoid with =
> much more confidence than I can advise you what to do.
>
> My previous boss (and his boss) used the Cro-Magnon method to evaluate =
> technical writers: hours per page. Although this is probably the least
=
> accurate measure, non-writing or pseudo-writer managers love it because =
> it allows them to dodge other elements that require writing ability and =
> experience to evaluate. Among other things, they don't have to consider
=
> a writer's ingenuity, technical savvy, ability to ferret out =
> information, ability to communicate with the customer and SMEs, and =
> ability to produce clear, succinct, accurate, complete, grammatically =
> correct, usable books. In fact, they get to ignore the quality issues =
> altogether.
>
> While these same managers get the pounds of pages that initially make =
> them look like heroes, sooner or later, things come crashing down. =
> First, the field engineers scream about how poor the books are. Then =
> the customers themselves find the plagiarism of previous manuals, =
> boatloads of baloney, mountains of misinformation, and reams of =
> non-specific rumination that's supposed to be helpful troubleshooting =
> and maintenance information. Then the customers find to their horror =
> that lack of quality characterizes the product as well as the =
> documentation. Next come the cash flow problems, layoffs, weeping, =
> wailing, and gnashing of teeth. =20
>
> Tony, if your management insists that hours-per-page is the only way to =
> evaluate writers, take it as a sign from a merciful Creator and update =
> your resume.
>
> Mike Johnson
> Salt Lake City, Utah =20
>
>
>
