Re: estimating page count for SW user guide

[Alexandra Sutherland <Alexandra -dot- Sutherland -at- aspect -dot- com -dot- au>]

Debbie,
I agree with Tony Markatos' method of chunking the system into tasks and
applying a multiplier. I find this method is very useful for estimating as
well as providing a specification for the documentation - something you can
get approved by the client. Using a simple number formula gives you
confidence and also crediblity in the eyes of others. Beware though not to
take this too far. I tried to create formula related to function point count
(under pressure from the tender manager). Eventually I managed to convince
him that it was just not feasible! I mapped out the following chunking
method for him and he was at least pacified.

The multiplier I use and the things I apply it to vary depending on a number
of factors. In addition to mapping the system you also need to include other
things in your estimate.

You need to consider the type of documentation you are writing. My
multiplier varies depending on the type of document - online help, online
document, paper user guide, paper administrator guide, etc) that I am
producing.

You also need to remember you are not just documenting a system - especially
for user documents. You need to also consider the extra components of a
document that need to be produced, such as the front matter, cover pages,
index, etc, and documenting common interfaces and reference information
(usually included as annexes/attachments), and the number of tables/diagrams
to be included. Also consider how much information can be shared across your
documentation (eg common analysis/research/text in help and user documents).


For example: I worked on a web e-commerce system (as part of a team)
producing online help and user documents (yes, I know but the client
insisted on a paper user guide!). The user guide was about 500 pages using
MS Word and help in HTML.

1. We mapped the system based on the design documents and identified the
main business areas and broke these into tasks.
Eg Request for Tender (business area)- submitting a tender, requesting
tender documentation (tasks)
Tender Submission - logging the tender submission, transferrring documents
System Administration - user maintenance, audit control

2. Then we reviewed the screen designs and tasks and found common
intputs/outputs/interfaces. Each common interface we also considered as a
task.  For example, all business areas included the tasks, logging on,
searching for a department, searching for a geographic location (each needed
to be documented because searching varied slightly for each), etc.

3. In addition we needed to supply attachments of lists of business numbers,
geographic codes, tender codes, details of contact/support personnel.

4. An additional multiplying factor per task was added because the user
guide was graphic intensive - lots of icons and screen shots. 

5. Other non-system components of a document also need to be estimated. For
example, we had to allow time for the client to design a corporate logo (as
part of the front cover design). We had to allow design time for both the
user manual template and the HTML online help web. Not forgetting the style
guide and standard words list - especially important in a team situation.

6. Consider also that your estimate has to account for varying abilities and
experience of your writing team members. Avoid estimating just for your
skill level. 

Remember, an estimate is just that - make sure the client also has a list of
assumptions and risks (and mitigation strategies) associated with your
estimate. This benefits both you and the client.

Hope this is of help.

Alex Sutherland
Training and Documentation Manager
Aspect Computing Pty Ltd
Canberra, Australia
alexandra -dot- sutheland -at- aspect -dot- com -dot- au