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:The project that wouldn't end, take II From:Geoff Hart <Geoff-h -at- MTL -dot- FERIC -dot- CA> Date:Thu, 20 May 1999 10:59:08 -0400
Robert Heath picked up the thread:
<<The system is already in operation. I do not know how
long people have been using it without a manual (I started at
this company on Feb. 1 this year and have learned of the
system only in the last few weeks), but they currently are.
They do, however, hunger for the manual.>>
Count yourself fortunate that some pointy-haired boss
(unsubtle Dilbert allusion!) hasn't wondered why you need a
manual at all--and thus, why you need technical writers--if
they've been using it for any length of time without a manual.
I can just see the logic now: "If they hunger, let them eat
cake" (slightly less unsubtle, and probably apocryphal,
allusion to a certain Marie-Antoinette, who eventually paid
the price for her purported culinary recommendations).
<<It seems... We install our systems first, and write the
documentation well after... Aye-yie-yie!>>
That suggests your products are crucial enough that users will
accept them even without manuals. This is either a very scary
situation to work in, or an ideal opportunity to make yourself
a hero by getting the documentation process into synch with
the development process. ("Scary situation" and "hero" do
tend to go together, unfortunately.)
<<At this point, though, I have to agree with Bob, who wrote:
"Get that turkey out!">>
Yup. And once it's out, start plotting your revision schedule.
To be honest, it sounds like your most fruitful strategy would
be to start forming good liaisons with your development staff
and gradually start making your documentation efforts part of
their development efforts. It may take some time, but in
principle at least, there's nothing to stop you from eventually
getting the docs out the door at the same time the product
ships.
