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" <[EMAIL PROTECTED]>
To: [email protected]
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" <[EMAIL PROTECTED]>
To: <[email protected]>
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
_______________________________________________
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.
