RE: The last minute crunch

[MList -at- chrysalis-its -dot- com]

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, 
   anyway?

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 
rubber-stamping.

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 
   crunch.

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 
release...."

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 
sub-set.

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 
project.

Time I got back to work.

Cheers,

/kevin