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.
Yeah, but no. Similar but not. My experience says keep things simple or
loose people's attention. This, in your case, includes the field trainers
as well as the clients. Why your documentation needs to be customized is
slightly understandable, as our current product is highly customized for
each client. However, new to the co., I have not yet encountered the need
to customize the documentation.
If "modules", if I may use the term, are standard from system to system,
then I would say separate your documentation into discrete documents -
inother words, create a user manual for each small piece a client purchases
or uses, so you, document people, can pick and choose which books or
booklets, maybe, to send out wtih the product. It is highly likely that
these smaller pieces can then be modified for clients, if this is really
necessary beyond the picking of components that got sold, by the
documentation guys. This should be done as the code is being written or
modified. Documentation needs to test the customization before it goes out,
or should? The product shouldl be completed with documentation before
delivery/installation. In the same vein, later changes and upgrades get
documented with the new code, so the new code goes out documented. Field
guys should stay away from the documentation, for these reasons: The fewer
fingers in the pie, the better the end product. This would keep the
documentation under control, and managed. The company's product is the
document as much as the software. if you can scale down the publications to
modules, or components sold/installed/modified, you can customize the one
that need it and send it out for field and client to use?
That's what I would push for.
That keeps the future of the documentation growth manageable too. You may
have few enough clients to do this for now, but grow another 5 or 10 clients
and how many field dudes are out there writing manuals? Will you ever know?
Cheryl L. Higgins
Manager, Projects and Documentation
Continuum Performance Systems, Inc.
chiggins -at- continuumperformance -dot- com
