Re: Round #4263 with the Client From Hell

[Andrew Plato <intrepid_es -at- yahoo -dot- com>]

"Elna Tymes" wrote 

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

Well, that sounds swell. But just because you have been around 30 years or
3 hours doesn't make the process perfect. Moreover, editing hell is a very
real situation. However, you're asking us to assume that you did
everything right one iteration 1 and the client screwed up everything from
there. 

I have found that you can avoid editing hell by getting it right on try
one. This usually means sinking deep into the client's business,
processes, and culture. Spending a lot of time understanding their goals
and hopes. 

I have no idea what you did - nor do any of us Elna. Which is one more
reason to keep "case studies" of this nature private. Because some people,
like myself, are inclined to start asking "why the hell did this person's
relationship go so bad?" and "why is she publishing this in such exquisite
detail." 

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

Sure, those sound like reasonable steps. But, for one reason or another
those steps did not keep you out of trouble with the client. So clearly,
the process is not the only ingredient to success. 

Part of any successful business is the ability to gauge the strength of a
relationship. I have clients that will basically let me do whatever I
want, because they trust me. I have others that require extremely formal
arrangements. And others that live in a perpetual state of chaos. I adapt
my "processes" to meet their needs. Its the essence of good consulting.
You're giving them quality product while adopting it to the client's
environment. 

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

Exactly. Just because people say one thing, doesn't mean its what they
will do it. 

In network security seminars, I often explain how hackers get into
computers by saying one thing to a computer, but doing something else. Its
a simplistic way to understand the nature of hacking. You obfuscate your
real intentions with bullsh*t. 

People LOVE to bullsh*t, plan and theorize. Because its easy, fun and
FEELS important. But when you get down to business and ask them to pay -
they lose interest. 

Now, you can walk into such a situation loaded for war, in which case you
will usually get one. Or you can be prepared to work with the shifting
sands. 

Again, Elna, we have no idea what process you implemented and if the
client accepted it or not. But, from what I read it sounds like they kept
on adding sections into the document. Based on my experience this tells me
two things: 1) the client has no idea what they are doing or 2) the writer
did not take the time to understand the technology at a detailed level.
Generally, it is a bit of both. 

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

Nor should you. But, you also should expect the unexpected. Sometimes,
that means doing the work yourself. I jump into projects all the time,
unpaid, just to get things on the right track. It sucks, but its either
that or a pissed off client. And I will not under any circumstances allow
a client of mine to become dissatisfied. Even if it means working for
free. 

I firmly believe the old adage that the customer is always right.
Sometimes I lose money on projects sometimes - but I keep reputation as a
company that can get the job done. That is worth WAY more than a single
unpaid invoice. Apparently, your firm has a different attitude than I do. 

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

If the client is unhappy with the results - then the rules are irrelevant.
Satisfaction is the key. I have found that my most profitable business
relationships have the least rules. They are usually handshake deals with
very basic goals. I have two or three long term relationships with clients
- and I don't even have a contract with them! I don't need one. I bust my
butt for them, they pay me. That's all we need to work together well. 

Now, I don't recommend this model to everybody. But it works for me. 

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

Which is why I don't do fixed bid contracts. They are too dangerous. I bid
based on hours. If the client adds work - then its just more hours. Real
simple. 

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

Elna, there is a big difference between a brief posting that says
something like "hey everybody, look out for clients from hell" versus your
detailed chronicle of a failed business relationship. 

I mean - what are we going to remember Los Trancos Systems for now? Their
savvy documentation capabilities or the fact that they had a massive
lawsuit with a client? Which do you want to stick in people's heads? 

Hey, I have had some icky situations with clients too. But it will be a
very cold day in hell before I would detail those icky situations on
TECHWR-L. Of course, I have never had a client dissatisfied with my final
product...yet. 

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

Yes. We do. And I hope yours work for you. Apparently they have for a long
time. But, I don't think you're doing yourself any favor by broadcasting
your problems on TECHWR-L. You may be giving all of us food for thought,
but the meal may be at your expense. 

Andrew Plato 

__________________________________________________
Do You Yahoo!?
Send FREE video emails in Yahoo! Mail!
http://promo.yahoo.com/videomail/

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

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.