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