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:Re: What do we need before passing GO... From:"Susan W. Gallagher" <sgallagher -at- EXPERSOFT -dot- COM> Date:Thu, 7 Dec 1995 14:06:53 -0800
At 2:27 PM 12/6/95, Marcia B. Reynolds wrote:
>I have a meeting this Tuesday, Dec. 12 with the head of our Engineering group,
>several engineers, the VP of Marketing, and the Director of Customer Support.
>This meeting is to establish once and for all "what the heck Tech Pubs needs"
>before we turn on the green light and begin working on the product documents.
>The documents we create include installation manuals, programming manuals,
>operating manuals, technical reference manuals, AND numerous product KITS!
>HELP!! SOS!! I would like to attend this meeting with some specifics on what
>other companies require their engineering departments to provide, prior to the
>tech writer starting the documentation. Any information would be greatly
You didn't specifically say software, just hinted, so some of this may not
What you need to get started will vary with the development process in your
organization. A functional spec, marketing requirements doc, prototype,
etc. may apply. Basically, you need to know enough about the product to
determine what type of documentation is required (user manual, reference
manual, online help, multimedia tutorial, quick reference card ... ),
enough about the product features and functions to develop a working
outline for the various pieces of the doc set, and enough about the
marketing strategy to determine who the target audience is (both customer
and end user, which is often the same but not always).
What you need to keep going includes a functioning product at each stage of
development (access to the most recent build of the software), notification
of all changes that affect documentation (user interface changes, functions
added or deleted, etc.) *in a timely manner* (very important), and one or
more technical contacts (SMEs -- subject matter experts) who can take the
time to answer questions, demo new functions (if necessary), and review the
doc set for technical content.
What you need to finish is a reasonable amount of time (which will vary
depending on the size of the product and the size of the doc set) between
user interface freeze and product production so you can verify that the
docs match the product, put the finishing touches on the docs (take the
final screen shots, refine the pagination, check the TOC and index, dot
your t's and cross your i's, etc.).
As you plan your finish, remember that paper docs require a lot more lead
time than online do. Printing-on-demand may require as little as a week to
ten days from the time you deliver to the time it becomes a book. More
traditional printing methods may take as long as three weeks. There's a lot
that you can do to online docs in that time frame, so schedule your work
accordingly. Unfortunately, there's a lot that the programmers can do that
affects the UI in that time frame, as well. ;-)
Sorry I can't be more specific. Hopefully, you can bounce these ideas
against your company's development procedures (whatever they may be) and
come up with a workable solution.
************************** NOTE NEW ADDRESS **********************************
San Diego, CA
sgallagher -at- expersoft -dot- com