SUMMARY: Productivity Measurement (LONG!!!)

[Larry Grinnell <Larry_Grinnell -at- PTS -dot- MOT -dot- COM>]

The following is a summary of responses I have received from the question I
posed last month on how one measures productivity in a technical writing
organization. As one might guess, I got answers all over the spectrum, ranging
from serious discussion to "who cares."

Names and companies of some individuals have been excised at their request.

In any case, here is the question restated, and the responses. Thanks to
all for their support and assistance.

Larry Grinnell
Motorola Inc., Paging Products Group

======================================================
QUESTION STARTS HERE
======================================================
I'm not totally sure this is appropriate for this forum, but I couldn't
think where else to put up a request like this...

I am the "Technoguru" for the technical communications organization within
Motorola's Paging Products Group. My boss has asked me to put out a
general inquiry among our technical writer/communicator peers on the
internet to ask about writer productivity:

* How you measure it?
* How are you are performing against your own measurement criteria?
* Is a "pages per day" measurement the standard by which writers are
  measured?
* Is there a better measurement than "pages per day?"

Along this line, how many pages per day _do_ you expect from your writers,
and what do you get on the average. If you have qualifiers, such as page
size, graphics pages, etc., please describe them, too.

We are trying to benchmark ourselves against other technical writing
organizations, and in particular, measuring ourselves against other
writers working in the technology fields. We have only recently begun
measuring ourselves in such a fashion and need some guidance/guidelines
based on our peers.

If there is enough interest, I will publish a summary of responses on
this listserver.

Thanks in advance!

Larry Grinnell
Senior Systems Administrator
Integrated Technical Communications
Motorola Inc., Paging Products Group
Boynton Beach, Florida
---------------------------------------------------------------
RESPONSES START HERE
---------------------------------------------------------------
Here the jobs are bid by the group leader. Several itterations of the
bidding take place. (The customer often comes back and indicates that
the price is too high.) You are judged by how well you meet the bid.

We document large scale, one of a kind systems (satellite tracking systems)
usually in the range of several million $.

Personally, I don't care for this system, as I have no input as to how
long it will take to produce the books.

Steve Evanina
Sr. Tech. Writer
Scientific Atlanta
steve -dot- evanina -at- SciAtl -dot- com
----------------------------------------------------------------------
Hello,
I needed to feed this info back to you becasue I have been personally
involved in two different scenarios. The company where I previously worked
measured how many pages we produced in a day, how many errors were on each
page, how many times we inadvertently missed formatting something in the
"accepted" style. The result of which was extremely poor morale, poor
quality technical content becasue there was no learning time alloted.
No one could contribute any ideas to improve anything....it was horrible.
My current company says:
This is the due date----go to it. You are a grown-up competent technical
writer----go do your thing. We have styles we try to conform to, and we
have the deadline to meet. We have the flexibility to tweak the document
as needed to improve the technical clarity of the material presented.
The result of which is extremely high morale, we all love our jobs, we
all try to do our best.....and we meet the deadlines. This is a great
company here in Dublin Ohio.....watch for us in NASDAQ as AINN - Applied
Innovation. The documentation gets better with each revision as we are
encouraged to bring forth suggestions as to what to do to make it better.
Some days I produce not one piece of paper, other days I produce 12
chapters. But I learn the product as I go and the documentation is clear
and concise....user friendly. So be prepeared if you go to the page count
to get resentment and bad attitudes from your writers. Documentation flows
so to speak and if management sets reasonable goals, the writers will
meet them. Hope this info helps.
Louise Mayberry
louisem -at- aiinet -dot- com
----------------------------------------------------------------------
Hello Larry,

It's an interesting question you posed on TECHWR-L. This is a subject that
has interested me for some time, ever since I've been responsible for
managing Writers. I would certainly encourage you to post a digest of
responses.

Here's my opinion:

I have found that 2 pages per day is a reasonable output for estimation
purposes. That is for documents that have to be started from scratch. This
includes planning, writing, editing, and final production of camera ready
copy. It appears simplistic, but it seems to work every time!

