What about the client's needs? (was: What would Andrew do)

["Hart, Geoff" <Geoff-H -at- MTL -dot- FERIC -dot- CA>]

Andrew Plato continued to play the client's advocate in this discussion:
<<Yeah, I roll up my sleeves and get the job done. But where is the real
fault here? To date, I've never had a client change deliverables that
radically, or if they did we negotiated something.>>

I'd say the fault--if that's really what you want to call it--was that Elna
was too patient with the client, and actually tried to help them develop a
better process. Sometimes you just need to shrug and accept the fact that
they like working inefficiently, and be glad that you're only working under
contract. I know you're allergic to the P-word, but the fact is, you have
the choice of using a process to help make things go better for everyone or
you can use it to strangle people and prevent them from getting work done.
Elna's process, in one or more variants, is perfectly sensible, and lies at
the heart of anything _we_ do--and I'm including you in this group. Any
writing involves the following steps:
- create the draft (usually based on some kind of analysis of what the
product does and what the user needs)
- get the client to review the draft
- revise the draft in response to client suggestions and critiques
- submit a (hopefully final) revised draft, then repeat these last two steps
as required

Where you and Elna differ is in the last two steps. In her case, because she
bid on a fixed price rather than per hour, she quite properly tried to get
the client to adhere to the terms of the contract--which clearly stated a
limited number of revisions. You seem to either work by the hour, or pad
your bills so much that it doesn't matter how often an ill-informed client
who can't be bothered to work with you asks you to revise something. Fine.
As you say:

<<Because I spent the time up front to figure out what was needed, I always
had my butt covered.>>

