Re: Techniques for Estimating Time
Hello Everyone,
I'm new to the list.
In my 8 1/2 years of doing technical writing I have
never been that good at estimating time required on a
project. Primarily because it has rarely been asked
of me for many reasons.
Can anyone comment in detail on the technique(s) you
use to give the most accurate estimate possible and
any possible caveats you warn your clients of?
Anthony,
The problem is always in the details. If the project is new you have no background on complexity or requirements other than what the specification says. And in most cases the requirements or specification document is woefully vague and inadequate. Only when the Design documents are created do enough detail begin to emerge. This is usually past the stage when you are asked to estimate time. Even then Design specifications change over development and usually don't reflect reality. This phenomena varies by organization.
Start with the audience and the purpose of the document. That will indicate what level of detail, and focus of information is required. The type of document is infered by that, and by what the organization wants as a deliverable. The customer (be they internal or external) must be satisfied. In many places you have layers of customers.
Make a rough outline of content. Using the specifications and other documents and info gleaned from design meetings or R&D, fill in subordinate levels.
At this point, you should have an idea of how much and what type of information you have to produce. Each topic of information should give you an idea of how many pages, how many screen capture, tables, illustrations might be needed to describe that topic. Once you have all this quantified you can start making estimates.
For new material, and depending upon the technical difficulty of the information, I usually use an estimate of about 2 hours per page of text.
screen captures 15 minutes each
tables half an hour or more (content driven)
Illustrations hafl an hour to 1 hour.
Edits and reviews are by per page.
1st Review I usually estimate 1 hour per page.
2nd and subsequent I cut the estimate by mulitplying the number of page by .25 and for subsequent (3rd and later iterations) by .1.
Depending upon the reliability of the specification and the history of the developers to stand by the orginal design and function, I multiply the results by .25 to .15, unforseen events.
Upgrading a version is a little easier since you have a body of work to base the estimate on. The changes or additions are figured solely on the changes using about the same estimation process.
Others use different figures, but the process is about the same. The variables include how many people are involved writing, feature creep, communication between writers and developers, and other distractions.
Scott
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
A landmark hotel, one of America's most beautiful cities, and three and a half days of immersion in the state of the art:
IPCC 01, Oct. 24-27 in Santa Fe. http://ieeepcs.org/2001/
+++ Miramo -- Database/XML publishing automation. See us at +++
+++ Seybold SFO, Sept. 25-27, in the Adobe Partners Pavilion +++
+++ More info: http://www.axialinfo.com http://www.miramo.com +++
---
You are currently subscribed to techwr-l as: archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit http://www.raycomm.com/techwhirl/ for more resources and info.
References:
Techniques for Estimating Time: From: Anthony
Previous by Author:
Re: using 3rd-party books
Next by Author:
RE: Techniques for Estimating Time
Previous by Thread:
Techniques for Estimating Time
Next by Thread:
Re: Techniques for Estimating Time
Search our Technical Writing Archives & Magazine
Visit TechWhirl's Other Sites
Sponsored Ads