When documents already exist, things get more complex. If I had to quote
figures, I would say that a heavy edit with significant new material
would rate at 3-5 pages a day, whilst a light edit still requires 6-8
pages a day.

I hope you get some good responses, all Tech. Pubs Managers will be
interested in the results.

Best regards

Jon
--
(0 0)
Jon Huxtable - Head of Product Services
U S WEST International Systems Group Ltd. Borehamwood, Herts, UK
(44) 181 214 2945       jhuxtabl -at- mpc-uk -dot- com
----------------------------------------------------------------------
...in answer to your question about measuring productivity--In all my years
of tech writing no one I ever worked for has ever had a formal way to
measure productivity! The closest measure was whether we met a deadline.

Best wishes,
Rogers George (Reg13 -at- aol -dot- com)
----------------------------------------------------------------------
Here's what I saved from previous appends. I'm sorry I didn't keep the
appenders' names. I didn't anticipate that I would be forwarding the
information to anyone. . .

Also. . . please post what you get. Thanks.

Debbie Lemasters
debbie -dot- lemasters -at- marcam -dot- com

---attachment follows-------
Lately, our office has been pondering the question of how to measure a
writer's productivity. Our managers are not writers and they insist on
measuring our productivity in number of pages. My questions include:

1) Do you know of any other easily measurable ways to track productivity?
2) How do you keep track of the time/pages?
3) Do you measure different aspects of a project separately? (Such as
   writing original drafts, editing, and entering changes.)
4) What is an acceptable or good amount of time/pages?

>Lately, our office has been pondering the question of how to measure a
writer's productivity. Our managers are not writers and they insist on
measuring our productivity in number of pages. My questions include:

The iron rule of productivity measures is that, whatever you decide to
measure, you will get more of it. Lots more. If your managers want lots
of pages turned out fast, then measuring productivity by number of pages
is a good way to go.

They are also likely to get some or all of the following:

- pointless diagrams and screen dumps
- 'paint by numbers' task descriptions, slowing down the reader by making
  them wade through stuff they didn't need to know
- extra sentences inserted just before a new heading to force an extra page
  break
- if the writer has any control over page layout, some very sparse pages
  AND BIG LETTERS -- even smaller pages
- poor quality control -- shoddy writing, grammar, and spelling - lots of
  repetition -- over-use of copy & paste - 'stream of consciousness'
  writing style - etc, etc

Some of these things (screen dumps, active white space, use of repetition)
are desirable, but only when they're done for the right reasons.

Kim,

You wrote:

>>Our managers are not writers and they insist on measuring our
productivity in number of pages.

Just like measuring a programer's productivity by the number of lines of
code they can pump out. At my last job, the company developed an
automated program-generating program that would produce 600 lines of
code for a simple task (eg, one that a halfway knowledgable programmer
could do with 25 lines of code or less) and 1000s of lines for any
half-way useful application. We wrote up a tongue-in-cheek ad for it that
positioned it a quick way for programmers to improve their "productivity."

At that same company, we did some productivity studies with a few of our
writers. We had developed a project tracking system that distinguished
broad categories of work within specific project. For the studies, we
further refined those categories so that we could distinguish writing
new material from editing existing material from meeting with technical
contacts from creating and testing examples from reformatting the stuff
tech contacts sent from dropping everything in order to satisfy a request
for review draft, etc. etc. ... We found that for typical projects writers
were spending from 20% to 40% of their time on real creative, value adding
work, with the rest of it tied up in grunt work, politics, etc. It was
eye-opening for us, so much so that nobody outside of our group would
believe it.

I'd pose this question: "why does management want to measure productivity?"
What is it that they want to know. Product development (writing,
programming, interface design, package design, and other activities of
such ilk) is different from, say, the number of phone calls a telemarketer
makes in a given hour stretch. Counting the number of pages sounds like
trying to force an activity to fit the wrong measure. Do your managers
measure their productivity by the number of memos they write?

Our measure of productivity was more along the lines of "did the client
get the material they requested in the time-frame they requested?" And
"did our production and delivery of the material fit within the general
turnaround parameters we see for similar projects?" Now, that may well not
be a suitable or adequate measure for your company's management.

