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.
I need some help from those of you who are writing for field service
techs in an OEM environment. I am trying to define my position (for
myself, mostly) and would like to know how you handle situations, such
as:
1. The design and sustaining engineering groups (separate from my
group)write procedures for upgrades and maintenance of equipment
(sporadically). They do not have a tech writer, so the engineers
themselves are developing these procedures, assigning a part number and
releasing them through an ECO. The procedures are useful, although not
always as clear (direct and to the point) as *I* would like to see
them.
The problems:
A. Do I take the time to rewrite these procedures for the field and
then distribute them, or allow them to go out as is? When I read
through them, I have lots of questions that I expect my audience to have
as well, although many of them will figure it out. My gut tells me to
rewrite and re-release them, but...
B. Some of the engineer's get very sensitive about the rewriting of
their procedures... I don't want to step on any toes, but I also
believe that a standard of documentation should be met. In my case, it
is my own standard of documentation for our field engineers that I am
trying to meet. Is that fair, or even reasonable?
C. Traditionally, I have developed a lot of the procedures on my own
using existing material where is was available, and hands-on experience
or observation for the rest. Everything goes through a thorough review
by engineering staff, and I wonder if they aren't tired of that process
so are developing their own in hopes of not have to do that anymore
(i.e. "we already wrote a procedure. Use it instead")
I am the first official "tech writer" to be hired in this group and work
alone (with the obvious exceptions of SME's). The workload is heavy, so
on the one hand, I feel I should be greatful for engineering's help
writing procedures and should just use them as is. On the other hand
there is the "standard of documentation" issue that says I have to do it
anyway.
If any of you are in this same type of environment, can you define the
structure of your position for me? How does it fit in with the design
and sustaining engineering function? How do you get information on
product changes (ECO only or by copy of e-mail, meetings, discussions,
etc.?) Do you try to control all documentation to the field or just
what you have time for?
Please feel free to respond directly -- scripta -at- gj -dot- net
Thanks!
AJF
TECHWR-L (Technical Communication) List Information: To send a message
to 2500+ readers, e-mail to TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU -dot- Send commands
to LISTSERV -at- LISTSERV -dot- OKSTATE -dot- EDU (e.g. HELP or SIGNOFF TECHWR-L).
Search the archives at http://www.documentation.com/ or search and
browse the archives at http://listserv.okstate.edu/archives/techwr-l.html