TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Subject:RE: The last minute crunch From:MList -at- chrysalis-its -dot- com To:schoy -at- us -dot- ibm -dot- com, techwr-l -at- lists -dot- raycomm -dot- com Date:Thu, 28 Aug 2003 15:42:24 -0400
Samuel Choy [mailto:schoy -at- us -dot- ibm -dot- com] said, plaintively:
> I had a big deadline last week. I got it done on time, but by
> golly, I had
> to work a gazillion hours of overtime the last two weeks to
> accomplish it.
> It seems that with just about every deadline I have, I go
> through the last
> minute crush.
On the principle of "Don't do what I do, do what I say...":
1) Establish as a principle of law, on the order of the
law of gravity for severity and amenability to appeal,
that not everybody gets to have the last word. (Do this
by negotiation, preferrably outside of crunch time.)
2) Establish an order for who gets to sign off on documents.
Do this by letting the principles fight it out among
themselves. You need this, because everybody has opinions
about various aspects of the document (some overlapping),
but somebody has to be the last one to submit a review
of the latest possible version of a document, and sign off
the changes. The corollory is that some people will have to
accept that changes (usually small and technical) will
occur after they have signed off.
3) Usually marketing and certain others are among those who
don't need to be in at the end, so prepare a version of
the document as early as possible. It should contain as
much of "reality" as you can manage, based on previous
versions (if any), on engineering documents and requirements
documents. That is, it should have the look and feel that
marketing wants, it should describe the major features and
elements of this release, and so on.
4) Create a publicly accessible directory structure, with a
directory for this current project. Partway through the
project schedule, begin dumping copies (I use PDFs) of
the required documents in there, and send e-mail to all
parties who might possibly be interested, alerting them
that review copies have arrived. I usually have only six
or eight customer documents per project, so I dump them
all in one directory reserved for that release. You can
make fancy sub-directories if that will add value.
Your e-mail should also contain the review schedule for
this project, with the most proximate ones highlighted
in some way. That's probably marketing, but how many
people have signing/withholding rights on your docs,
Note: They don't really HAVE to sign by the particular date,
you are just giving them notice that AFTER that date, they
MUST be ready to sign, having had ample time to review. That is,
you let them know that your ample early warning ensures that
their inevitable approval does not need to be a hurried
5) Keep dumping new copies (overwrite the old) into that
directory, as the project progresses. If the nature of
the project is that some docs are in a nearly-finished
state, only days after the start, but others must
remain skeletons until near the deadline, TELL people
that, and EMPHASIZE that the nearly-done ones must
therefore be reviewed, signed and out-of-the-way before
6) Keep a log of changes -- it can probably be based on
the requirements doc, to begin with. Later, match your
document changes (as much as possible) to Issues or
ECRs or whatever you call them, by number. The log goes
in that same directory. Anybody who's doing reviews can
look at that summary of what has changed and why.
Each time you dump in revised documents, update the log.
If there were particularly nasty Issues that you addressed,
refer to them in your every-few-days "New review copies
are in the \\big-server\company-shared\reviewdocs\projY
directory" e-mail. Nobody must ever be able to say
something like "There are 2500 pages of documents; how
am I supposed to know if issues are being documented
and if feature-adjustments are covered?"
Note: This again is where the log is handy. If this is
going to be release 5.0 of your product, then there's a
lot of documentation that has previously been read and
approved. Your log should show what and where the changes
are, so that reviewers can go directly to those places.
You don't need to log every punctuation change, just the
substantive ones. "Issue 2319 - Broken Pipe on Reset - is
addressed in Chapter 5, section Blah of the User Manual,
and in Chapter 9, section Blee of the SDK Guide."
If you are a user of the Issue/Bug-tracking system, then
you have probably put a sample of your text into the
Issue notes before resolving your part in it. Cut and
paste the same text to the log file that your reviewers
will see. They may not even need to open your actual docs,
they'll have so much confidence in you.
7) If anybody is dragging their review feet, be public in your
announcement e-mails, that they are dragging their feet.
Use diplomatic language that doesn't accuse, so much as
sympathize, while offering helpful suggestions such as
that they DELEGATE the task, if they're just too damned
important to meet their own commitments!! (whoops!, was
I frothing, there? sorry).
Make it clear that when the project enters the final
sprint, the people who previously agreed to review
earlier drafts will be DEEMED to have approved, and
review comments will be accepted only from those who
have legitimate (previously agreed) reason to be the
later contributors (like PV/QA or the code-monkies who
are implementing fixes for problems found in testing).
7) When somebody (like marketing or PLM comes around late
in the game with major changes that just absolutely
need to be incorporated, to satisfy the huge customer
for whom the project is being done... tell them that
you can fit it into your schedule only if they agree
to be extra available and accomodating with respect
to re-review (they already reviewed once, didn't they?)
and approve the changes... or they must trust you and
PV/QA to get it right, and waiver the re-approval.
If you don't get stuff like that in writing, PUT it in
writing as "My understanding of our 3:45pm standup hallway
conference is that the bump-bump capability is being
inserted and that the boogie-woogie capability is being
delayed until the next project in order to finish on time,
and that PLM waives further review of documents for this
The only documents that might be changing at the post-last
minute are release notes or ReadMeNow, or wherever you
put discovered-at-the-last-minute horrors. Structural
stuff like the tables of what version of hardware goes
with what version of firmware goes with what version
of software, and tables of capabilities, or of features
enabled and disabled for this and that model.... all of
those were completed long ago, weren't they?
At any rate, systematic public nagging that takes the
form of updates is very (hate the word) pro-active, and
ensures that anybody who makes themselves unavailable
is making themselves -- not you -- the bottle-neck. You,
after all, have been bending over backward throughout
the project to keep people informed and up-to-date.
Public is important. CC your boss, and if there's a
mailing list for the project, use it, or an appropriate
Here's another thought:
Lot's of people, whether they get to sign or not, want
to have input to the end-user documentation. However,
they fall into two camps -- project people and "I have
another job" people.
Project people are the PLM (Product Line Management)
and project management people, the designers, the
coders, the grunt labor that makes it happen. They get
assigned and have a stake in this particular event.
"I have another job" people are generally the Customer
Support and Sales Engineering people. They are very
important to you and to the improvement of your docs,
but they can't be signers. They are constantly being
interrupted by phone calls and trips to service
customers. Yet their input is often some of the most
valuable. What to do?
Well, you give them the most recent RELEASED versions
of a product document set and tell them that their
input is more than welcome... just not at deadline
time. Because your project documents are public, the
Customer Support people CAN read them and make comments,
but for the most part, they should likely be one release
behind, and operating at their own schedule, between
the customer calls and emergencies. That way, their input
still gets used, but it doesn't hold up any particular