Summary (long): online help estimates

Subject: Summary (long): online help estimates
From: Stephanie Holland <SLHOLLAND -at- MICRONPC -dot- COM>
Date: Wed, 17 Feb 1999 15:30:32 -0700

Thanks to everyone who submitted suggestions about how to provide accurate estimates for online help projects. Several people asked me to summarize the responses.

Here is a snip of my original post:

<snip>I'm managing an online help project for an application that hasn't been prototyped yet. The project manager for this application is basing her time estimate on the number of forms, modules, and reports the application will have. I don't feel comfortable basing my estimate on the number of forms in the application because our online help is task-based, not form-based.<snip>

Many people told me I should base my estimate on the number of topics, tasks, or functions. However, that was exactly my problem -- the only information I had was the number of forms, reports, and modules. Heck, the project manager hasn't yet chosen the software with which the programmers will write the application!

Based on my limited information about the project, the best suggestion I received was to refer to the "Developing Online Help for Windows 95" book by Boggan, Farkas, and Welinske. (See the first response I include below.)

I own the book, but didn't think to check it. This is a terrific book, and, as usual, it was helpful. I decided to assume that most of the dialog boxes (forms) would be complex, which gave me the number of six procedure topics for each complex dialog box. Then, I multiplied that number by 8 hours for the time to create each online help topic. Yes, 8 hours is a large number, but I wanted to be safe rather than sorry.

This is not the right way to estimate projects according to JoAnn Hackos ("Managing Your Documentation Projects"), but it was the best I could do in my situation.

Here are snips from the responses I received, in no particular order.
The book "Developing Online Help for Windows 95" by Boggan, Farkas,
and Welinske has this to say:

For every command that does not display a dialog box, figure on 1
procedure topic.
For every command that displays a simple dialog box, figure on 3
procedure topics.
For complex dialog boxes, figure on 6 procedure topics.
As a rough rule of thumb I was taught that:

Number of topics is approximately 3 x number of commands in menus

2 topics is approximately 1 page of text

Using these together should give you a good ballpark figure.
A few estimating approaches:
1. Allow roughly 7 hours per topic. This average works out only if you
have topics that vary in length.
2. Allow 15 days for the help for each form. Your development process
parallels the development of the form. Be sure that the final day or so is
scheduled after final testing on the form.
3. Number of forms x 10 tasks x 8 hours per task.
4. Number of tasks x hours per task. then add a week for prototyping and a
week for finishing (during testing).

At the risk of sounding cynical, you can hardly over-estimate a project that
has not yet been prototyped. Make that estimate generous and you'll only be
a little short!
I'm learning that sometimes you just make your best guess, and document
the assumptions on which it's based. "This estimate is based on a list
of 24 functions, which we believe will require no more than 35 help
topics." Then, if it turns out that there are 75 tasks to perform the
24 functions, or the number of functions change, you have a legit reason
to adjust your estimate.
You know, if the developers are really starting this application with so few
design plans, I'd be very careful about how you approach this. It might be
better to point out that beginning a software development task without a
clear roadmap will incur more setbacks and may waste a lot of valuable time.

If you've read this far, thanks again to everyone who offered suggestions.

Stephanie Holland
slholland -at- micronpc -dot- com

From ??? -at- ??? Sun Jan 00 00:00:00 0000=

Previous by Author: online help estimates
Next by Author: Re: Getting Job/Resume/Pamphlet
Previous by Thread: Re: Specification Software/Templates?
Next by Thread: Wanted: Technical Writer for E-commerce startup

What this post helpful? Share it with friends and colleagues:

Sponsored Ads

Sponsored Ads