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 don't know of very many aspects of business that are more abused or
misunderstood than productivity metrics. Not one out of a hundred companies
can use them well.
First, there is the problem of identifying a valid measurement, which is one
of the most difficult tasks any manager can have. Valid metrics vary from
company to company, and many are identified only because, like the man who
looked for his keys under the streetlight, the light was better over there.
Ideally, productivity should be measured on some kind of outcome basis,
whatever the company sees as its ideal, but not so granular that the
counting process is meaningless. Pages produced, for example, is probably a
useless metric, although it's an easy one to count.
A better metric would be the number of mistakes found, or number of
dissatisfied users, but those are also rather difficult to count and their
validity is dubious at best. Perhaps a better metric is how often you met
deadlines, and how often you hit estimated costs. Again, not something I'd
care to be judged on, but it's better than page counts.
It's also noteworthy that almost always an outcome-based metric is
worthless, because everybody finds ways to puff the numbers. Page count, for
example, can be pushed up merely by hammering out more useless paragraphs.
A proper metric can be valuable to a good manager. The most
important...VITALLY IMPORTANT...point to keep in mind is that you must at
all costs resist the management temptation to rate each and every writer
against her colleagues on the basis of the metric. This is, as W. Edwards
Deming proved, utterly pointless at best, and self-defeating at worst. It
is, in his words, "tampering".
It must be recognized by one and all that everyone in an organization is
embedded within a process (that dreaded "P" word again!), and that workers
in the vineyard often have no control whatsoever over what's happened
upstream. It's absolutely vital that your management use their metrics ONLY
to chart the ENTIRE EFFORT and react only when the numbers reflect an
OVERALL problem in the process, not in any one person's individual
performance. See any good book on Deming's process management. The idea is
that you chart everyone's performance to detect what's a "common cause" of
problems, and what's a "special cause", such as one person not performing
well enough or somebody's account being blown away for a month. Once
everyone is performing within the span of "common causes", NO AMOUNT of
individual coercion, training, or anything else that focuses on individual
performance will improve the overall performance of the process. This is, in
my experience, one of the most common problems in companies, especially in
Level 1 and Level 2 companies where management is often ignorant of
statistical realities and manage mostly by hip-shooting and rules of thumb.
If management uses the metrics they develop to judge individuals, I'd start
working on the old resume. That situation inevitably becomes unstable, like
an electronic feedback loop that's too sensitive. You have every reason to
Simply Written, Inc.
Featuring FrameMaker and the Clustar(TM) System
"Better communication is a service to mankind."
Check our Web site for the upcoming Clustar class info http://www.simplywritten.com
> My department (Tech Pubs/Training Development) has been charged with
> developing a set of productivity metrics to be used for both individual
> department evaluation and planning. I'm pretty underwhelmed with most of
> material I have found researching this issue.
> Does anyone know of a good model or have any experience with this area?
> particularly concerned about validity of any numbers we are able to
> Curtis Ward
> curtis_ward -at- dbs-systems -dot- com