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 Pickett wonders: <<We're trying to show our project manager the
percentage of total software development hours we need to develop the online
help system, and we need documentation from other sources to substantiate
our claim. For example, does online help development for most software
projects at most companies typically require 30% of total software
development hours? 5%? 40%?>>
We can't provide any kind of useful percentage for you, and I'd recommend
treating any percentages you hear cited with enormous caution. Consider an
exaggerated example: Dialog box A requires 1 year of research to develop a
mathematically accurate algorithm for calculating a result, and has only a
single input field that takes you 15 minutes to describe. Dialog box B takes
15 minutes to code because even though it has 50 fields, each of these
fields has a simple predeveloped function that programmers can pull from the
API (the library of functions); unfortunately, it takes you 50x15=750
minutes to describe.
See the problem?
The only good way to estimate help development time is to start with a
reasonably complete list of the interface items that users will interact
with (fields, tabs, clickable icons, radio buttons, etc.). As a first guess
at development times, allow 1 hour (entirely arbitrary figure for the sake
of example*) to document each one: that figure includes researching the
item, writing multiple drafts, changing the "final" draft to conform with a
surprise last-minute interface change, SME review of the item, and revision
to produce a final draft. Refine this estimate by adding a fudge factor to
account for life's little miseries (hostile developers, people going away on
vacation, shoddy reviews, multiple interface changes, office parties, the
roof leaks, etc.).
* So don't use that in your estimate. Use an estimate of your own
productivity, which may be higher or lower.
--Geoff Hart, geoff-h -at- mtl -dot- feric -dot- ca
Forest Engineering Research Institute of Canada
580 boul. St-Jean
Pointe-Claire, Que., H9R 3J9 Canada
"User's advocate" online monthly at
www.raycomm.com/techwhirl/usersadvocate.html
Hofstadter's Law--"The time and effort required to complete a project are
always more than you expect, even when you take into account Hofstadter's
Law."
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Check out RoboDemo for tutorials! It makes creating full-motion software
demonstrations and other onscreen support materials easy and intuitive.
Need RoboHelp? Save $100 on RoboHelp Office in May with our mail-in rebate.
Go to http://www.ehelp.com/techwr-l
Free copy of ARTS PDF Tools when you register for the PDF
Conference by May 15. Leading-Edge Practices for Enterprise
& Government, June 3-5, Bethesda,MD. www.PDFConference.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.
