Re. Productivity

Subject: Re. Productivity
From: Geoff Hart <geoff-h -at- MTL -dot- FERIC -dot- CA>
Date: Fri, 15 Sep 1995 09:22:34 LCL

Larry Grinnell asked how to measure productivity
and compare his group's productivity with that of
other organisations. Larry, this was discussed
recently (not a flame), so I'm sure the original
posters will summarize. One common thread was that
you must collect data in your own unique context
to serve as a benchmark; another is that quality
must be part of any productivity metric, since
volume is irrelevant unless quality is also high.
It seems to me that what you need is an "approach"
to defining productivity as much as you need
specific details, so here's one for discussion:

Premise: Productivity with respect to others is
irrelevant provided that you're meeting internal
deadlines and not delaying the delivery of the
products that you're documenting.

Conclusion: Don't waste your time comparing your
productivity with anyone else. Identify your
current productivity using whatever metrics seem
appropriate, then see if you can come up with
strategies to improve these metrics. Periodically
test whether you're still meeting whatever goals
you've set with respect to those metrics. For
example, one metric might be "no more than two
edits required", in which case, if you're
currently having a document edited 3-4 times,
you'd have to ask your editor to teach your
writers how to require less editing. (A bit fuzzy,
but I'm illustrating a metric rather than
recommending one.)

If the need for productivity measures reflect an
attempt to estimate how long projects will take,
there's no alternative other than to start timing
your own projects and attempt to correlate these
times with characteristics of the job. This
provides benchmarks that you can use to estimate
your own projects. A few examples of possible
correlates: number of words or concepts (better
than words) per manuscript, number of product
features, number of parameters per feature,
whether the expert/developer/author is available
locally or by phone or by airplane for
consultation, etc. Here's how this might work
(warning: very simplistic example to show approach
rather than realistic numbers): A typical author
might produce 1000 words per day, less 20% if
there are more than 4 concepts to document, less
5% per parameter that must be documented for each
feature, less 50% if the expert is unavailable and
the writer must go to the library or do similar
research. On the other hand, increase productivity
by 25% if the expert works two doors from the
writer and loves explaining how things work, if
the engineering specs are followed closely, if the
author is highly experienced, etc.

--Geoff Hart @8^{)}
geoff-h -at- mtl -dot- feric -dot- ca

Disclaimer: If I didn't commit it in print in one
of our reports, it don't represent FERIC's

Previous by Author: Re. Bulkiness
Next by Author: Re. Table of contents for figures/tables
Previous by Thread: Re. Bulkiness
Next by Thread: Re: Justified and Unjustified Text

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

Sponsored Ads