Nevertheless, I still go back to the question: "What does management want
to know?" I believe that the "productivity" of product development groups
can be measured meaningfully, but only when you first answer this
fundamental question. Knowing what information about your activities
management wants is the prerequisite to developing a yardstick for
measuring it.

----------------------------------------------------------------------
The following replies are from peers at Motorola in various pubs
organizations...
----------------------------------------------------------------------

There is another factor that isn't being discussed here. What if management
doesn't believe your estimate? Then, whose productivity measurement method
do you use? Yours, or the manager's?

I've used the one page/one writer/one day estimate for years, but for each
manager, I had to prove this estimate. Usually, the manager second-guesses
my estimate, throws out my PERT and Gantt charts, and cuts the time in
half. Then, as my prediction comes true, management tells the customer that
we fell behind schedule (i.e., we are not being productive), when, in fact,
we are right on schedule--the first, realistic schedule.

Customers waiting for documentation (which is usually blown off in our
contracts) often do not understand why they have to wait "extra" weeks or
months for their user and training materials, and put pressure on
management to use the critical path as the delivery schedule. This is far
from productive.

Delaying factors I use when calculating resource availability:
. learning curve for the subject matter (80 hours)
. learning curve for any new software/hardware documentation tools (20
  hours)
. holidays/vacations (scheduled: 40 hours)
. illness/personal days (unscheduled: 40 hours)
. computer down time (20 hours, and I'm right every time)
. customer review delays (80 hours)

The above is based on a project estimated to take six months or longer.
That's seven weeks, which is what makes management balk. If it weren't
true, I would second-guess the estimate, too. But it almost always comes
true.

-Andrea
_______________________________________________________________________________
Once the work to be done is defined, it can then be broken into its
elements. One way to estimate labor is as follows (definitions below):

1. Estimate base time -- admittedly, this number is sort of magical; one has
   to start somewhere. In a clean and perfect world, how long would it take a
   totally productive person unhindered by interruptions to do the work? This
   is  the point at which I close my eyes, rock back and forth, and wait for
   some number to bubble up from wherever such things come from. All it can be
   is my best guess, based on experience and all I've been able to learn about
   the nature of the project at hand.

2. Add 10%-20% for project loss time.

3. Add labor contingency time, typically 25%-30%, to sum of base time and
   project loss time.

4. Add non-project loss time, typically approx. 40%, to the figure derived in
   step 3 above.

5. Multiply by the disruption factor.

6. Sum the duration of non-concurrent work to arrive at span time.

Definitions:

Base time: Totally productive time; no interruptions. Includes travel
           on company time during normal work day.

Project loss time: Short periods when a worker is not working but is still
           charging time to a project.

Labor contingency time: Time wasted because of the unforeseen.

Non-project loss time: Time such as vacations, sick leave, training, etc.,
           when a worker is not available.

Disruption factor: a multiplier to account for less than full-time
           availability (can also be used to account for experience, skill
           level, needed learning curve). If a worker is available only half
           time for a given project, the disruption factor for that project
           would be 2 (will take the worker twice as long to complete the work
           than if the worker were available full time).

Span time: The total (elapsed calendar) time for a full-time productive
           person plus disruption factor.

Estimates I've come up with by using this technique are within 10%-15% of what
I  come up with by using my old "take a wild-ass guess, then double it (at
least)"  technique or by using Diane's "one page per writer per day" rule of
thumb. The main advantage is that it's much easier to sell a project schedule
if one can  point to all the footwork and figuring that went into it rather
than having to point to something that may be just as valid on the basis of
many years' experience in the Publications game but looks like total hocus-
pocus to others.

Would love to hear from more people about their tricks, techniques,
observations, experiences, etc.

Phil
_______________________________________________________________________________
Larry,

In the world before Motorola, when I was with a Publications house, we used
a recognised 'industry standard' when preparing quotations. This standard
productivity figure was 15 pages per week.

This was based on an average of simple pages (TOCs etc,) text pages, graphics,
and assumed that all source material was available - indeed, the estimate could
only be prepared if there was substantial source information available.

