RE: Estimating time

["Dugas, Andrew" <ADugas -at- eTranslate -dot- com>]

As said by others, there's no easy way. 

However, I usually follow the below steps to estimate a documentation
project schedule. It boils down to 4 hrs/page, too, but offers guidelines
youcan use to modify that figure up or down:

1. Determine scope of project - Who is the audience? What kind of
documentation is needed? Installation? Admin? Using? How many different kind
of books?

2. Determine product maturity - Is the product existing or in development?
If the latter, how stable is the current version? Is it something you can
play with? Otherwise, have functional specs been developed? Is the feature
set stable? 

It can really screw you up if the keep changing the product features
midstream.

3. After resolving steps 1 & 2, develop a detailed outline of all the
manuals. The outline items will become your chapter titles and headers, so
go as deep as Header3.

4. Go over the outline(s) with the appropriate developers and product
managers. Some companies require marketing buy-in as well. Ensure that all
functionality, explanations, and instructions are accounted for. Revise
accordingly.

5. Here comes the real guesswork - Allow one page for each item on the
outline. This would be non-inclusive, that is, for a Header 2, don't count
the Header 3 items within it. Then check each item (section) and estimate
how much instruction will really be needed for it. 

If the product is close to mature and you have been able to play with it,
you should be able to guess fairly easily which things need three steps to
explain and which need twenty-five. The less mature the product, the more
guesswork.

6. Total up the page count. Allow four hours (yes, FOUR hours) for each
page. You can now set up a schedule with milestones.

If your page count puts you months behind what they need, you can revise.
But don't go too short, or you'll regret it. The four hour formula is
designed to allow for things going wrong such as interface changes, feature
changes, SMEs falling ill, etc. 

Much also depends on other facters: The more mature the product, the more
professional the development team, the more stable the company, then the
more you can safely trim.

OTHER TIPS

Compare your doc schedule with your SME's travel/vacation schedule. If s/he
going to Maui the week you'll need him/her, it could set you back. Same goes
for your reviewers.

If the product is really not mature, allow plenty of time toward the end for
screenshots. Personally, I find it more efficient to do screenshots along
the way, but sometimes you have no choice.

-----Original Message-----
From: Marilynne Smith [mailto:marilyns -at- qualcomm -dot- com]
Sent: Wednesday, September 19, 2001 5:52 PM
To: TECHWR-L
Subject: Estimating time



I've been asked for the "rule of thumb" list of how long it takes to write 
a page, edit a page, etc.

I said "oh sure" thinking that I could find it right away, but I 
can't.  Would someone help me out?

Marilynne

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

A landmark hotel, one of America's most beautiful cities, and 
three and a half days of immersion in the state of the art:
IPCC 01, Oct. 24-27 in Santa Fe.  http://ieeepcs.org/2001/

  +++  Miramo -- Database/XML publishing automation.  See us at  +++
  +++  Seybold SFO, Sept. 25-27, in the Adobe Partners Pavilion  +++
  +++ More info: http://www.axialinfo.com  http://www.miramo.com +++

---
You are currently subscribed to techwr-l as: archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot-  Visit 
http://www.raycomm.com/techwhirl/ for more resources and info.