Estimating Complex Projects? - Responses

["Anthony Markatos" <tonymar -at- hotmail -dot- com>]

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
situation.

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: http://www.fredcomm.com/

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 http://www.comtech-serv.com/  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 http://www.hotmail.com