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:Estimating pages per hour From:ArtElser -at- AOL -dot- COM Date:Thu, 10 Jul 1997 11:47:38 -0400
Mathew J Long asked about how to estimate projects in a post on July 8th.
Being able to estimate the scope of a project is probably the most critical
aspect of good pubs project management. As for metrics for the time necessary
to produce a page of good documentation, that obviously varies with many
factors such as product stability, accessiblity of SMEs, information
availability, the writer's experience and knowledge of the technology, the
writer's familiarity with the tools.
Someone posted a two to three hour per page range. Our experience with new
documentation project, not revised docs, is that a page of documention takes
about five hours per page. Those five hours, however, include research time,
time to interview SMEs, editing time, project management time, and writing
time. It does not include time to do screen captures or produce graphics.
We then adjust the five hour standard by evaluating 10 factors, including
those I've mentioned above. On a project in which we're documenting a product
that's already shipped and is therefore stable, the SMEs are very
cooperative, and our writers are experience in the technology and tools, we
might lower the estimating factor to three and a half to four hours per page.
If, on the other hand, the product has no specs, the designers are shooting
from the hip and are too busy to speak to the writer, they are working in a
technology the writer has no experience in, and the tool the writer is using
is new to the group, we might use an estimated hours per page figure of six
to seven and a half.
For a good discussion of how to evaluate the complexity of a project and thus
put some intelligence into your estimating process, see pages 174-181 of
JoAnn Hackos's book Managing Your Documentation Project (Wiley 1994). As a
matter of fact, the entire book is well worth the price for anyone who has to
estimate and manage publication or training projects.
As far as basic metrics for hours per page, five hours seems fairly common
among organizations how do estimate projects. One key for any organization,
however, is to keep track of the hours actually spent during a project, both
to help keep the project on track and to build a history of the time required
in that organization to produce a page of documentation. Once you have a
metric developed for that organization, you can factor in the dependencies
that vary by project to get a better estimate for a particular project.
Art Elser
Comtech Services, Inc.
art -dot- elser -at- comtech-serv -dot- com
TECHWR-L (Technical Communication) List Information: To send a message
to 2500+ readers, e-mail to TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU -dot- Send commands
to LISTSERV -at- LISTSERV -dot- OKSTATE -dot- EDU (e.g. HELP or SIGNOFF TECHWR-L).
Search the archives at http://www.documentation.com/ or search and
browse the archives at http://listserv.okstate.edu/archives/techwr-l.html
