document release date schedule documentation

Fri Jul 7 00:55:42 PDT 2006

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" <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
-> >>
-> 
-> 
-> _______________________________________________
-> 
-> 
-> You are currently subscribed to Framers as NFA at maconomy.dk.
-> 
-> 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/nfa%40maconomy.dk
-> 
-> Send administrative questions to lisa at frameusers.com. Visit 
-> http://www.frameusers.com/ for more resources and info.
-> 