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.
Subject:Re: Estimate for On-Line Project From:sanders_j -at- TBOSCH -dot- DNET -dot- GE -dot- COM Date:Tue, 21 Sep 1993 08:46:08 EDT
Well, since I can't seem to convince the mail to send rather than reply,
I'm afraid everyone will have to enjoy my opinion.
There was an extensive discussion some time ago about online documentation,
and I have talked with a number of people who have setup online docs
specifically. Since this is a first-time effort for your team, you should
expect, right off the bat, that there will be a lot of extra time just
for startup issues, not the least of which is learning the software.
There are two important first steps, as I see your situation: Research
First your 1.5 people have to do research into online help, if they haven't
already. From what you said, they don't have much experience with it.
They should try to get an overview of the techniques and theory behind
online help, and some practical advice on how to plan such projects ahead
At about the same time, your and/or your programmers (company's) should
setup to convert the text of the current documentation into a format
readable by Frame. It the best possible scenario, it will have a similiar
appearence to the original paper documents. Your 1.5 people can than
begin massaging it from there. At the very least, this step will give
your team something to work from as an information pool, and cut down
their mundane involvement significantly.
The next step is planning. This should take the most time, since what
you are really doing is developing an application. Make sure the team
is familiar, ahead of time, with what the Frame tools can DO, not simply
what they WANT to do. The hours spent on planning now translate into
minutes at the computer. If you don't plan, your help could turn out
looking very half-baked.
The third step is execution. Your team has to put everything together.
My understanding of the Frame tools suggests that the actual hyper-
coding task is fairly simple, if somewhat time consuming.
The last step is testing/revision. Get some people around the office
to use the help as part of their use of the application, or whatever
formal/informal testing procedure you can use. It is vital for someone
other than the editor or the application authors to do the testing.
That's what you have to do, as I'm sure you are well aware. What you
really wanted to know about was estimating. Ok. This depends on several
things. First, were you able to get your documentation into a nice,
workable online format directly from the Ventura version, or was the
conversion something that the 1.5 people are going to have to spend time
on to format? If they have to format it, it's going to take a lot of
extra time. A good signpost someone once told me for paper output was
to plan on about 1-2 pages of documentation a day, allowing for writing,
revision and review. This is a good estimate if your team has to format
as well as hypertext. If the docs are converted with formats, and your
team has a good plan ahead of time, than a lot of their work is already
done. The page count is not real exact for online help, since "pages"
almost really don't apply, but it might give you a feal for solid figures
if you work from your original page count. (The 1-2 pgs a day is for one
Well, looking back, this doesn't help you much in estimating as much as
planning ahead (sorry), but hopefully some of the ideas will help. My
experience has been largely on the receiving end of an estimate rather
than the producing end.