Estimating Complex Projects? - Responses

Subject: Estimating Complex Projects? - Responses
From: "Anthony Markatos" <tonymar -at- hotmail -dot- com>
To: wtreisz -at- raque -dot- com, techwr-l -at- lists -dot- raycomm -dot- com
Date: Fri, 03 Sep 1999 15:45:45 PDT

Based upon a suggestion from another listserv member, below are copies of the responses that I got to the question "How do you estimate complex projects?"

Thanks all for the great advice.

Tony Markatos
(tonymar -at- hotmail -dot- com)

Tony Markatos asked:

Question for all listerv members:

How do you estimate a documentation project for a complex software system? I have read estimating "rules-of thumb" of a couple of pages per day. However, that still leaves the following questions:

1.) How do you know how many pages will be required?

2.) Isn't there a significant up-front analysis phase BEFORE any pages arecreated? (Isn't the common rap against programmers about prematurely jumping into implementation just as appropriate to Technical Writers?)

Tom Murrell responed:

My first "rule-of-thumb" for estimating a documentation project is that it will cost 20% of the development budget. It's amazing how accurate that turns out to be.

1.) How do you know how many pages will be required?

2.) Isn't there a significant up-front analysis phase BEFORE any pages are created? (Isn't the common rap against programmers about prematurely jumping into implementation just as appropriate to Technical Writers?)

My second rule-of-thumb is that I can't do more than 10 pages per day of finished product. For every project I've been able to look back on, I find that is probably a bit optimistic, particularly when doing "new" documentation. That is, if I'm starting from the beginning I average maybe7 pages per day when all is said and done.

Of course, most of the time I'm given a due date and a set of deliverables that don't fit either of my rules-of-thumb. Then I do as everyone else does...the best I can in the time allotted.

Bonnie Granat responded:

You have a story to tell.

You have to list each feature and estimate how many pages you need to tell
the story of that feature.

When you are finished listing the features and the time estimates, total the
number of pages and do whatever arithmetic seems best applicable to your

Laurie Morgan responded:

To estimate the number of pages in a manual for a software project, I try to
use a combination of things:

- number of screens (or windows) in the program - which hopefully can be obtained from design docs

- number of function points in the program (which I try to relate back to user tasks that need to be performed)

This means that the programmers must have done some up front analysis about what they are going to develop. Based on previous experience with the complexity of the user tasks associated with using the software, I assign X number of pages per screen or per function point. Function points are important since one screen may be used to perform several functions.

Sandy Harris responded:

One way to estimate:

Take total developer time used and divide by five.

Of course five is a variable. The only study I've seen was some years
back, in a book by doc folk from one of the 7 in "IBM and the seven dwarves" Honeywell? Burroughs? GE? They'd measured doc/development ratio in many companies and got values from three up to nine.

Their shop was the only nine; they attributed it to sensible automation, e.g. tech writers get copies of all bug reports and tech support email for products they're responsible for, automatically.

Sarah Lathrop responded:

You might want to check out the article "Stop Guesstimating, Start Estimating!" on this web site:

Sarah Lathrop responded:

JoAnn Hackos covers that in her book "Managing Your Documentation Projects." She also has a new book out called "User and Task Analysis for Interface Design," which I covers the process more in depth. I just got that book and have not gotten into it very far so I can't comment on it. I've worked at a number of companies where I was expected to do just what you are struggling with: give estimates without having any idea of the scope of my project. I didn't know what
the audience needed and getting that information was not in the budget. I basically felt I was pulling numbers out of the air or trying to figure them out based on the number of fields on a screen I had to document. As a fairly new writer I had no prior experience to draw from and I was usually way off the mark.

I am now a lone tech writer in a company that is interested in setting up procedures for doing documentation for a new product. In my planning document, I am building in the user/task analysis phase and my boss is supporting me in this. I have an advantage here because our software is for internal use so my users are fellow employees. However, JoAnn's first book gives a variety of
methods of getting the information when the users are not under the same roof.

JoAnn's company offers workshops on doing a user/task analysis. See her web site at As you might have guessed, I am a big fan hers. I had the privilege of taking a
class from her and she knows what she is talking about because she has
first-hand experience.

Don Lenk responded:

The rule of thumb I've used has changed over the years from 8 hours per page to 4 hours per page. This is mostly due to increased efficiencies in the mechanics of development
and production . These estimates include the whole process from requirements analysis through delivery.
(Management time is an extra 10% or so).

Suzette Seveny responded:

Since I have never been able to estimate the number of pages required BEFORE starting a project, I base my estimate on the number of topics. Each topic seems to be somewhere between 8 and 15 pages, and I estimate 3 days per topic for the final manual. I usually have a draft ready in 60% of that time. I have gone back and measured actual time taken, and find that I am usually with
a couple of days of my estimate, which seems fairly good to me.

In preparing my estimate, I complete the following steps:

1. Prepare a list of tasks/topics.
2. Identify primary users of each task.
3. Prepare a User:Task matrix.
4. Identify required documents.
5. Review with project team to obtain consensus.
6. Estimate time per document (3 X # of topics).
7. Schedule review date for first draft (60% of #6).

Get Your Private, Free Email at

Previous by Author: Estimating a Task Analysis
Next by Author: Defined Process For Creative Thinking?
Previous by Thread: what do you do?
Next by Thread: Re: Re: Off Topic: How do I...

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

Sponsored Ads