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.
I'm all for implementing new process to improve productivity, etc.,
but this metrics fad can be very aggravating. At one company we
wasted hours coming up with "metrics" that were never implemented.
If they had been, we would have wasted more hours tracking them.
Be self-serving. (You'll become cynical soon enough ;)
Many measurements are pointless, *especially* those suggested
by non-doc people. Some examples: number of pages produced,
number of corrections editors have to make per page, file
size, etc.
However, if you are managing the doc process, some measurements
can help *you* (as opposed to just giving lip service to some
quality committee out there). Some examples of *potentially*
useful measurements:
1. Approx. average of pages produced per day (Don't
waste your time actually tracking pages per day per writer--
just guesstimate on a project-basis the average pages produced
per average writer. This can be useful for estimating future
projects and determining whether or not new procedures are actually
increasing efficiency, etc. Of course, it doesn't tell you the
quality of the work--which is why you should never measure
this on a per-writer basis--it will encourage some writers to
produce sloppy, lengthy work in the interest of page count.)
2. Decreases in number of bugs filed against docs.
3. Decreases in tech support calls due to mistakes/omissions/
confusion in docs, etc. (With the understanding, in writing,
that docs are not supposed to make up for deficiencies in GUIs,
and so on.)
Any other suggestions from folks? The key is to get meaningful
information that you can use to do your job better without
wasting a bunch of time.
Hope, I can almost guarantee that most of the types of metrics
you described (page count, for example) will do nothing but
eat up your time and your morale. Try to counter these suggestions
with either some measurements that will help you (and call them
metrics) or, as Robert suggested, some cynical, self-serving metrics
that don't take much time to measure so you can get on with your
work and wait for it to blow over.
>----------
>From: Robert Plamondon[SMTP:robert -at- PLAMONDON -dot- COM]
>Sent: Tuesday, July 08, 1997 10:46 AM
>To: TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU
>Subject: Re: Measuring goals/bemchmarking
>
>Hope Creskoff writes:
>
>>...my department is
>>establishing ways to collect metrics for our 2-person documenation
>>group.
>
>I suggest you come up with metrics that are cynical and self-serving.
>Depending on the organization, you may or may not have to whitewash
>your intent.
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
