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.
I usually follow these steps to estimate a documentation project schedule:
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 below 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 ready, 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.
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.comhttp://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.
