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 page count for SW user guide From:Fabien Vais <phantoms -at- pop -dot- total -dot- net> To:TECHWR-L -at- LISTS -dot- RAYCOMM -dot- COM
To my knowledge, there are four ways to estimate the number of pages that a
document will be:
WAY #1 - The magic wand
Just wave a magic wand over the material that you have gathered to make up
the document. The desired number of pages should (no garantees...) pop up in
your head.
WAY #2 - The algorythm
Use a very long scientific algorythm that takes into account all kinds of
variables such as the degree of difficulty of the software, the willingness
of SMEs to help you, the degree to which you actually understand the
software yourself, etc. This algorythm is not a joke. I can send it to
anybody who is (SERIOUSLY) interested. I haven't used this algorythm myself
but a colleague of mine uses it quite regularly and swears that it works
with very little error margin.
WAY #3 - The Hackos method
This is probably the most widely used method. As you stated, break down the
software to be described into TASKS. Assign a difficulty factor to each
task, going from 1 (very complex task to explain) to 7 (disarmingly simple
task to explain). A difficulty factor of 5 is normal. Then, for each task,
you have to ask yourself how many pages you would need to EXPLAIN this task
to someone. To this page count, you must add the number of pages in the
Front Matter (Title Page, TOC, Copyright, etc.) and the Back Matter (any
appendixes, Index, back cover, etc.). This will give you AN APPROXIMATE
number of pages.
WAY #4 - Experience
When you have a lot of experience, not only as a writer but also with the
particular software documentation, you can probably use your experience to
determine a ballpark number of pages for the document.
These are the four ways I can think of. Hope this helps.
Fabien Vais
At 03:33 PM 11/29/1999 +0200, you wrote:
>Here's what I hope is a good question, with--unfortunately--no
>definitive answer (Why go easy on the list gurus? It's still the
>beginning of the week, energy levels should be high): How do you
>estimate the page count for a new printed software User Guide (that
>isn't based on any existing documentation)? I'm looking for some ways to
>estimate my project. Note that I've checked in the archives and most
>threads discuss the "hours/page" issue. I am interested in learning how
>you know how many pages you need in the first place. I'll throw out two
>methods:
><><><><><><><><><><><><><><><><><><><><><><><
Fabien Vais - Documentation Analyst (Analyste en documentation)
Technical Writing, Technical Translation/Globalization, Editing, Publishing,
Teaching, Training
Rédaction technique, Traduction/globalisation technique, Révision, Mise en
Page, Enseignement, Formation
e-mail: phantoms -at- total -dot- net
Mailing address (Adresse postale): 38 Elderidge, D.D.O. (Montreal), Quebec,
H9A 2P4
Phone/Fax: (514) 685-4752
