Re: Estimating Online Help Schedule

["Jeanne A. E. DeVoto" <jaed -at- jaedworks -dot- com>]

At 2:59 PM -0800 3/28/2000, emmy_aricioglu -at- hp -dot- com wrote:
>How do you estimate how long it will take to create online help
>(as I've defined above)? Do you count backwards from the release
>date to find your "begin development" date? Or do you have a
>firm development schedule that you adhere to and then use other
>tactics to manage expectations, if you get my drift <g>?

I usually create a development schedule whose stages are conditioned on
product milestones. For example, a schedule might go something like this:

- Release of first draft: 2 weeks after software goes alpha
Additional features added after the software goes alpha WILL cause the
documentation to slip.
- First review meeting: 1 week after release of first draft
- Release of second draft: 3 weeks after user-interface freeze
Changes to the user interface after the user-interface freeze date WILL
cause the documentation to slip.
- Final review meeting: 1 week after release of second draft
ALL comments from development and marketing are due at the final review
meeting. Comments received after the date of the final review will not be
incorporated. Any changes to the documentation content that are required
after this date WILL cause the documentation to slip.

You get the idea. It usually is not necessary to pound the idea into the
team's head with quite this much force, but you need to make your
dependencies clear so that there are no surprises. Making your
documentation milestones depend explicitly on product milestones helps
establish exactly what you depend on, and eliminates the potential for
unpleasant situations such as the following: "Your schedule says you'll
have the final draft ready by August 5th. What? You say the software didn't
go beta until August 4th? But your schedule *says* August 5th, and I just
*assumed* it would take you only one day..."

(In point of fact, if there were a minor user-interface change or new
comment the day before the docs went final, it would get incorporated and
there wouldn't be a schedule slip. "Underpromise and overdeliver" in this
case ensures that everyone's expectations of you are realistic and that you
don't end up pulling an all-nighter because of someone else's screwup - or,
at least, that if you have to, your management sees it correctly as effort
above and beyond the call of duty, instead of thinking it's your own fault
for "missing the schedule".)

--
jeanne a. e. devoto ~ jaed -at- jaedworks -dot- com
http://www.jaedworks.com