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.
I agree with Andrew 100% and would also add that you should document your
time and what your actions over the next two months. In other words, cover
your butt, but get the job done. I have been there and it sounds like Andrew
Besides writing like a demon, do the following:
1. Ask for more staff, but do not agree to interview, manage, etc. This is
a hedge against management claiming they didn't know you needed help.
2. Keep all email to and from your engineers. They also will pass the buck
if this project blows up.
3. When the deadline is made (and you can make it), put together a working
plan to get the docs up to speed. Do not expect the management to give you
the time and resources to do the job. You will have just shown that you can
produce under tremendous pressure. In each subsequent release, you should
be adding the documentation/organizational features that should have been
there in the first release.
4. Get to know your engineers very well and do not be afraid of cc'ing their
managers on requests for information.
One strategy I have used to get information for recalcitrant engineers is to
camp out in their cube while copyediting or anything else that can be done
in paper format. If you hang out long enough, they will answer you just to
get you to go away. This works as long as you keep a smile on your face as
you do it. Don't get angry at the engineers; it only will build bigger
director of engineering services
btw, my 6 person staff currently is editing/writing/maintaining one manual
set (9 manuals) of 6000 pages, one manual set (5 manuals) of 3500 pages, one
manual set (2 manuals) of 2800 pages, and one standards spec of about 1000+
pages. We are all very used to working in high velocity mode under very bad
information conditions. It can be done and you can make a career out of it
(as Andrew points out).