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.
Thanks to all of you who posted responses to my original. Here are some
things I continue to work on.
* Techniques for and approaches to getting information when the SME is
not one person or two, but many people including engineers, shop
people, field service guys who installed the machine, even the sales
engineer. Hard to get access
to the machine while it's in the debug stage, which is followed almost
immediately by a buyoff and crating. On many jobs, I end up putting
something together for maintenance, a rough draft, which I send to the
field rep starting the machine. Attached to draft is a long list of
questions and suggestions.
* Developing a system to expeditiously produce paper documentation for
many variations in machine models and systems. In other words, literally
having a manual identified by sales/job number, not by "model" or "type"
because the builder rarely assembles the same thing twice, although
similar basic chunks of design are recycled.
* The difficulty in finding out what the end user really needs. My
major customer does a lot of work with a major, major can/can end
producer. Recently that company has been harping on the idea
that they want a "world class" approach to maintenance. Yet, I've been
unable to get someone at the user end to even mark up one of the manuals
we've done or tell us where we're deficient. How to get real world
feedback when my own customer is not interested in doing anything more
than giving them just enough to meet the PO requirements and get paid.
If you're contracted to write just one manual, what
is it? What is the emphasis? You may be asked to write an Op Manual, but
I've found that many
times, depending on the user company and their ideas, Operating Manuals
are for anyone but the operator. Is it a training manual? Maintenance
manual? Many times a customer just wants "a manual" but can't tell you
how the machine owner is going to use it.
* Producing maintenance manuals for various custom machines, I've
found that many of the younger or less experienced engineers are of
limited help in establishing maintenance intervals, methods, lubricants,
etc. It's not impossible to get the information (from OEM), it just
makes the search a much more tedious process. I know that many component
OEMs are publishing on CD and have web sites, but this still takes a
long time to check out, often with disappointing results if the CD or
web site info is more application/sales oriented than maintenance
oriented. Any other ideas?
Any thoughts and ideas from successful real world experience are
appreciated.