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: docs to development ratio From:chuckm -at- MDHOST -dot- CSE -dot- TEK -dot- COM Date:Thu, 28 Mar 1996 16:18:31 PST
Someone asked if it is possible to estimate the work required
to create documentation on the number of hours required to develop
the product.
Helen Hegelheimer replied to the thread:
> Richard Mateosian replied in part:
> >
> > There's no way to determine this information from the number of programming
> > hours. ...RM
> I disagree with Richard. It is difficult to estimate
> a project, especially at the beginning. Technical Communicators must
> develop estimating formulas if we are ever to achieve any status within
> our organizations. The formulas can be honed to your particular products
> and based on prior experience. For example, our product uses customized
> widgets that differ from customer to customer. Through experience, we have
> determined that documenting these customized widget takes 3-5 hours
> depending on the detail of the widget.
I agree with Richard. I never pay attention to how long it takes to
develop a product. I look at what I have to document. There can be a
tremendous effort required to create an easy to use product. Simple to
use products can be very easy to document. Conversely, something can
take a relatively short time to develop (because little time was spent
on making it easy to use) and it can be a bear to document.
Additionally, the type of documentation needed affects the time required
to document a product. Mimimalist documentation usually takes *longer*
to develop.
> As a rule, my boss and I estimate doc's effort to be half of the
> development hours (and only the development hours). Estimating projects is
> an extremely important part of our profession. And in my opinion, is the
> key to achieving the corporate respect that seems to allude us all too often.
I compare the new product to a similar existing product. I look at the time
that was required to document the existing product and adjust the estimate
accordingly based on the comparison of the new product to the existing
product.
Some product features require a lot of effort to develop, but the effort
can be somewhat hidden from the customer. That is, the customer
just sees a number on the screen, for example, a measurement. There is
little the customer needs to do to use the capability. It takes
little effort to explain how to press a button and read the results
on the display. But, it can take a lot of development effort to make
that feature available.
Chuck Melikian chuck -dot- melikian -at- tek -dot- com
Measurement Business Customer Documentation
Tektronix, Inc.
