Re: meeting goals/benchmarking

Subject: Re: meeting goals/benchmarking
From: Stuart Burnfield <slb -at- FS -dot- COM -dot- AU>
Date: Wed, 9 Jul 1997 01:30:19 +0800

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


Previous by Author: Databases and Pigeonholes
Next by Author: Re: Where is everybody?
Previous by Thread: Re: meeting goals/benchmarking
Next by Thread: Re: meeting goals/benchmarking


What this post helpful? Share it with friends and colleagues:


Sponsored Ads