Re. Productivity

[Geoff Hart <geoff-h -at- MTL -dot- FERIC -dot- CA>]

     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
     opinion.