document release date schedule documentation

[karyn hunt]

I'll second what Roger said and add to it. Hoboy, have you hit on a HUGE 
subject here. A few thoughts:

1. The industry standard is four hours per page. That may seem like more 
than you need, but when you consider the time needed to understand the 
feature, write it, get screenshots, have engineers review it, correct it, 
proofread/spellcheck it, then check it in to source safe, this is a good 
number.

2. I figure that one GUI screen translates to about one page of 
documentation. Or each "feature" can translate to between one and four pages 
of documentation, depending on how your company define's a "feature." 
Another way to guesstimate is that two or three pages worth of engineering 
notes can translate to about one page of documentation (users rarely - if 
ever - need to know the behind-the-scenes stuff explained in engineering 
docs). So if they can produce a PRD or some engineering docs, you can use 
these guidelines to reach a time guesstimate.

3. ABSOLUTELY figure review procedures in your timelines. Guesstimating that 
is even trickier. I demand a five-day turnaround and insist that my manager 
enforce this for me if engineering, QA or customer support isn't adhering to 
it. Allow yourself half-an-hour per page for correcting the inevitable 
mistakes/misunderstandings that find their way into docs in the first 
iteration. So add an extra week or two for the review process.

4. Consider folding in a second round of reviews b/c oftentimes, the changes 
you make wind up being wrong. So fold in a few extra days for that.

5. Create a spreadsheet with all features listed, the time guesstimates 
needed to doc each one, and the begin/end dates for each one, and the time 
allotted for the review procedure. Send that to your manager, the 
engineering manager and the product manager as well as anyone else who is 
tracking your work.

5. Educate everyone and anyone you can about this so there's no room for 
misunderstanding or finger pointing later on.

6. Insist that they include you on one or two of the following: Planning 
meetings, release team meetings, product management meetings or any other 
"process" meetings that will help you discern their timeline and at each 
one, let them know that planning for the docs should happen simultaneously 
with planning for feature implementation.

Believe me, been there and done that on all of these. Hope this helps.

Karyn

>From: "Roger Shuttleworth" <rshuttleworth at activplant.com>
>To: <framers at frameusers.com>
>Subject: RE: document release date schedule documentation
>Date: Thu, 6 Jul 2006 14:52:54 -0400
>
>
>On 7/6/06, Gillian Flato <gflato at nanometrics.com> wrote:
> > Guys,
> >
> > I need to provide my engineers with a document release date schedule
>so
> > they understand when I need information by. I think that they think
>that
> > they can give me info two days before the release date and expect an
> > updated manual with the release. Does anyone have something I can use
>as
> > a template?
>
>Hi Gillian
>
>I don't have such a template, I'm afraid. However, the situation you
>describe needs more than that. You need to be involved in the process
>from the beginning, so that you have input into specifications, GUI (if
>it's software), and so on. Then your documentation estimation process
>occurs simultaneously with the product development estimates. Given
>proper management of the whole project, you should be able to finish the
>docs at the same time as the product is finalized, and without stress.
>The project manager should at least be aware of your needs and the
>timing. Decent specifications will allow you to estimate and to create a
>draft ToC. From that point you can develop your docs iteratively,
>incorporating the review process.
>
>If there is no real project management, you have an education job on
>your hands which could take years if management don't get it yet. (This
>is the voice of experience!) You will need to call meetings and keep
>expressing your needs. But sensible estimating, based on requirements
>and specifications, should allow you to at least give ballpark dates for
>your various stages. There are resources around for estimating; I've
>seen industry standards set at 1 page/day (including everything),
>although we work on something less than (more than?) that - more than a
>page a day, I mean!
>
>Hope this helps, and good luck!
>
>Roger
>
>Roger Shuttleworth
>Documentation Team Lead
>Activplant Corporation
>140 Fullarton St.
>London, Ontario
>N6A 5P2
>Canada
>Tel. 519 668-7336
>Fax. 519 668-3227
>www.activplant.com
>
>-------------------------------------------------------
>
>The information in this email is confidential and is
>intended solely for the addressee. Access to this email
>by anyone else is unauthorized.
>
>If you are not the intended recipient, any disclosure,
>copying, distribution or any action taken or omitted to
>be taken in reliance on it, is prohibited and may be
>unlawful.  Please contact privacy at activplant.com for
>cases where you have received this email and were not
>the intended recipient.
>
>
>_______________________________________________
>
>
>You are currently subscribed to Framers as karyn_hunt at hotmail.com.
>
>Send list messages to framers at lists.frameusers.com.
>
>To unsubscribe send a blank email to
>framers-unsubscribe at lists.frameusers.com
>or visit 
>http://lists.frameusers.com/mailman/options/framers/karyn_hunt%40hotmail.com
>
>Send administrative questions to lisa at frameusers.com. Visit
>http://www.frameusers.com/ for more resources and info.