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:Two documents from one source From:Tim Altom <taltom -at- IQUEST -dot- NET> Date:Sat, 13 Jan 1996 20:57:00 EST
>Rick Lippincott replied to a previous post:
>>We found that it simply wasn't possible to produce one manual that met both
>>needs, for the following reasons:
>>1) The students need to know certain aspects of the equipment because they
>> are seeing it for the first time. This information isn't really relevant
>> to an operator who has even minimal experience.
>>2) The instructors need to present some highly technical information (such
>> as schematics) that are not used by the routine operator.
>>3) The operating manual has complex and detailed procedures that would
>> overwhelm the novice student.
>>Another disadvantage is that if the manual has to "serve two masters" you
>>will find that you're forced to revise and update it more often. There are
>>times when procedures change, and even though it may not impact the training
>>school the instructors still get a revised manual. On the other hand, a small
>>hardware change might not have been covered in the maintenance-driven
>>portions, but the instructors may have a valid need to show "all
>>of a system.
>That's a major stumbling block if you're trying to just produce a single
>manual for both purposes. We've had good success with FrameMaker's
>conditional text feature. We make a master document that contains both
>subordinate documents within it, then print out one or the other by turning
>on/off conditional text. It makes maintenance and updating a lot easier and
>The major stumbling block we've found isn't technological at all, but
>procedural. It takes much more meticulous planning than two manuals, and it
>REQUIRES that all responsibility be vested in a single project manager with
>true management authority. No "coordination" between departments and
>managers. It won't get done that way. The team approach is essential, too,
>so that training and technical writers are working as closely together as
>possible. Put them in the same room, if possible. And make sure there's an
>editor on the project to smooth down seams and take the heat. You'll need a
>strong template and meticulous preplanning. The upfront costs, therefore,
>are much higher than for two manuals that can be merely knocked together.
>But the effort of maintaining two books that drift apart is much, much
>higher than the cost of maintaining one.