document release date schedule documentation
Before we started doing serious documentation estimates, we used the following formula. The developers describe every change to the software in "worksheets". We used to multiply the number of worksheets for a release by pi to get the number of required documentation hours... And guess what, it actually worked out pretty well... Now that we do serious estimates (with MS Project and all), we arrive at a number more or less equal to the number of worksheets multiplied by pi plus the number of hours spent on estimating... :o) -Niels -> -Original Message- -> From: framers-bounces+nfa=maconomy.dk at lists.frameusers.com -> [mailto:framers-bounces+nfa=maconomy.dk at lists.frameusers.com] -> On Behalf Of karyn hunt -> Sent: 6. juli 2006 23:08 -> To: framers at frameusers.com -> Subject: RE: document release date schedule documentation -> -> 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" -> >To: framers at frameusers.com -> >Subject: RE: document release date schedule documentation -> >Date: Thu, 06 Jul 2006 20:08:40 + -> > -> >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" -> >>To: -> >>Subject: RE: document release date schedule documentation -> >>Date: Thu, 6 Jul 2006 14:52:54 -0400 -> >> -> >> -> >>On 7/6/06, Gillian Flato 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 -> >&g
Re: document release date schedule documentation
I usually base the documentation deliverable schedule on a critical date from the software development schedule... like 30 days after UI freeze, or XX after functionality freeze. Art On 7/6/06, Gillian Flato [EMAIL PROTECTED] 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? -- Art Campbell [EMAIL PROTECTED] ... In my opinion, there's nothing in this world beats a '52 Vincent and a redheaded girl. -- Richard Thompson No disclaimers apply. DoD 358 ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
RE: document release date schedule documentation
On 7/6/06, Gillian Flato [EMAIL PROTECTED] 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 [EMAIL PROTECTED] for cases where you have received this email and were not the intended recipient. ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
RE: document release date schedule documentation
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 [EMAIL PROTECTED] To: framers@frameusers.com Subject: RE: document release date schedule documentation Date: Thu, 6 Jul 2006 14:52:54 -0400 On 7/6/06, Gillian Flato [EMAIL PROTECTED] 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 [EMAIL PROTECTED] for cases where you have received this email and were not the intended recipient
document release date schedule documentation
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? Thanks, Gillian Flato Technical Writer (Software) NANOmetrics, Inc. 1550 Buckeye Dr. Milpitas, CA. 95035 (408.435.9600 x 316 7 408.232.5911 * gflato at nanometrics.com This message (including any attachments) may contain confidential information intended for a specific individual and purpose. If you are not the intended recipient, delete this message. If you are not the intended recipient, disclosing, copying, distributing, or taking any action based on this message is strictly prohibited.
document release date schedule documentation
I usually base the documentation deliverable schedule on a critical date from the software development schedule... like 30 days after UI freeze, or XX after functionality freeze. Art On 7/6/06, Gillian Flato 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? > -- Art Campbell art.campbell at gmail.com "... In my opinion, there's nothing in this world beats a '52 Vincent and a redheaded girl." -- Richard Thompson No disclaimers apply. DoD 358
document release date schedule documentation
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" >To: framers at frameusers.com >Subject: RE: document release date schedule documentation >Date: Thu, 06 Jul 2006 20:08:40 + > >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" >>To: >>Subject: RE: document release date schedule documentation >>Date: Thu, 6 Jul 2006 14:52:54 -0400 >> >> >>On 7/6/06, Gillian Flato 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 >>
