Re: scheduling multiplier

[Jack Shaw <jsh -at- SOFTWARE-AG -dot- DE>]

On 12 Jul. 1995, J. Sevigny wrote:

>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.:

  Devl.:       |-----------------//----------------...

  Your doc.
     work:     |---- - - - -----//- - - -------------- ...

...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...

IMHO.

Regards,

Jack Shaw
jsh -at- software-ag -dot- de