document release date schedule documentation

[karyn hunt]

Oh, and one more crucial thought on this subject: When you're done doing all 
this math, pad your schedule by somewhere between 25% and 30% because 
everything that can go wrong, will.

;->

k




>From: "karyn hunt" <karyn_hunt at hotmail.com>
>To: framers at frameusers.com
>Subject: RE: document release date schedule documentation
>Date: Thu, 06 Jul 2006 20:08:40 +0000
>
>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
>>