TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Subject:Re: Estimating time From:Robert Plamondon <robert -at- PLAMONDON -dot- COM> Date:Thu, 30 Jan 1997 08:05:36 PST
>Does anyone have any methods of estimating the time required for a
>documentationproject, for both Winhelp and paper manuals? I've
>always been good at doing a thumbnail estimate of time requirements,
>but want to put a little more, ahem, timeinto it.
My method is extremely straightforward: I use past history when estimating
future results. For example, I can divide the total number of hours I spent
on a project by its page length, and this gives me the number of hours
per page. With a few projects of different types, I end up with a catalog
of completion rates. These are reasonably accurate most of the time.
It's important to keep in mind that these estimates are just estimates,
and the only way to meet these estimates right on the money is to fine-tune
the definition of the job -- adding or removing work in order to match
the estimate. It's not clear who's served by these shenanagins.
Personally, I'm getting away from hourly billing and going almost exclusively
to project billing. This gives my clients something concrete to budget
for. I come out somewhat ahead, as I should, since I'm both assuming
risk and relieving the client of some management and planning tasks.
>I've heard of "industry standard" estimates of both 5 hours per page and
>6.5 hours per page, but am not sure what this really means (for example,
>are these hours/page estimates for all drafts--and how many drafts? Do they
>include graphics development?) What other methods are in use out there?
The rule of thumb in the semiconductor industry seems to be 1, 1.5, or 2
pages per day. These estimates sometimes include only billable hours
(that is, reviews and delays don't count), and sometimes include all
working days between the start of the project and masters being delivered
to the printer.
When I managed a documentation department, we hovered slightly above
one finished page per working day, including all reviews. In my
consulting practice, I always achieve more than two finished pages
per billable day. Part of the difference in rates is the difference
between a "working day" and a "billable day." A lot of it, though,
is because I'm a very fast worker. (Use high-end tools, arrange a
quiet, pleasant working environment, and never ask an SME a question
that you can answer yourself.)
Most companies do the same kinds of documents over and over. Thus, your
estimation techniques will get better over time if you review what's
gone on before.
(Oddly, this is rarely done, even by so-called professional managers. I
used to amuse myself by keeping engineering projects schedules and
tracking the schedule slip. Since I always arrive on time for meetings,
and hardly anyone else ever did, I usually had time to look at the revised
schedule and calculate the slip from last week's schedule. The number
of weeks a schedule slips in a week is called "slip velocity." A
constant slip velocity of 1.0 makes a project last forever. The rate
of change of slip velocity is "slip acceleration." These make nice
charts to put on your wall.
In any event, at the beginning of every engineering project, I asked the
manager how long each phase had taken in the previous project, how
much the previous project has slipped compared to its original schedule,
and what specific, structural improvements were being made to justify
his new project's schedule, which of course was wildly optimistic compared
to past history. No manager had ever done ANY of this rudimentary
Interestingly, project slipped so many times that people generally forgot
what their original milestone was. People would often insist to me that
a project had slipped only six months, when in reality it was over a year
late. Under these circumstances, the number of pages per man-day is
a largely irrelevant metric, since the non-existence of the product
to be documented is the overwhelming concern.)
Robert Plamondon, High-Tech Technical Writing, Inc.
36475 Norton Creek Road * Blodgett * Oregon * 97326
robert -at- plamondon -dot- com * (541) 453-5841 * Fax: (541) 453-4139