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.
From:Tim Altom <taltom -at- IQUEST -dot- NET> Date:Wed, 10 Jan 1996 22:06:00 EST
We've done such projects for our clients, usually in FrameMaker because of
its conditional text feature. We're doing one now. The master document will
produce both paper doc and a help file. There are lots of complications.
Each multi-output project has its own barricades, usually because you'll
want to place the master output into another tool.
The technological challenges usually yield to determination and knowledge.
The organizational and management challenges are normally the ones that will
scuttle the thing. It requires close coordination between training writers
and tech doc writers. It also requires a lot of up-front planning to control
the process. The teams (if there are more than one) must be coordinated
under one project manager. And the writers must be given strong guidelines
and style sheets. The writers will often develop in a basic tool, such as
Word, and then supply ASCII, perhaps with a markup for headings, to a layout
person, who in turn places the text into a prepared template. The template
abilities in FrameMaker also recommend it to us.
There will, of course, be at least two separate review cycles, one for
training and one for tech doc. And the separate and occasionally competing
demands of each must be balanced against the whole. That's another reason
why the whole project must be under one manager.
Success is usually measured by whether or not you can produce a document
that's acceptable to both the training and tech doc reviewers. I know it's a
subjective standard, but it's one I can live with as a contractor.
If you have more specific questions, you can email me directly.
>Our technical writing department has been asked to investigate the
>possibility of producing one document that meets training and reference
>needs. By doing this, we would be able to eliminate duplication of effort
>between our department and our training department. We would like to know
>whether others have taken this approach and, if so, whether they feel it has
>been successful. If it has been successful, how have they measured that
>success? Any information or anecdotes you can provide would be appreciated.
