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.
Subject:Re: Measuring a Doc Dept From:Typo? What tpyo? 02-Oct-1994 2232 <jong -at- TNPUBS -dot- ENET -dot- DEC -dot- COM> Date:Sun, 2 Oct 1994 22:42:39 EDT
Pete Pollich <pete -dot- pollich -at- NWCS -dot- ORG> asks what metrics exist
for documentation departments. As it happens, I have just
returned from leading a seminar on documentation quality (in
Oregon, as it happens!) that included quite a lot of
information about metrics.
First, it's *good* that you have a VP who cares to manage by
facts, i.e., metrics. The ones who issue edicts like 'our
books are too long, make them shorter' are the ones you
should worry about. Better yet, your VP is giving you the
chance to define your own metrics, as opposed to issuing
them to you. So here's your chance to do yourself some
good!
First, what is it you care about enough to measure? From
the posting it sounds like the VP is concerned with
fundamental process questions: How productive is the
documentation group? How efficient is it? Are there areas
for improvement? Such a person might like to know what the
documentation group costs as an investment. If you can, it
would be nice to show how much return there is on that
investment. You have access to support calls; that's a
great place to start! How many calls come in per customer
per product per month? What fraction concerns documentation
problems? When you revise a documentation set for a
product, what is the effect on calls? Can you demonstrate
that by revising a doc set you've saved some amount of
support cost?
Can you measure the average length of time a document takes
to go through editing, illustration, review, and production?
Are there areas for improvement? Are there problem areas
that stand out? What are the most common reasons for
unexpected delays in production, editing, illustration,
writing, and review? If you identified the problem areas,
could you reduce or eliminate them?
You probably also care about the needs of your customers.
What's important enough for you to measure in customer
satisfaction? Are they getting what they want? What are
the most criticial needs of your customers in documentation?
Can you measure it? Can you demonstrate that you're
providing it? Are there things you need to provide more of?
Are they satisfied? Can they be more satisfied?
There are a number of sources for documentation product and
process metrics. My paper in the most recent ITCC
_Proceedings_ covers some of the more important ones and
cites places where you can learn more.