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 am working for a small software development company who has decided that
the documentation department is too costly, so they've let 4 out 6 people go
and the 5th person has quit two weeks ago--that leaves me.>>
The first thing you need to do is sit down with your manager and find out
how they expect one person (and a new writer at that) to do the work of 6
writers, at least some of whom had more experience than you. Unless the
other five writers spent their days drinking Jolt cola and playing poker, it
can't be done, and you can't make that point too strongly to your manager.
Obviously, the manager is pretty clued out, and it may take a bit of work to
get an idea to sink into that thick head.
<<I am not being included in the weekly Manager's meetings>>
If you don't feel comfortable persuading the manager to invite you, then
invite yourself. The worst that's going to happen is they'll turn you away.
Rule #23 of corporate life: it's generally easier to ask forgiveness than
<<I don't have access to the latest build of the software>>
Get access. Now. There's no reason whatsoever why you couldn't persuade one
of the developers to give you access. In many cases, denying writers access
to software or the developers is not a formal policy, but just "one of those
things that happens because everybody forgot about you".
<<the biggest problem I'm facing--I'm a newbie!>>
That's much less of a problem now given that you've already asked us your
first question. It gets easier to ask the really "dumb" questions now.
Really... we don't bite. Much. <g> Seriously, though; ask lots of questions,
and sooner rather than later. Problems you solve and efficiencies you find
_now_ will save you increasing amounts of time and grief throughout the
remainder of the project.
<<What is the best way to determine whether or not I'll meet the deadline
(there are two 1,000 page manuals--printed, pdf, and online)?>>
You can't meet that deadline. Divide the 2000 pages into (say) 50 working
days (you said ca. 2 months) and that gives you 40 _finished_ pages per day.
That could easily be the work performed by 6 to 8 competent writers. Double
that time if you're going to try to make the online information useful
instead of just being a braindump of the printed manuals.
<<Without having access to the interface, should I document what's in the
external designs and verify later?>>
If you really do have to accomplish any significant amount of work within
your 2-month deadline, you need to sit down with your manager and decide
what can realistically be done with the current resources. If you're really
lucky, the existing user manuals haven't changed at all, and all you'll need
to do is document a few added features. Getting good access to the
developers and a clear idea of what these new features are should make it
possible to meet your deadline under those conditions. If there have been
substantial changes to existing features since the last version, you're in
deep trouble; not only will you have to find out what those changes are (not
always obvious), but you'll still have to handle all the new stuff.
Speaking as someone who isn't working there, and thus has no responsibility
for the consequences, it's awfully tempting to simply let the job fail as an
object lesson to management that cutting the writing staff without doing a
careful needs analysis is de facto suicide. Speaking realistically, pay
close attention to whether they pay any attention to your needs and respond
intelligently. If they do, it may be worth sticking around and helping them
develop some respect for you and the documentation you produce. Given that
they fired four writers with more seniority at the company than you, and
that the fifth writer quit, I'm dubious that your management can be
saved/educated. That being the case, cover your ass (put all your
recommendations in writing, with copies to everyone who's involved in the
project) and soldier on until you've had enough. Then remember that you've
done your best under unreasonable conditions and console yourself that at
least it's a seller's market when it comes to selling your services
"Technical writing... requires understanding the audience, understanding
what activities the user wants to accomplish, and translating the often
idiosyncratic and unplanned design into something that appears to make
sense."--Donald Norman, The Invisible Computer