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 Stegall wrote:
>why is it always the *writer's* fault when the documentation sucks? I
wish I had a dime for every time I've written, or seen, a beautifully
organized and informative manual that was USELESS because the software
had so radically changed in the last iteration that there was virtually
no resemblance.
Well, I wish I had a dime for every dime I had. I would then have a lot
of times.
Seriously, although I've been in situations where the product I was
documenting changed, and I was not informed of the changes, I never was
blamed for the resulting errors in the doc. That's because I always took
(and still take) great care in recording who I spoke with and when, as
an effective CYA technique. That way, if a manager ever did approach me
and say "why didn't you document the changes to the ABC module?", I
could say one of:
1. WHAT ABC module? (doh!)
2. What CHANGES to the ABC module?
2. I tried to get the changes from developer X on these dates, but he
was unable or unwilling to supply the changes
In an ideal world, all writers would be aware of all changes. But in an
ideal world, I would get paid one million dollars a day to fondle fonts.
>>I've seen writers ORDERED by Marketing VPs to include instructions for
features that were not in the product, just because "the competition has
it and we have to, too".
This I find pretty wacky - I'm sure it happened but it obviously makes
no sense. How exactly would you document something that doesn't exist?
(Click on the "Fluffy Cloud" menu in Word - huh?) What is tech support
supposed to do when these customers call in asking where the feature is?
If I were the president of such a corporation, I tie those Marketing VPs
to the back of a truck and drag them over broken glass for six to eight
blocks. Then I'd probably give them I mild verbal reprimand.
>>I've struggled with projects where the engineers/developers who built
the hardware left the company three weeks before I was brought on board,
without so much as a diagram scribbled on the back of an envelope to
document their specifications.
Yeah, that hurts. Is there anyone left who knows what the hardware does?
If not, then documentation become the LEAST of the company's problems,
believe me.
>> I've had vice presidents put misspellings BACK INTO documentation
after I took them out.
Simple solution - force them to use a spell "chequer". (Or at least make
sure they use the "Track Changes" feature, probably the only useful
feature in Word (assuming they are using Word.) If that doesn't work,
"shoot zem - shoot zem both."
>>I've been forced to "release" documentation that no one ever took the
time to review despite my threats and pleading. In the end, management
NEVER (can I say this again? NEVER) takes responsibility for their
mistakes, and blame the writer for things that the writer could do
nothing about.
If you have carefully documented all your efforts, who you spoke with
and when, and management is still blaming you, then either:
1. The managers are a bunch of psychos, in which case you should start
looking for work elsewhere.
2. The managers aren't psychos, and you could have done more to get the
changes you required.
3. Something between options 1 and 2.
Pick one. But I would say from my experience, I have NEVER had a manager
blame me for errors in the final docs - I have always been able to show
them who I spoke with and when. It would have been almost impossible for
them to say: "OK, you continually asked the developers for the changes,
and they didn't give you them, and other developers didn't event tell
you there were other changes, but, hey, you really should learn to be a
mind-reader."
Maybe that happened with you, in which case, you have my sympathies.
>Turning around and blaming *ourselves* for the shortcomings of the
startup/development environment is only demoralizing and divisive.
Blaming others is easy. Taking responsibility is harder. Poor quality
can be caused by the developer, the writer, the manager or a combination
thereof. Often, it's a combination. But like I said, if you are working
for a psycho, then be sure to document all your efforts. If they still
blame you, move out or move on.
Andrew Brooke
abrooke -at- advancedutility -dot- com
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Order RoboHelp X3 in December and receive $100 mail in rebate, FREE WebHelp
Merge Module and the new RoboPDF - add powerful PDF output functionality
to RoboHelp X3. Order online today at http://www.ehelp.com/techwr-l
Check out SnagIt - The Screen Capture Standard!
Download a free 30-day trial from http://www.techsmith.com/rdr/txt/twr
Find out what all the other tech writers, including Dan, already know!
---
You are currently subscribed to techwr-l as:
archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit http://www.raycomm.com/techwhirl/ for more resources and info.
