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.
Subject:Re: Educating Clients In Action (long) From:Robert Plamondon <robert -at- PLAMONDON -dot- COM> Date:Tue, 17 Oct 1995 08:45:28 PDT
Binni Graham writes:
>For example, my most recent Devil Project involves a company who brought me in
>to the project early, them stonewalled every request for useful information (I
>received old specs, an out-of-date design guide, the old DOS version of the
>manual, and their customer's RFP that was really only a list of features with
>no explanation of why these features wer important or how they were expected
>to be implemented). [...]
>I'm honestly starting to wonder if it wasn't ME, since the client views my
>concerns about these issues with innocent amazement (much like my cat's
>attitude when I catch her on the counter). Is this an unusual client (I know
>it is for me -- most of my other clients are MUCH more responsive than
>this)?
Typical. I advise the following course of action:
1. Raise your rates for this client on the next contract. Raise them
a lot. Tell the person you negotiate the contract with that it
is very unpleasant to work for them because the developers are
so uncooperative, and that you are very unhappy about the quality
of work that comes out of such an environment, and you're afraid
that it will hurt your reputation in the field. Then jack up the
price $20 an hour, and tell them that you'd be just as happy if
they turned you down.
2. If they turn you down, throw a party for all your friends.
3. If they don't turn you down, throw a party for all your friends.
4. Realize that your boosted price goes to salvage your professional
pride, because you're going to consider yourself two-thirds babysitter,
one-third writer on this contract.
5. It's not you. It's them. This is typical of engineers who have
no concept of the real world. Writing scares them, so they avoid
it (and you) with astonishing agility. (I forget what the five
stages recovering alcoholics go through -- something like fear,
denial, anger, guilt, and acceptance. Engineers have to run
the gantlet before they can accept the existence customers and
the need for documentation.)
>Some of this I am willing to own as my own fault: I probably should have
>specified review cycles in the contract (at the time, I couldn't even imagine
>a client not wanting them...), I should have asked about deadlines, I should
>have been more aggressive about getting new software and edits.
Little of that really matters. Babysitters can have any kind of contract
they want, but the kids don't care. The engineers you're dealing with
are operating without adult supervision. The important thing to do
is to either (a) ditch these clients and get some grown-up clients, or
(b) resign yourself to playing Wendy to the engineers' Peter Pan.
>I keep hearing that little voice in your head that says "If you were
>REALLY a good technical writer you'd have been able to do it anyway" -- am I
>the only one who hears it? Anyone else found the volume control for it? <g>
This is the Stone Soup School of Writing. "If I'm really good, I can
write a manual without access to the facts." The only way to write
a manual in a hostile environment is to reverse-engineer the product,
which never works until AFTER the product is released, since it changes
too much beforehand.
-- Robert
P.S. None of MY clients are quite that bad, but one's close.
--
Robert Plamondon * High-Tech Technical Writing
36475 Norton Creek Road * Blodgett * Oregon * 97326
robert -at- plamondon -dot- com * (503) 453-5841
"I regret that I have but one * for my country." -- Nathan Hale
I can "should" all over myself if I want to, but what I want to do is make
sure it doesn't happen again. One way is to put a number of these things in
the contract. Do any of my fellow contractors have any additional suggestions?
Part of where I'm going with this is putting the feelers out for assembling a
panel of contractors for some future Annual STC conference. I'd like to call
it something like "Beer and Skittles -- My Worst Contract and What I Learned
>From It." Kind of like a "war stories" panel, but more geared toward the
"learn from it" aspect.
The other part of where I'm going with this is a little moral reinforcement --
does EVERYONE have at least one contract like this, or is this a Sign From
Wherever? I keep hearing that little voice in your head that says "If you were
REALLY a good technical writer you'd have been able to do it anyway" -- am I
the only one who hears it? Anyone else found the volume control for it? <g>