The only way this statement can be universally true is if you also included
clear knowledge of the client in your planning, or included so much padding
in your bill that it didn't matter how often the client changes their minds.
Admittedly, one thing Elna could have done differently once it became clear
that the client was no longer sticking to the contract would have been to
renegotiate the contract: "I've noticed that you folks are doing an awful
lot of revisions here. That's fine, but if we stick to the terms of the
original contract, this won't work out fairly for you because you won't get
as many revisions as you clearly want. So here's my suggestion: let's change
the contract so that I charge you a fixed price per revision, and then we'll
make sure that each revision is to your satisfaction." Working this way
protects you, because you get paid each time you do a revision, and might
make the client happier, because they see their needs (ongoing revision) met
better. Moreover, you can come right out and be honest about it: "I
estimated the original project based on two revisions, at $1000 per
revision, for a total of $2000. Let's change this so I bill you $800 per
revision. If you only revise twice, you save money [and I save my remaining
hair--but you don't say that], but if you revise a third time, you're
getting that third revision for $600 less than if we stuck with the original
contract. [But I'll also be compensated for my effort by making more--and
you don't say that either.] Deal?" Numbers obviously fictitious and
ill-considered; if you're actually budgeting, you'll want to spend more than
10 seconds coming up with real numbers.

<<I suppose if the client changed the deliverables, and the change made
sense to me, I would go along with them.  If they changed everything and it
didn't make sense, I would probably ask for more money as well.>>

Which, coincidentally, is exactly what Elna tried to do. So I don't think
you're so much disagreeing with her as you are misunderstanding her. I
assume from the way that you write that you're experienced enough by now to
recognize clients who will insist on endless revisions and pad the cost
estimates accordingly. But even if you're experienced, you occasionally get
blindsided by someone who talks a good game--and believes it--but simply
lacks the skills to do what they understand they're supposed to do. When
that happens, you shouldn't just chalk it up to experience without at least
trying to recover some of your time and money.

<<Before we all jump to the "clients hate us and abuse us" let's remember
that there is another side to this tale. And we don't know that other side
AT ALL... I am sure Elna did her job. But, I am compelled to be the jerk
here and say: but what about the other side of this coin? What about the
client's needs?  >>

The fact is, most businesses are run by the seat of their pants, by managers
who follow Sturgeon's law: a majority of them don't really know what they're
doing, got their position because promoting them was easier than going
outside the company to hire someone with real experience and skill, and end
up just faking the job reasonably well. A good manager doesn't need a
formalized process as much as this latter type of manager because their
skill lets them follow the process without much thinking about it; that's
the situation with you and your "just roll up your sleeves and write the
damn manual" approach. I doubt you'd claim that you randomly do whatever
happens to feel right on a given day on a given project, right? If you're
not working randomly, you're following some kind of process whether or not
you like to admit it. That process may be much more flexible than the one
that most of us use, but it's still predictable and includes most of the
same steps that everyone else's process includes. Call these the three R's
of technical writing: write, review, revise. <g>

<<we don't learn ANYTHING from closing ranks and assuming what we are being
told is true.  We learn by considering the what
the other side is doing and trying to understand their motivations. We can
learn by analysis of a situation.>>

That's an excellent point, and I'd love to see this discussion change
completely in focus: How do development managers manage or mismanage the
development process? How do senior managers, the marketing department,
sales, finance, and the other various divisions of a company put pressure on
the development managers and change how they manage? How does this affect
the work we do? Off the top of my head, a few thoughts intended to stimulate
discussion:

- Deadlines are often chaotic because marketing and sales plan to meet a
certain shipping deadline, and when a competitor changes strategy without
warning, development must shift to account for this: if it doesn't, the
company doesn't sell enough products to stay in business. Moral: Deadlines
will always be tight and changeable, and we must build flexibility into our
planning to account for this.

- Programmers often tinker endlessly with the interface because (a) doing so
is much easier than producing the underlying code, and that makes them
appear productive, and (b) they don't understand how unproductive this is.
You can sometimes educate them about the problems this causes, but because
traditional programming training generally emphasized exploration and
elegance and productivity over efficiency and maintainability, you've got a
huge cultural barrier to cross. You can't change a culture overnight. Moral:
Where you can work with the programmers to show them the benefits of
freezing the interface early, do so. Where you can't, accept that things are
going to change constantly, that you'll be documenting a moving target, and
that you'll need to develop some coping tools that let you meet deadlines.

- The vast majority of managers don't really understand much about writing,
but they do know what they like and dislike, even if they can't explain why.
Thus, they revise by iteration, changing things back and forth until they
get something that sounds right to them, then ask you to produce that.
Moral: Sometimes you need to give a manager several options to choose from,
and time to confirm that choice, if you expect to avoid endless repetition
of the review/revise cycle. And some clients will still keep revising as
long as you let them, and you'll just have to deal with it.

- Sometimes the person you're dealing with is the wrong person to deal with;
they may be the manager of the department, and may be able to put you in
contact with the SMEs and do all the other things they need to do to get
documentation written, but in the end, someone else (the company President
or the accountant in Purchasing with a 1-year diploma in Croatian
literature) is the one who approves the documentation. If you don't know
that, or can't do anything about it, you're screwed. Moral: Identify all the
stakeholders before you begin so you can involve them in the planning--or at
least be aware that you're trying to meet the expectations of someone you'll
never see, hear, or get to ask questions about their preferences.

<<I roll my eyes when people... egg me on and draw me into making an ass out
of myself.>>

C'mon, Andrew. It's not like you need encouragement. <gdrlh>

--Geoff Hart, FERIC, Pointe-Claire, Quebec
geoff-h -at- mtl -dot- feric -dot- ca
"User's advocate" online monthly at
www.raycomm.com/techwhirl/usersadvocate.html

"Arguing with anonymous strangers on the Internet is a sucker's game because
they almost always turn out to be--or to be indistinguishable
from--self-righteous sixteen-year-olds possessing infinite amounts of free
time."--Neal Stephenson, Cryptonomicon 

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Sponsored by eHelp Corporation, makers of RoboHelp. RoboHelp 2002 is now available! Get the very latest in Help functionality 
to create superior Help systems. Get special savings when you buy 
in January!  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.