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.
>Let's say it took 30 days to develop these 10 screens/menus. I'm now up to
>50 work days to document 10 screens/menus? At 5 days/week that gives me 2.5
>months! I don't want to seem harsh here, but that's insane.
Whoa, wait a minute Josee. I didn't say this was the time just
to document the screens/menus. I said that the screens/menus changed
and/or added were the basis of a user interface factor. It is
highly unlikely that the changes needed to doc. those screens/menus
are the _only_ related changes you have to make. You also might have
- introductory/conceptual "big picture" info.;
- function description changes related to the change;
- product installation/tuning changes;
- user message/code info.
The point of taking the screens/menus is solely a beginning for
factoring in the user-sensitive effort, based on some barometer of
the developer's changes to the user interface.
You also said:
>I just updated a manual where 57 windows have been modified/added (not
>counting dialogs, message boxes, print preview windows), all in 101.75 hours
>(that's just over 12 work days). That included learning the software (since
>it was just move to our dept.), a major restructuring of the document,
>adding index entries as the previous TW didn't have any, as well as
>step-by-step instructions on how to perform tasks.
All well and good: did you begin when the development effort began, or
did your effort _follow_ the bulk of the development effort? What about
the results of beta or other testing? Wasn't there any impact from that?
If your activities were paced by/with the devl. activity, how could you
help but have to march to the devl. music? To wit, your activities are
probably parallel to devl., but sporadic. E.g.:
...where the "- - -" portion is, likely as not, lulls where you are
busy with other parallel projects, right? That's why I add in the
devl. time _in_addition_to_ the user interface factor; because in
most cases, your doc. work is paced by the devl. activity. In fact,
the bulk of your work comes _after_ the back side of the devl. slope
curve. And if you're doing quality testing, a good bit of it is likely
to come then--late.
As for taking 30% of the overall devl. activity as doc. time, super.
But a percentage of _overall_ devl. time isn't what was asked for.
What WAS asked for was a multiplier relevant to the "development-
only" effort, similar to that cited for Quality Assurance. Sure,
my hair-brained "screens/menus plus devel. time" multiplier is
phoney. It's just a starting point, like I said.
But I can cite project after project that would blow your "30%" rule
right out of the water. I'm working on one now that actually reduced
the amount of user function, restructured almost all remaining function
into completely different user scenarios--in short, not much new, but
everything repackaged from the previous release. Devl. effort was
moderate, but I have to jack up the cover and drive a virtually whole
new book underneath it. I'd hate to have to be held to a percentage
of devl. effort on that one, boy...
But then, you closed with:
>We don't currently estimate our doc. time based on dev. time. We just make a
>wild guess based on previous projects.
Aha! And therein lies the truth. Such "wild quess" estimates are
experientially based and neither wild nor largely guess. And, they're
a damned sight better than a devl.-related "multiplier", which is
as phoney as it gets. Of such "wild guesses" are the better plans made...