Re: meaning & practice of a "doc freeze"

["Ned Bedinger" <doc -at- edwordsmith -dot- com>]

There used to be a .sig in techwr-l that declared
"Technical writing is like changing the tire on a
moving car."  Indeed.  Typical problem is the dev
team that proceeds by "rolling update"--that is,
they make continuous minor version changes in
response to reported bugs. This sort of
development environment leads to new additions to
the documentation at every review cycle.

I don't think that you ever want to cut off the
flow of information from reviewers and SMEs (get
it while you can) but you do need to identify a
clear cut-off point for changes to the current
version of the documentation that you have
committed to releasing on a deadline.  With
software development, this cutoff is a freeze but
really should be spelled out to reviewers in terms
that correspond to a product version, thus:

"This is documentation for version 3.0.  Any
documentation change requests must be 3.0
specific.  Changes related to subsequent minor
versions (currently at 3.0.1) will be held for the
next update to the 3.0 documentation."

Then you can tie it into the calendar:

"Current scheduled delivery date for the 3.0
documentation is 4/27/2004.  Please submit all
changes prior to documentation freeze on
4/20/2004.  Changes submitted after that date will
roll over to the next documentation release.
Thank you for your cooperation in meeting these
documentation deadlines."

To get a general agreement on the doc freeze date,
you might need to make it clear that your process
for finalizing and publishing takes X number of
hours (plus a fudge factor of 50-100% if you can
get it), and you have counted backwards from your
delivery deadline to establish the point where
they need to leave you alone to get that work done
on time.  Your fudge factor can represent any of
the unpredictable time sinks that attend
finalization.  A sterling example of the need for
a fudge factor: Recent software upgrades on your
work computer can affect your ability to predict
the time needed.

In big IT organizations, you might not ever be
expected to deliver a new document unless it is
for a major revision of the product.  There's not
any point in freezing a document such as an
ongoing minor version update.  This is not to say
that you'll never be asked for updated
documentation outside of a major revision, but the
big push to get a document (set) published to
standards would be reserved for major revisions,
and that is where you might need a freeze (aka
"drop dead" date) for your documents.

So, I think you do owe stakeholders a chance to
review everything in the document.  If they don't
want to review the final draft, fine.  They owe
you recognition as the one who knows best how much
time you need to finalize and publish it on time.

Disclaimer:  Docs are also frozen for all time
once published.  What do you expect from a
language that lets a nose run and feet smell?

Ned Bedinger
Edwordsmith Technical Communications Co.
doc -at- edwordsmith -dot- com
http://www.edwordsmith.com
tel: 360-434-7197
fax: 360-769-7059




^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

ROBOHELP X5 - ALL NEW VERSION!! 

Have you tried the latest in Help Authoring from RoboHelp?
Try ROBOHELP X5 for Free - Now with Word 2003 support, Content 
Management, Multi-Author support, PDF and XML support and much more! 

Download a free trial today: http://www.ehelp.com/techwr-l4

---
You are currently subscribed to techwr-l as:
archiver -at- techwr-l -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot-  Visit
http://www.raycomm.com/techwhirl/ for more resources and info.