RE. Client from Hell redux?

Subject: RE. Client from Hell redux?
From: "Hart, Geoff" <Geoff-H -at- MTL -dot- FERIC -dot- CA>
To: "Techwr-L (E-mail)" <TECHWR-L -at- lists -dot- raycomm -dot- com>
Date: Tue, 6 Jun 2000 11:53:25 -0400

Ron Sering has <<... agreed to perform a contract for a client who has begun
ignoring contract agreements almost from the git-go. This isn't due to
unscrupulousness, but to poor (nonexistent) processes in place in their

Coincidentally, Lori Lathrop just published a nice article that should help
you decide: Lathrop, L.M. 2000. Knowing when to bail out. Intercom (June

<<The upshot of this is that their failure to provide me things like
software for research and an approved outline jeopardizes the success of the
project. In addition, decisions made on one day are ignored or countermanded
a day or two later, forcing me to lose time in changing direction.>>

In your shoes, I suspect that I'd bail out so fast their collective head
would spin. (But then again, I have another source of income and you may
not. Act accordingly.)

<<What does one do to retain a degree of professionalism and make sure that
they understand that the inevitable cost overruns and missed deadlines are
their problem, not mine?>>

When I've been forced to work under such circumstances, all I've been able
to do is keep the lines of communication open and frequently (daily, in one
case) make it excruciatingly clear what the problem. If you have any doubt
that the message is getting through, ask them to paraphrase what you've
said, and keep track of your agreements in writing. You can't be expected to
adhere to original contract conditions or deadlines if everything is
changing randomly and regularly. If they can't impose some sort of order on
the process, it's going to be a disaster for you no matter how things work
out. One possibility: if they don't have any professional managers (often
the case at startups), could you offer to take over management of the
project for an additional fee? (Political considerations almost certainly
prevent this, but who knows: you might get lucky.) Doing so would offer you
the possibility of gaining control of the process rather than becoming its
victim. If you could realistically do this, you'd be acting as a consultant
and helping the company develop a process that would work well in all their
future projects; that would place them eternally in your debt.

But on the face of it, I suspect that you won't be able to exert any
meaningful amount of control in this kind of environment and trying to do so
would leave you holding the bag for letting the project fail.

--Geoff Hart, FERIC, Pointe-Claire, Quebec
geoff-h -at- mtl -dot- feric -dot- ca

"Technical writing... requires understanding the audience, understanding
what activities the user wants to accomplish, and translating the often
idiosyncratic and unplanned design into something that appears to make
sense."--Donald Norman, The Invisible Computer

Previous by Author: Tools: Acrobat add-ins
Next by Author: RE. Why duplicate efforts? (Because it ain't duplication.)
Previous by Thread: RE: FrameMaker and Databases
Next by Thread: Re: Insure vs Ensure

What this post helpful? Share it with friends and colleagues:

Sponsored Ads