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.