Estimate Information

[jowen2 -at- CSC -dot- COM]

Hi All,

Had a couple of folks ask me for the information I've compiled on project
estimation - so I'm posting the responses I got to my question.

-Joy

***

I'm no expert (so why bother opening my big mouth?), but I have heard many
times this rule of thumb...

New text: 3-5 pages a day per writer
Fixing legacy text: 7-10 change pages a day per writer

Of course, if you're converting from Word to Frame, that will add
considerable time with reformatting and template development...you'd be
best
to judge that.

*****

Joy,

During the STC Conference, I attended a workshop given by Sarah Lee
Hauslinger (email sarahlee -at- contentmanage -dot- com, URL www.contentmanage.com),
and Grant Hogarth (email grant -at- onyxgfx -dot- com), who gave an excellent
presentation on project management and documentation estimates. They've
uploaded have information and an estimate spreadsheet on Sarah Lee's
website.

Also, you may want to explore JoAnn Hackos' website, www.comtech-serv.com,
as well as another website offering a downloadable program of her
Dependency
Calculator: www.execpc.com/~knp/TechCom/Dchelp.html.

Good luck!

*****

Howdy!

     It varies.  In the Software Documentation classes I taught, it ranged
     anywhere from 1 page/day for the traditional study/analyze to pick-up-
     the-books-at-the-printers process to 2 pages/day documenting working
     GUI applications with screen shots and producing final output on laser
     printers and copiers.

     BTW, for editing figure 50 pages/day for heavy technical info. with
     picky highlighting requirements to 75 pages/day for easier
     screenshot-laden info.

     Don't be surprised if management thinks these times are too
     slow...reality irritates them!

     Hope It Helps

*****

Technical writers can control what we can control. One of these is to
know how much time it takes us to do things like:

*       Research and design
*       Preliminary reading
*       Kick-off meetings
*       System overview with SME
*       Interviews with SMEs
*       User interviews/task analysis, if allowed
*       Designing prototype pages
*       Creating or modifying template
*       Designing content outline
*       Writing design document
*       Presenting design
*       Writing and editing
*       First draft
*       Review process
*       Second draft
*       Review process
*       Final draft
*       Review process
*       Production/Printing, if required

We have found it useful to add the actual totals for these items
together and divide the hours by the number of pages in the final
document. Totals like these for one project only can be misleading
because of variables like:

*       % of system changes that affect drafts
*       availability/lack of availability and cooperation of SME's
*       review delays by client
*       bureaucratic instrusions
*       politics
*       changes in client perceptions of what's needed
*       technical problems
*       life (Murphy's law)

However, after keeping these numbers for a year or more, the variables
begin to average out, so that the writer begins to get a realistic
"feel," based on numbers, for how long things take under specific
conditions. These conditions can be used as a basis for querying the
client prior to a project and for estimating. In estimating, the
conditions and assumptions the writer is making in the estimates should
be stated clearly in writing, along with a statement that if the
conditions and assumptions change, the estimate will vary in proportion
to the changes.

This approach gives a rational basis for adjusting project budgets and
schedules as conditions and assumptions change.

******

The problem with estimates is that you have to know how many pages you will
write. I don't remember the specific dependencies, but things like quality
of the written text will still be relevant.

Further there is the issue of which estimate we are talking about, and how
the estimate is being used. Usually, the initial bid is a gut-level guess.
It has to be a competitive bid, since you want to win the job. And, the
hrs/page number should be less than the numbers published as industry
standard. This bid needs to be close. It does not have to be correct. This
bid is made strictly on the basis of the RFP. No detailed analysis of the
job is made. After you win the job, and you are on the customer's clock,
you
do a detailed investigation to quantify how much work needs to be done. If
it cannot be done under the numbers established in your bid, descope the
project, so that it can be done within budget, and on schedule. There may
be
a need for additional estimates as the project becomes more defined.

If you have not started to keep your own history database, start today. A
history database contains the number of pages written on a given day and
the
number of hours spend writing them. All processes in the publishing process
can be metriced this way. Do not use these number for comparing employees.
Establish a running average. At some point the numbers will converge. You
will no longer need to collect data once the average converges. You will
need to do data collection again anytime a process or tool changes. And,
you
might want to collect the data to find situations where your production is
anomolous.

The averages you got from your history database should be the ones you use
in your estimates. They show your true productivity. How you account for
overhead and profit in your estimates is up to you. In addition, some
companies, stupid companies, get a number and then give themselves a 5-15%
chance of failure by reducing the number by that percentage. This is
supposed to motivate. But, projects cannot depend on motivation.

The industry average for production is 4 hours per page. For help it is 1
hour per topic with an additional hour for context-sensitive topics. In
Stulz'es The Business of Writing, he breaksdown all publications tasks:
writing, editing, production. The book is from the pre-DTP period, and is
probably out of date. In it he uses different numbers, because the real
numbers are a trade secret. Estimates can also be based on function points
and other IT based metrics. It is sometimes better to use non-Tw numbers as
they will be respected more. Casper Jones in Managing Software Risks, wrote
that .5 EP/FP, one half of a day per funciton point, was a good rule of
thumb, of course, I could never figure out if he meant internal or external
documentation, or if he meant ISV or IT environments--they are not the
same.


One thing is clear to me, if you create your history database with your
current employees, practices, and quality levels, you shouldn't have to
identify dependencies, because they get built in.

We like to think that most of our work is projects. This is not true. Most
of our work is maintenance. By keeping the original project plan, you can
come back latter and add new topics and tasks. I use a work breakdown
structure to describe the artifact, instead of the work. Then, I come back
later and add the processes (templates) that consisit of series of tasks
that create the components of the artifact. I use a color code to
categorize
the artifacts and the tasks.


*****

For the conversion, allow as much time as you would for editing - ballpark
6
pages/hour.

For the updates, calculate how many pages are affected, estimate writing at
2
pages/hour. You can probably use Hackos' calculator from there.

*****
With the Word to Frame conversion, I'd stick fairly close to the standards
in the book. We estimate time at 3.5 hrs. per page. Given you situation, 2
hours might be more accurate?

****
Hi Joy:

I do use JoAnn Hackos'method for estimating projects, including for
revisions of existing documents.

What I usually do is look at the spec, or whatever information I have about
the revision, and try to estimate how many changes I will need to write,
and
how many new pages these changes will entail.

Then I take this page count and multiply it by the hours per page rate from
the dependency calculator.

I find that I can apply the dependency calculator to revisions as well as
to
new projects.

My estimates are, on average, 90% accurate. Some projects I find I
underestimated, some I have overestimated. As I get more experience
estimating projects, I believe I am becoming more accurate.
Of course if the scope of the project changes  unexpectedly (which
happens),
all my lovely estimates and projected release dates may go right out the
window. :-(

In general, I find Hackos method to be a useful starting point. I wonder
what others' experiences are with it?

*****

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