TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
(Beth Kane asks for suggestions on how to estimate with accuracy.)
As others have said, you do need fudge factors and you do need to make clear
what's in the estimate and what isn't, and so on.
But first start with the estimate itself. You need to define the deliverable
- at least a first take at the actual outline. Have a look at the system,
find out at least the basic information on the audience, and whatever base
documentation exists. Use this information to build an outline - yes, an
outline - of your user guide or whatever it is you are to produce. (In Jo
Ann Hackos' book, she describes this as part of building an Information
Plan.) Sure, some things will change later. But your goal at this stage is
to get the best picture you can of what you will actually produce.
Next, look at each topic in your outline. (BTW, bring the outline down to
the lowest level of detail you can.) Estimate how many pages it will take
you to write each. You can do this if you've broken down the outline into
manageable topics.
So now you know this:
Chapter 1
- topic A - 5 pages
- topic B - 3 pages
Chapter 2
- topic C - 7 pages
and so on. Add them up, and you have the estimated total page count for your
doc.
Next, you need to come up with a metric, a multiplier, to use in figuring
how long it will take you to write those pages. There are so-called industry
standards, and I think Hackos includes some in her book. But you will do
better if you can be more precise.
And you can. Think back to the projects you've done before, and try to
determine what your personal average is for hours/page. And yes, do use an
average. Some projects are more complex than others. What you want to do is
get that average, which you can then further manipulate as necessary. So if
you know Captive Manual X was 100 pages and you worked on it for 2 months
(say, 360 hours), your hours/page metric is 360/100, or 3.6.
To produce a more precise estimate for any given project, adjust your metric
up or down based on your assessment of any special factors for that project.
Build your own formula; what works for me is a formula I made with the
following factors: writer ability (in your case, it's just you!), system
size, system availability and stability, quality and availability of specs,
SME availability and quality, and whether it's a rush job. I use scales of
1-10 for each. (I have slightly different formulas for training and for
help.)
So, to sum up: with an estimated page count, a metric for hours/page, and
adjustments up or down based on the specifics for the project at hand, you
can come up with a pretty good estimate almost all the time. (Hackos says
that the goal is to get within +/- 20%, and so far it's worked for me.)
Some estimates will turn out to be a little off. So you need to look back at
the end of each project and figure out why. In some cases, your formula was
correct, just the data wasn't. For example, say your actual page count
turned out higher or lower than your initial outline suggested. That's okay.
To keep automatically refining your formula, keep modifying your hours/page
metric based on the actual results from each project you do. Your estimates
should quickly become more and more accurate with this recursive formula.
Sounds like a lot of work, but it isn't as much as it sounds like, and the
best thing is, it works. Customers are very pleased when I can tell them a
project will take X hours (yes, hours, even for large projects spanning more
than a person-year) and then deliver it for a little bit less.
It's absolutely crucial, at least for me, to do it this way if I want to be
accurate. If I just used a thumb-in-the-air kind of method, I would
chronically underestimate. I guess I just want to please or something. By
forcing myself to go through the details, I eliminate that tendency for
error.
*** Deva(tm) Tools for Dreamweaver and Deva(tm) Search ***
Build Contents, Indexes, and Search for Web Sites and Help Systems
Available now at http://www.devahelp.com or info -at- devahelp -dot- com
Sponsored by Cub Lea, specialist in low-cost outsourced development
and documentation. Overload and time-sensitive jobs at exceptional
rates. Unique free gifts for all visitors to http://www.cublea.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.
