Re: Round #4263 with the Client From Hell

[Elna Tymes <Etymes -at- LTS -dot- com>]

Andrew Plato wrote:

> I am probably going to be chastised not being supportive...but here goes.

I hardly expected anything else from you.  You represent one side of the
contracting business, and most of us represent other sides.  Nobody's played
the "yeah but we earn more than you do" game, and  I certainly hope nobody
will, but we have certainly been successful in this business by any measure
you care to name, sometimes outrageously so.

> Elna, you were not hired to teach your client software development
> processes. If I read your post correctly, they hired you  to write docs.

Here's where your mode and ours differ dramatically.  Our experience going
back some 30+ years in this business, most of it as independent contractors,
is that a certain amount of structure (= process) establishes the rules by
which the contract is executed.  One of our rules of process is that endless
iterations don't necessarily improve the quality of a document and almost
without exception add to the cost of the project as a whole.  In addition, if
nobody puts any bounds on the iterations you wind up with people correcting
each other's corrections, and sometimes their own, until nobody reaches
consensus on what's to be released.  That's not good for anybody - not for
you, not for your business, not for the client.

So I maintain that, in order to write docs in a cost-effective manner, we have
to reach agreement with the client about how we're going to do that.
Negotiating that agreement (= process) can take as little as 5 minutes with a
savvy client or much longer with a client who's never produced docs (= CFH),
and the time it takes up front is worth every penny in aggravation avoided -
usually.

> The idea that there is some universal software and documentation
> development processes (or universal to Silicon Valley) that everybody
> should use is nonsense. Every firm has their own weird ways of doing
> things.

Of course they do.  The process tends to be the same, generally, with
exceptions here or there or little variations on the theme.  In the companies
who succeed, that is.  These are all things that are settled up front, usually
in the first 15 minutes or so.  It's normally Not A Big Deal.  If you're
dealing with a software developer from Timbuktu or some other remote place, of
course, you might have to deal with some other factors.  But the process I'm
referring to is one that is generally used by software and hardware companies
all across this country and consists of (1) outline, schedule, audience
definition, (2) first draft, (3) first review, (4) second draft, (5) second
review, (6) final draft, (7) production.

> By forcing a client to use a process they don't like, you're bound
> to have trouble with them. And just because they "approved" of the process
> on day one, does not mean they actually will follow it.

I can hear legions of writers out there scratching their war wounds and
nodding in agreement.  Just because the entire team agreed to follow certain
rules doesn't mean they will.  One might just as well say "just because they
agreed to pay you X amount on Y date doesn't mean they will."  In which case,
of course, we aren't running a business, we're running a charity.  And
frankly, we don't write tech docs for free. I doubt Anitian does either. Nor
do you provide long-term consulting for free on an ongoing basis unless there
is some other quid pro quo. Get real, Andrew - I'm not going to allow my
writers to prostitute themselves just to please a client.

> Theory and
> reality are rarely bedfellows. And demanding they follow the process and
> then withholding work when they don't would anger anybody. You should
> adapt your processes to fit the client's work patterns.

Of course withholding work when the client doesn't play by the rules would
make them angry. That's why we try all sorts of other things to get their
attention.  If they don't like the process, they can renegotiate the contract
with us - we're always open to that.  The point is that you play by the set of
rules you agreed upon - and if you don't like the current rules, it's
important that you negotiate a new set.  But you don't just up and abandon the
rules because you put your jock strap on backwards this morning (or something
equally irrelevant).

> I too have had clients that went 6 and 7
> rounds on edits. It sucks, but each iteration improved the docs as a
> whole. And I tried to keep everything informal and cool. If you aren't too
> much of a stickler, most places will realize they are taking up more of
> your time and agree to pay you more.

If we had seen signs that things were improving, we would have gladly gone
along.  But remember that this was a fixed price contract, and the client was
NOT going to pay more. We already knew that.  And the iterations improved the
docs only because they kept adding new material about features that hadn't
been invented before, in essence expanding the scope of the document some 4-5
times what we'd been told to assume when the contract was signed. So here we
were between a rock (the fixed price contract) and a hard place (endless
iterations with much new and unexpected material).  I think even you would
find that objectionable.

> Furthermore, I did not see anywhere in your message an attempt to resolve
> the customer's complaints about the docs after you delivered them? Did you
> make any effort to find out exactly why they did not like them? Why did
> they think the docs were garbage?  What did you offer to do to fix them?

That's a subject of another posting, and I'd rather not use the bandwidth just
now.  Suffice it to say that we "fixed" the docs according to review comments
of every type, length, and description whenever we encountered them and in
whatever form they were sent to us.  As far as we knew, six developers and
their vice president did not consider our stuff "garbage," only the newly
hired general manager did and he admitted he hadn't even read one of the
docs.  He claimed the "garbage" term was something he'd heard from someone
else.

> Moreover, were I your client, I would be very angry if I found out that
> you were posting a complete summary of these events in a public forum. I
> think it is unprofessional to discuss such private matters in a public
> forum - although I am sure others will disagree with me.

Let's be real clear about this.  There is nothing unprofessional about using a
board like this to cite a real story - a case study, if you will - about the
realities of contract work in technical writing.  Let's face it: most business
schools, including the prestigious ones like Harvard and Stanford, use case
studies heavily to illustrate points.  Only they use real company and people
names and real numbers from balance sheets and income statements.  This case
is, in fact, a case study but with the names of the client removed and certain
other details - like ethnicity, which oddly enough actually has a bearing here
- left out. Based on the details I've given now and in previous postings, it
would be impossible to identify the client unless you knew where to search and
what to look for.  There is nothing libelous or slanderous about anything I've
said about them.  As for being "unprofessional," that's like saying that
someone who doesn't keep an immaculately clean desktop is "unprofessional."
<chuckle> If that's the definition of "professional behavior," then I plead
guilty.

Go mop up your own desk, Andrew.  You have your standards for success, and we
have ours.

Elna Tymes
Los Trancos Systems


^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Sponsored by eHelp Corporation, makers of RoboHelp - the industry standard
in Help authoring. Download a trial version today or get special savings when 
you buy the RoboHelp 2002 Holiday Edition. Visit http://www.ehelp.com/techwr

---
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.