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:Educating Clients In Action (long) From:Bonni Graham <bonnig -at- IX -dot- NETCOM -dot- COM> Date:Mon, 16 Oct 1995 16:58:58 -0700
Robert Plamondon wrote:
>Also, decide how much of the engineers' time you want, and demand it.
>Early on, you can do this, and people will grudgingly acquiese.
>I find Gantt charts very useful in this endeavor. Any time someone
>suggests stiffing you on something you want, your deadlines leap further
>into the future. By showing the managers the effects of their intransigence
>(in a helpful, even cheerful way: "Sure, we can do it that way if we
>really have to, but it slips the manual out until...hmmm....September 17.")
>you can beat a smidgeon of reality into them.
Robert cites these an other useful tips for cooperating while still managing
to convey a busy schedule and a sense of project reality. These are great for
in-house employees, but what about contractors? I'm finding I'm having a hard
time stepping out of this "juggle projects" mode (each client thinks, as each
professor used to in college, that they are the ONLY ones with any claim on my
time -- and I'm not necessarily saying they're wrong to do so).
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 was told that I wasn't expected to *be* the SME, but I
couldn't get information *from* the SME(s). At each and every conversation
with the client I requested further information such as:
o contact names of the appropriate engineers
o updated specs/design guide
o programmers notes (even if they were handwritten; I used to teach fifth
grade -- I can read pretty much any handwriting)
o any kind of customer feedback on the manual from the DOS version
o software updates on a reasonably regular schedule
o draft review feedback on a reasonably regular schedule
I received zero, zip, nada, nothing, and was frequently told (on things like
which global tables needed to be populated with data before a useful widget
could be built) "They'll already know that, so you don't need to tell them";
well maybe I didn't need to tell them, but I kind of did need to know it... To
add insult to injury, I received exactly one set of edits (three days before
the deadline), even though I delivered a version of the help file every other
week. I never received any advance warning of deliverables ("We need to
demo/deliver the project next week; can you be finished by then?"). I had to
ask for every new version of the software (we got wrapped up in documenting a
finally-functioning feature and didn't ask for an update two weeks in a row --
by the time I remembered to ask for an update they had COMPLETELY changed the
interfaces to several of the dialogs).
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
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.
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>
Thanks in advance!
bonnig -at- ix -dot- netcom -dot- com