Source material comprised specifications, drawings, appropriate to the type of
manual being quoted - usually a Technical Description and associated Operator
information, Install & Commissioning information, and Maintenance information.

The estimate also catered for the preparation of a synopsis for approval by the
customer, draft copy for review purposes and the preparation of final camera
copy - it did not cover print activities.

Adequate source material meant that the document could be written in isolation
of development - on occasions we were contracting for customers over 100 miles
away without the advantage of current communication methods.  Probably one or
two visits for discussion with engineers. Sight of the equipment was an
infrequent bonus, reliance placed totally on good source engineering
information.

We have used that figure as a yardstick here, but as we get closer and earlier
into the development cycle it is no longer achievable, mainly because of the
amount of time searching for information, rework due to changes in the pilot
version or early software loads etc.  The figure is now more realistically 5
pages per week from scratch to cam copy.  What we have gained however is an
earlier learning curve on the part of the writers as they get involved with
development, and also beginning to influence development as writers expertise
grows and looking at the product from a customer and system perspective.

How to measure it - difficult.  I have implemented a coded timesheet which
caters for all the different activities a writer may be engaged in - meetings,
training, writing, project identifiers, manual identifiers, release
identifiers, generating revisions, vacation ,sick, internal activities such as
SOP writing, and many more.  Not fully functional yet but I live in hope of
being able to produce the metrics that are always being asked for.

When making any estimates I apply an availability figure of 70% to all writers
- based on the normal working annual days less vacation, estimated 7 day sick
average, meetings/activities unconnected with writing, training time, travel
time (due to our fractured locations we have a considerable overhead in travel).

Productivity is always a variable in terms of writer experience, availability
of source info, at what stage of development is work commenced, or if previous
documentation has any similarity.

We are also trying to apply 6 sigma to our documentation, based on problem
reports and errors which give rise to a revision requirement, measured against
the total pages in the manual and also broken down into format error, writer
error (poor phraseology typos etc) missing information, incorrect eng
information, print errors.  We do not yet have a solid process!!!

I have also instituted a formal edit process to provide a second, independent
line of quality checking and improve the standardisation of documents being
produced in three different locations (with English, Irish and American
writers) but all dealing with the same system.

Hope this helps.
Regards

Terry
----------------------------------------------------------------------
Larry,
I find that not spending my time counting the number of pages people are
producing in an hour makes ME more productive.  Seriously, I think you will
be hardpressed to find a meaningful formula.  I don't know about the paging
business, but here there are far too many variables:  complexity of
information, availability of subject matter experts, existence/accuracy of
specs, availability of product, new vs. revised, research, etc. I think that
a productivity measurement may be applied to something that is fairly routine
(e.g., number of pagers coming off the line, number of chocolates Lucy and
Ethel can stuff into boxes, number of pages that can be typed/produced, etc.)
but the creative and research processes do not lend themselves easily to this
type of measurement.  What type of productivity measurement is used in
Engineering?  Bottom line, if you're going to measure productivity, focus on
the "manufacturing" part of the publications process:  i.e., the final
production and preparation for printing.  Other than that, I think you'll
just be tilting at windmills.

Chris
----------------------------------------------------------------------
Hi Larry,

We at (a division of Motorola) don't measure productivity per se;  what we do
measure is cycle time.  Rather than measuring the productivity of each
writer/member of the department, we measure the total time it takes
to complete the various types of manuals we produce (owner's manuals,
service manuals, etc).  As you know, the rate of productivity (per page)
would differ between an Owner's Manual and a Service Manual.

By measuring total cycle time (from receipt of preliminary material
till supplying printed copies to the Motorola stockroom), we cover
all facets of manual preparation.  Our measurements show that our
cycle time is decreasing; consequently, productivity is increasing.

Eva

=======================================================
 Larry Grinnell, Motorola, Inc., Paging Products Group
                 Boynton Beach, Florida
           Email: Larry_Grinnell -at- pts -dot- mot -dot- com
   "History Delights in Details"--John Quincy Adams
=======================================================