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.
Gwen Barnes had a good list of what you needed to know to manage projects rather
than crises:
>1. When it has to ship
>2. When the books have to be ready
>3. How long it takes to print the books
>4. Your drop-dead camera ready date
>5. Which printers you're going to bid it out to
>6. Who's going to sign off on the final manuscript
>7. How long it takes to prepare a good index
>8. How long it takes to make any necessary issues resulting from
engineering review
>9. How long it takes for the engineers to review the final draft of the
manuscript
>10. How long it takes to get the first draft ready for engineering
review
>11. How long it takes to write the first draft
>12. When you get to see the product you're writing about for the first
time.
I'd like to add number an item:
11. Make sure you know who is supposed to be in charge of the document
and what your role is.
I've worked in extremely pressured production environments, particularly
proposals worth hundreds of millions of dollars (and, in one case $2.5
billion), and my biggest nightmare has been either cases in which the
person who was supposed to be in charge would not or could not manage
the project, or those in which I was given responsibility over the
document, but not the authority to get it done (that is, the authority
to make others do their jobs). I've dropped from my client list clients
who have put me in the situation more than once.
If I have no control over management of the document, I at least try to
make clear who is supposed to be in charge and just what my
responsibilities are. This saves a lot of grief in the middle of the
project and recriminations later. I always joke with my clients that I
know they're going to be yelling "the temp did it" the minute I walk out
the door and that's OK; I'm convinced that's one of the reasons
organizations hire temporary help, especially for projects that they
know are unredeemable. However, I feel better when I know I've done my
best and my clients know it, too (whatever they may say to their bosses
to save their corporate butts).
