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:"Anthony Markatos" <tonymar -at- hotmail -dot- com> To:debbie_pesach -at- attune-networks -dot- com, techwr-l -at- lists -dot- raycomm -dot- com Date:Mon, 29 Nov 1999 10:39:25 PST
Debbie Pesach asks:
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.
Tony Markatos responds:
I create data-flow diagrams to "chunk" the system into tasks.
The data-flow diagrams tell me if I have properly partitioned the system:
each task should not have more than four or five inputs and outputs (total
combination). (Note: These inputs and outputs are also called interfaces.)
I know, from experience, that, if a task has four or five interfaces, I will
need to create about a page or two of procedural text (not including any
systems overview material). If less, usually a page or less.
My estimate is now a matter of simple arithmetic. You will be surprised at
how accurate such an estimate is (and therefore, how comfortable you feel
with it).
Debbie Pesach says:
[The author of a well know book on book managing documentation projects]
..recommends breaking out the various tasks that will be documented......
Tony Markatos responds:
Lets stop here for a second. How are you supposed to "break out" the tasks?
Only data-flow diagrams rigorously GUIDE you through this all-important
activity. Such guidance is very important for new products and larger scale
projects: In such situations, just identifying what the tasks are is a very
daunting task - it so easy to miss important stuff.
Debbie Pesach continues:
...and then deciding on their relative level of difficulty.
Tony Markatos responds:
How do you decide a task's "relative level of difficulty"? By "gut feel"?
For new products and larger scale projects, prior experience can be of very
little value. And "gut feel" has severe limitations.
Using my (above mentioned) estimation methodology, the relative level of
task difficulty is very formally determined - by evaluating interface
complexity. You will find that such a rigorous formal analysis can make a
tremendous difference in terms of the accuracy of your estimate.
Debbie Pesach says:
Then [using the popular methodology] you are supposed to create a thumbnail
sketch of a sample chapter section to determine an average page count needed
for an "average" task. Multiply this by the average number of tasks, add in
other content (TOC, index, front matter, etc.) and you have a general book
estimate.
Tony Markatos responds:
Again, this is all based on some sort of touchy-feely guess. No rigorous
formal calculation comes into play. And for new products or larger-scale
projects, such an approach soon becomes very shaky.
Tony Markatos
(tonymar -at- hotmail -dot- com)
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com