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.
The measurement of productivity is extremely relevant to several other
questions.
For example, if the measurement is done in an easy and sloppy way, the
worst possible forms of single sourcing become quite attractive. That's
one of the big dangers of single sourcing - it skews the easy
productivity numbers, so it is likely to be used where it is not
appropriate.
Targeted and well designed documentation is extremely expensive on a
per-page basis. When I write a Getting Results guide that's 60-70 pages
long, it takes me almost as long as the 300 page comprehensive monster
it replaces. And then it has to be tested more intensively. I have to
know just as much about the product for the short one as the long, and
then I have to know more about how it will be used in order to know what
information _not_ to include. It takes longer to intelligently not write
a page than it does to write one.
I don't have any answers today, just questions. But we have to be sure
to measure the right things, or we will end up producing ever larger
piles of garbage.
---
mike -dot- huber -at- software -dot- rockwell -dot- com
Home: nax -at- execpc -dot- com
>-----Original Message-----
>From: Miki Magyar [SMTP:MDM0857 -at- MCDATA -dot- COM]
>Sent: Friday, February 20, 1998 2:04 PM
>To: TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU
>Subject: measuring productivity
>
>Kathy Borgtodd asked " how do you measure productivity in your department? "
>
>Good question! Usually the answer is, we don't - we get evaluated on whether
>or not we got the manual/help/etc. out on time, on budget, and with approval
>from the client reviewers. Since we work on any given project as a team, and
>are subject to any number of external constraints beyond our control, this is
>about the only thing that makes sense.
>
>'Productivity' on an assembly line makes sense. 'Productivity' in Tech Pubs
>needs to be clearly defined. Or better yet, ignored. What is the purpose of
>the measurement? Who is going to use the information, in what way? The answer
>is in the question - if you are looking for process improvement,
>'productivity' is not necessarily what you want to ask about.
>
>That said, yeah but, and on the other hand -
>Each case is different. If you're churning out updates of a catalog,
>'productivity' may be a valid measure.
>You can't make improvements until you know where you are. Just make sure your
>baseline and metrics make sense for your purpose.
>If you're trying to evaluate tools, 'productivity' may be a key factor.
>Again, be sure you know what you're measuring.
>
