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 iron law of finance: you get more of what you pay for, and less of
what you tax. If Hope's company rewards TWs for writing more pages,
then more pages they will get.
Let's say you put out a 200-page draft manual for beta testing. Based
on customer feedback, you merge two chapters, eliminate some repetitive
text, tighten up some waffly writing, and use graphics and tables to cut
an appendix by half. The final manual ships at 175 pages, to applause
from customers, customer support, and the STC awards committee.
What just happened? The page count went down by 25 -- was that negative
productivity? Even if the page count ends up the same, you may well have
made substantial changes to most of the manual. Is that worth nothing?
Being saddled with a dumb set of performance measures which measure
things that don't matter -- that's annoying, but that's life. Measures
that actively encourage you to churn out bad writing quickly, and punish
you for tight writing and good organisation -- that's another thing. How
would your managers feel in your shoes? Come to think of it, what are
their performance measures?
To paraphrase Dr Johnson, performance indicators are both quantifiable
and useful. But the ones that are easy to quantify are not useful, and
the ones that are useful are not easy to quantify.
"Cramer, Kim" <kcramer -at- NCSLINK -dot- COM> wrote:
> <great stuff about benchmarks snipped>
>
> 1. We estimate time to completion for each book for each release, then
> we track actual time. We're expected to estimate within +/- 10% of
> actual. This comparison helps us become better at estimating for future
> projects so they are more likely to stay on track for the estimated
> release date.
I like this. The TWs get rewarded both for making accurate estimates
and for working to them.
> 3. We monitor Support calls to ensure that FAQs are adequately covered
> in the books and online help. If we can answer the user's questions
> with the docs, we reduce the calls to the Support line. This is an area
> where we can make a big difference to both our clients (saving time and
> aggravation) and our company (saving money).
Another good practical measure -- one that aligns with a company's goals
(happy customers, reduced costs). 'More pages' doesn't sound like any
company goal I ever heard of.
> Good luck on convincing them to ditch the page count stats idea, and
> find something to measure that really means something to the user or
> company.
Sounds like your company has got it about right, Kim.
Regards
---
Stuart Burnfield
Applied Phlogiston Pty Ltd mailto:slb -at- fs -dot- com -dot- au
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
