Productivity Formulas

[Robert Plamondon <robert -at- PLAMONDON -dot- COM>]

Productivity is a measure of the work done per unit time.  The concept
breaks down in writing and programming because a line of text or code is not
a unit of work.  This is true at all levels; word, line, page, manual, and
document set.  Size means almost nothing; it's not even bounded by typing
speed in many cases, because so many documents are Frankenstein's Monsters
of old text.

There are two uses for productivity metrics.  One is to estimate how long a
job will take, or how fancy a piece of work can be stuffed into the
available time.  The other is a way to judge writers.  The two uses are
almost unrelated.  In general, judging and ranking employees (that is,
blaming them) is used as a handy way to demoralize them and reduce their
efficiency.  Actual MANAGEMENT has little to do with assigning blame.  Back
when I was managing, I quickly learned that the annual performance review
cycle had an entirely negative impact on my department, leaving my staff
deeply upset while accomplishing nothing of value.  I found it far better to
tell them that I thought the process was a worthless charade, and that I was
just going through the motions.  Even so, they could not shake off the
feeling that it meant something, and it worked best if I told them it was a
worthless charade AND gave them extremely high marks!

At this company, the uselessness of the process was highlighted by the way
it was more difficult to promote someone or give them a substantial raise
during the review process than at other times.  The purpose of the review
was to upset people with your judgments and then upset them again by handing
out pathetic little raises, which some sadist labeled "Merit Pay."

Now, given a task that's very similar to a task I've done before, for a
client I've worked with before, and with several other constraints also held
constant, I can produce an estimate that's pretty accurate.  This even
happens a fair proportion of the time.  But the biggest variables in my
schedule have little to do with me.  They are (1) the rate of progress in
the design of the client's product, and (2) the level to which the client is
dedicated to supporting me.  Note constraint #2 -- I'm an engineer by
training, and I can do documentation by reverse-engineering if I have to,
and I *still* have client support as a major constraint.

If I were still managing, and someone wanted productivity metrics, I'd find
one that always made my group look good.  I'm sure that, given a little
time, I could create one in which productivity also rose continuously,
without having to do anything crude like making the date part of the
formula.  I am certainly cynical enough to give upper management a
meaningless metric that works in my favor, rather than a meaningless metric
that works against me.

Here's a thought for those of you who are considering this:  Find the oldest
memo with the ORIGINAL ship date for the project.  Base productivity on the
time spent on the project minus the project slippage, with the result
clamped at zero.  For example, if you wrote a 100-page manual in ten weeks,
and the project slipped five weeks, your "productivity" is 100 pages/(10-5
weeks), or 20 pages per week.  You will frequently achieve infinite
productivity this way.  This is great to report at meetings: "Tech Pubs'
productivity metrics are reporting infinite productivity, because we don't
count time elapsed due to Engineering's schedule slips." If you think people
will object to this, only subtract half the slippage.  Or you can base it on
percent slippage.  If you're feeling mean, you can add in "slip velocity"
(the number of weeks of slippage per week) and even "slip acceleration" (the
increase in the number of weeks of slippage per week), just to watch people
wince when you use these terms to describe their projects!

The other method, which isn't so obnoxious, is to base your schedules on
"three weeks after tape-out," or "two weeks before customer shipment" and
things like that.  You can base your productivity on whether you met this
target, rather than a fixed date.  This is hard for people to argue with,
provided that schedule slips are rarely your fault.

Remember, the use of productivity formulas in tech writing and R&D is almost
always boneheaded, and is often sadistic to boot.  Let's all be careful out
there!

        -- Robert
--
Robert Plamondon * High-Tech Technical Writing
36475 Norton Creek Road * Blodgett OR 97326
541-453-5841 * Fax: 541-453-4139
mailto:robert -at- plamondon -dot- com * http://www.pioneer.net/~robertp


 From ??? -at- ??? Sun Jan 00 00:00:00 0000=