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.
Estimation of timelines for documentation projects?
Subject:Estimation of timelines for documentation projects? From:"Hart, Geoff" <Geoff-H -at- MTL -dot- FERIC -dot- CA> To:"TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Mon, 6 Oct 2003 09:40:38 -0400
Vlad Dracul wonders: <<In my experience, one is best placed to estimate the
time required for a documentation project only if one has implemented a
similar project in the past. If such experience is not available, how can
one come up with a reliable estimate?>>
If you don't already have records on how long it takes, start creating them
now: Pick a topic you can document in a couple hours, document it, figure
out how long it took, then use that productivity figure as your starting
point. By the end of those 2 hours (a trivial investment of time), you'll
have your first productivity estimate. Move on to the next topic and repeat
the process. You'll undoubtedly end up with a different productivity.
Estimate an average productivity (total time divided by total number of
topics). Repeat as necessary until each consecutive new productivity value
you add into the mix stops changing your average by a significant amount
(i.e., when the average stops changing, you're basically done).
That's obviously pretty crude. If you can come up with a more precise
estimate (e.g., by breaking each topic into subtopics and calculating a
productivity per subtopic, per number of fields in a dialog box, per number
of developers you have to interview, etc.), you'll come up with much better
estimates because you can adjust the estimate to the difficulty of the task
rather than simply counting menu functions and multiplying by your average
productivity.
Start with a crude estimate, with lots of room for error built into it, then
progressively improve your estimates as you gather more data. The key is to
_start_ tracking times and productivities. You'll have revise your timeline
many times along the way, but that's why Uncle Bill created MS Project.
--Geoff Hart, geoff-h -at- mtl -dot- feric -dot- ca
(try ghart -at- videotron -dot- ca if you get no response)
Forest Engineering Research Institute of Canada
580 boul. St-Jean
Pointe-Claire, Que., H9R 3J9 Canada
"Work is of two kinds: first, altering the position of matter at or near the
earth's surface relative to other matter; second, telling other people to do
so. The first is unpleasant and ill-paid; the second is pleasant and highly
paid."--Bertrand Russell
RoboHelp for FrameMaker is a NEW online publishing tool for FrameMaker that
lets you easily single-source content to online Help, intranet, and Web.
The interface is designed for FrameMaker users, so there is little or no
learning curve and no macro language required! Call 800-718-4407 for
competitive pricing or view a live demo at: http://www.ehelp.com/techwr-l3
---
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.