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.
Sarah Siliconwriter reports: <<A couple of weeks ago I created a quick
start guide for our users, sent it around for review, got signatures,
and sent it through our Document Control process, which garnered more
reviews and more signatures. It got packed with the product and sent to
a user. Next thing I know, I'm getting feedback from the field reps
that the default user ID and password are incorrect.>>
Good thing you've got signatures. You can now take this feedback and a
copy of the signatures to the managers of everyone who signed off on
the problem areas and ask for appropriate beatings and beheadings. Of
course, satisfying though it is to circulate digital images of the
mutilated corpses to inspire fear and dread a week or two before the
next review cycle, you may want to try something a bit more moderate...
<g>
<<I had no access to this software while writing the guide, and relied
on our field reps to give me the information, then later to review
it.>>
Politely explaining the situation to the people who did not provide
access, and providing the signatures and field rep comments as
supporting materials if necessary, should gain you access to the
software next time around. Similarly, pointing out that people who sign
off on these things are legally responsible if your customers are
harmed by inaccurate documentation should gain you support for holding
these people responsible for the review.
Note that the goal here is to ensure accountability, not to punish
anyone. When you get into punishment games, you create all kinds of
long-term enmities that make your life even more difficult. Start with
the attitude that punishment would be satisfying in the short term, but
positive changes that don't earn you enemies will be more satisfying in
the long term.
This isn't just theory: I've done this at a previous job. The key is
not to blame people and insist on punishment, but rather to use the
cold, hard facts to justify and implement a more rational approach.
That approach must ensure accountability and tracking of that
accountability; making successful reviews part of the criteria for the
annual performance appraisal works well.
If you can't get buy-in from somebody with the authority to hold those
who sign responsible for their mistakes, about the best you can do is
take appropriate measures to cover your ass. Keep collecting
signatures, keep a low profile, and eventually someone will get
sufficiently pissed off to insist on a change. Since we writers are
often highly visible targets, it would help to send Personnel a file
copy of all your correspondence with managers and reviewers, plus
relevant statistics about problems. If you're paranoid (sometimes
justifiably so), keep a copy of anything that isn't confidential at
home in case some of your files at work go missing.
<<Nobody mentioned that the user ID and password had been changed. When
I mentioned (a bit testily, I confess) in email that the reviewers
should have caught this, I was told by the head of tech support (my
main reviewer) that he never looks at the documents he's sent to
review, and that I should walk them over to him and stand over him to
get them actually reviewed. What am I, his mother?>>
If you were, at least you could ground him and take away his TV
privileges. <g> Here, you need to do several things: First, use this
situation as evidence that you need to have ongoing access to the
software and that the appropriate managers must hold reviewers
accountable for their reviews. Second, you need to be working with the
developers of the product to find a way to be kept up to date on
changes. Third, you need to find a more appropriate reviewer. Tech
support is great for telling you the kind of information users need,
and what kinds of problems they report most frequently (i.e., so you
can focus your efforts on these problem areas during the design stage),
but only the developers ever know the actual state of the software
(i.e., what you'll focus on once you move beyond design to the actual
writing).
<<I am holding onto my temper with both hands, as the field reps are
now blaming me for this screw-up. Am I responsible?>>
It would be appropriate to ask your manager to insist that the
reviewers apologize to the field reps and absolve you of blame. Your
ability to work with these people and others in the company, not to
mention your professional reputation, is at stake here, and it's
appropriate to work hard to protect yourself. At this point, your word
probably isn't worth much, so the actual malefactors are the ones who
should clear your name--or possibly their managers. It's nicer if the
guilty parties take responsibility for their sins, but forcing this
down their throats won't make you any friends. So you might want to
accept a mea maxima culpa from their managers instead.
WebWorks ePublisher Pro for Word features support for every major Help
format plus PDF, HTML and more. Flexible, precise, and efficient content
delivery. Try it today! http://www.webworks.com/techwr-l
Doc-To-Help includes a one-click RoboHelp project converter. It's that easy. Watch the demo at http://www.DocToHelp.com/TechwrlList
