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.
Kris Seguette wonders: <<I've been asked to look for information regarding
estimating documentation (user guides, training manuals and materials) time
according to system development time. My reaction is that it doesn't make
sense>>
Trust your reaction. Think of the following exaggerated but realistic
examples:
- An application that takes a couple weeks to create because it uses
pre-existing modules from a development kit, but that links hundreds of
these modules together, each with hundreds of fields and tabs and menus:
This will take an eternity to document.
- An application that takes years to create because the algorithms are
complex and require considerable basic scientific research to document their
validity, but that presents a single user-interface screen with two
data-entry fields and a "Calculate" button. Maybe an hour's work?
See the problem? There's no predictable, safe relationship between
development time and how long it'll take to write teh docs. The true measure
of how long it's going to take is a function of how many topics you have to
document, and how many elements (e.g., menu items, data fields) each topic
contains. If you can come up with a good estimate of the number of topics
and their difficulty, and have a good grasp of your productivity (how many
fields you can describe per hour <g>), then you've got a good chance of
estimating documentation times. Add to this preliminary estimate several
fudge factors to account for various problems: user interfaces that change
dozens of times and have to be redocumented each time, developers who are
unavailable to explain things and cost you a week of waiting time for each
topic, internal (and sometimes external) reviews for editorial and technical
content, and so on. Then add 10% to cover your ass. <g>
--Geoff Hart, FERIC, Pointe-Claire, Quebec
geoff-h -at- mtl -dot- feric -dot- ca
"User's advocate" online monthly at
www.raycomm.com/techwhirl/usersadvocate.html
"How are SF writers like technical writers? Well, we both write about the
things we imagine will happen in the future!"--Sue Gallagher
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.comhttp://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.