Productivity for Technical Communicators

[Michael Uhl <uhl -at- VISLAB -dot- EPA -dot- GOV>]

Measuring the productivity of a worker involves three fundamental
questions:

          1. How much is produced per unit of time? (Quantity)

          2. How good is the end product? (Quality)

          3. What process is used? (Method)

The way I have built a good reputation as a technical communicator is
to begin be addressing Method (3), then Quality (2), and then, last,
Quantity (1). Here's why.

The customer has a need that they communicate to me. They need x by
date_y. I evaluate these two parameters and recommend a method, and I
specify what quality can be achieved using that method in the specified
time frame. If the customer needs better quality, we start over, and I
recommend a different method. Finally, we reach an agreement: I will
produce x by date_y meeting quality criteria y (qc_y). The measure of
productivity comes only when we coomplete this project and complete a
subsequent project. Then we look at these criteria *across projects*.

Let's say we continued with qc_y. Let's also say that x(1) and x(2) can
be readily compared. This allows us to focus on the method. Or let's say
x(1) and x(2) cannot be easily compared. That means, we probably didn't
use the same method. I don't have time to explain my whole thesis here,
but the two points I want to make are these:

    1. Productivity is measured across projects, comparing one project
       against another. You should not attempt to measure it within a
       project. The goal in measuring productivity is to improve
       output while holding or improving quality. This means improving
       the skills of the people or improving the processes.

    2. Management should judge your performance based on what you agreed
       to at the beginning. Did you meet the deadline? Is the quality at
       the level agreed upon? If not, why? Did the communicator choose
       an inappropriate process? Did they underestimate the work? Was there
       some unanticipated event (mitigating circumstances)?

On TECHWR-L and other related listservers, there's a lot of discussion about
which electronic publishing program to use. They all have deficiencies and
really cool features. But not one of them is *the* right one for all technical
communicators or for all the projects of any one communicator. Part of
what we do is choose the right method of production for every project we
encounter. Even if management forces a program or method on us, we should let
them know in very clear terms that we disagree with the selected method,
why we disagree, and what we propose instead.

...I have go to get back to work...sorry for preaching, but this productivity
issue gets under my thick skin...

-Mike


------------------------------------------------------------------------
Michael Andrew Uhl                          Internet: uhl -at- vislab -dot- epa -dot- gov
Lead Technical Writer                       Compuserve: 72624,2155
SVC/NESC                                    Phone: (919) 541-4283
Martin Marietta Technical Services, Inc.    Fax:   (919) 541-0056
Primary Support Contractor for the EPA      ftp site: ftp.nesc.epa.gov
Research Triangle Park, NC 27709
************************************************************************
              Scientific Visualization Center (SVC),
       National Environmental Supercomputing Center (NESC)
           U.S. Environmental Protection Agency (EPA)
************************************************************************