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 was recently asked to to an estimate for a new manual for our company (I
am the lone tech writer, but I have many other projects than just our docs).
We are currently porting our mapping software from DOS to NT 4.0 - big jump,
no? Well, there were NO portions of the GUI ready before last week, and the
release is April 30. The manual is currently 300 pages. (We are also
including on-line help for the first time ever!) I tried to come up with
estimates based on "Industry Standards", halved them, and still came up with
times that kept me working until July. (I was also informed that since we
were WAY over budget on recent renovations, a contractor was completely out
of the question.) So I came back to the developers and said - "I'll work
until the release and get as much as possible done." A crappy situation, but
very real world.>
But what a great opportunity to practice minimalism! (Sorry... I just
couldn't resist, since minimalism has been such a hot topic lately.) I've been
in those real-world situations, too. When faced with such a short timeline,
the challenge is to determine the absolute essentials that a user must know to
get started (a similar exercise to writing a Quick Reference Card). Instead of
trying to document every screen, every report, every function *in detail*, you
can consider documenting in detail only some representative functions. That
way you can design a useful document that can be produced in the time
available. (Otherwise, if you work on a full manual until the release date,
hoping to get as much done as possible, you end up with an unfinished document
that's not suitable to publish to customers.) If your management agrees, you
can follow up with a more complete manual later. This approach has worked for
me in the past--hope it helps!