How to deal with a nightmare client?

November 22, 2006 6:30 AM

How to deal with a nightmare client?

I am developing a flash app should not be too big of a deal to develop; A collection of documents that a user can download off of a CD and then use and/or edit. Now, that being said;

The client asks for it to be white, but then again black. The client says that the document we are basing the navigation on are correct, except for the things that are not correct. The client changes documents and architecture and does not tell us about it and then accuses us of using the wrong documents. The client has focused on cosmetic changes while we could've been spending time on getting the code correct. The client makes changes to changes before we've had a chance to make the original changes. The list goes on. Names have been changed without us sitting in a meeting and the client going, "well that's not in there anymore" in an accusatory tone. Like we are trying to put the wrong thing into our work immediately.

Everyone who has worked on this project has either tried to quit (other outside resources) or get transferred to a different job.

How do survive this hell without:
1). Losing my mind
2). Losing my job. Because if you look at the Seven Stages of a Project, we are, or almost about to be into Phase 5: Search for the guilty.

posted by Botunda to work & money (17 comments total)

I have been through this. You need to be polite, yet firm, with tthe client and tell them that all of the changes are wreaking havoc on the project and the schedule. Ask them to step back, give you the final requirements, and then you finish the first draft of the project without sharing intermediate results with them. Document your code for easy editing as you know there will be plenty after the client gets the next chance to request changes.
posted by caddis at 6:53 AM on November 22, 2006

First, I would document each sudden change they have requested be implemented.

Second, I would request a meeting with the client and sit down with them and the list.

Third, I would say "If this keeps happening, we're not going to be able to finish your project in a timely manner."

Fourth, I would establish that you are going to go to alpha or beta or whatever stage you need to be at and then a set number of revisions can be implemented afterward.

If they don't agree to these terms, it may be time to consider the cost sunk into the project and figure out if it's time to cut your losses and their own.
posted by beaucoupkevin at 6:53 AM on November 22, 2006

Specify. Confirm by contract (sounds like you went right by this step, but it's never too late to Write Stuff Down and Show It To The Client and Refer To It Later, Like It Was Real). Change only by signed change order. Up charge (profit!).

Nobody feels bad when they are getting paid more.
posted by paulsc at 6:55 AM on November 22, 2006

Fire your client.

If you're not in a position capable of doing that, keep a paper trail. Ask a confirmation by e-mail/letter/fax/wather for every change he asks to be done verbally.

Invoice the work you have done now. This is the type of client that will always find a "small" change that needs to be done, and "then" he'll pay his bill.

Good luck!
posted by lodev at 6:56 AM on November 22, 2006 [1 favorite has favorites]

So when the client changes things, do you have a record of what they've previously specified? If so, you can politely but firmly draw attention to the change and press them to acknowledge it, adjusting the schedule/budget accordingly.

If the entire project is in a mess, you basically have 2 options. Either let it stagger on and bodge something together, or 'reboot' by stopping to assess what you have, what's needed, and how you're going to achieve it. Calling for the latter option might make you a target, but awkward people often back down when faced with an organised, transparent process that makes them accountable for their actions.
posted by malevolent at 6:57 AM on November 22, 2006

!

Write up an exhaustive analysis of the project's course thus far. Include your own mistakes (not demanding that project specs be finalized earlier!) as well as those of the client (unilaterally changing the specs multiple times). Seal it in an envelope, and hand it to your boss, while giving him a quick verbal summary of the challenges the project now faces, and how they may be overcome.

The boss may offer some solutions of his own. If he does not, your only option is to communicate directly with the client and request in the strongest possible terms that specifications be locked for the remainder of the project.

If the client refuses this request, well... at least your have a solid base from which to argue that the project's collapse was not chiefly your fault.
posted by The Confessor at 6:58 AM on November 22, 2006

If you want to complete the project, you need to go into serious CYA mode. Assume nothing, document everything, and be super-over-explicit about everything you're going to do.

As soon as possible, meet with the client, tell them you want this project to go as smoothly as possible, and to make that happen you need to both agree on a process for maintaining the spec. They need to understand that since you're not psychic, for you to do your job, you need a clear set of guidelines for interacting with their organization.

Not sure what the spec or process for maintaining it will look like for your project, that'll take some judgement - for example, if you need to use documents they maintain, specify where you'll get them from, how often, how you'll find out about updates, etc.

Basically, you need to ram the point home, over and over, that you are working to a process and a written spec document, and that you don't change either of them unless you talk to the client (or whatever process you come up with.)

It sounds like a lot of players are involved, so the process should talk about how you publish the spec and solicit corrections. Then if someone accuses you of using old data, you can sweetly ask them why they didn't reply to the email you sent the day before with the spec, asking for changes.

_Every time_ you meet with someone at the client about the requirements, send a summary of the meeting and changes to the spec to the participants and any other relevant party. Say "this is what we'll be basing our work on unless someone tells us otherwise."

Yeah, it's sort of lame, but it's the only way with organizations like that - it's hard to keep a lot of people working in the same direction on complex stuff.
posted by lbergstr at 6:58 AM on November 22, 2006

I work with a difficult person like this. (Unfortunately she's my boss.) I have a special spiral notebook that I use exclusively for taking notes during conversations we have. I keep the notebook in an easy-to-find location, and grab it anytime she wants to talk with me -- even just for a 30 second or two minute chat.

I write the date, time and purpose of any meeting, take notes as we talk, then write out a bulleted summary of actions, direction, and key data after the meeting.

If she later says something that contradicts direction she gave me earlier, I flip back to my note of that conversation. "Hmm, on Tuesday we agreed that I would do X, and I put quite a bit of work into it. Now you're telling me to do Y. Are you sure I should change direction on it? Here's my thoughts ..."

It works much better than just being frustrated or than arguing with an unreasonable person.
posted by croutonsupafreak at 7:09 AM on November 22, 2006 [3 favorites has favorites]

Take the lessons learned on to the next client because you've got this one trained already.

You let them get away with too much, now they're spoiled.

If you can't fire them (and you really should) get everything from now on in writing, of course. It won't keep things from being changed, it'll just make it harder for them to do it and you'll have someone to blame. Which is, as you've suspected, important with clients like this. Make sure they know that any change to any aspect of the project, content, spec, copy, artc, etc. has a minimum of 5 (or more) working days turnaround.

My best tip for managing invasive clients is this:
Add a few intentional mistakes into the project as a red herring before the next review. Make the background blue and put a graphic way off center. And make some of the copy obviously wrong. Make it really obvious stuff, but things you can fix in about 30 seconds.

In my experience a client wants to feel like they're involved, so by setting something up for them to change they often won't go looking any further.
posted by Ookseer at 7:20 AM on November 22, 2006

I think you are being too accomodating by attending to every need of the client on a continuing basis. It is up to you to set deadlines for changes and/or only allow changes at specific times.

Schedule at most two client meetings where they will be allowed to have input on the design. Only allow input during those times and ignore any emails regarding changes at any other times. Tell them that changes are to be in writing and delivered in hard copy within a week after each meeting.
posted by JJ86 at 7:27 AM on November 22, 2006

Tell the client, face to face, what you've written above.

"If you don't stop doing [x] then [y] is going to happen and there's nothing I can do about it. You *need* to help me so that we can get to [mutual goal]"

Take notes, follow up with minutes. This happens to a greater or lesser degree with every client, and it's usually because the client has no idea of the effect they're having.

Also usually, any client can ulitmately be controlled with the proper care and attention. This is what Project Managers are for - even if you have to remind them of that fact from time to time.

And get things signed off.

Oh, and make sure the client knows what "Signing off" means.

I feel your pain brother!
posted by Jofus at 7:29 AM on November 22, 2006

Lots of good advice here. I'll also add that it often helps to have someone in your org who is the designated Bad Cop or enforcer for all these rules. No matter how many times you set the expectation that changes must be in writing, must be signed off, will cost extra, etc etc, nightmare clients will try to go directly to the lowly designer/developer/freelancer and throw their weight around, bullying them into more tweaks to the project. Everyone on the team should know who the Bad Cop is, and should feel comfortable using a lack of authorization from him/her as a shield against additional demands.

Bad Cop, obviously, should be a senior manager, someone who is difficult to reach and who reeks of authority.
posted by junkbox at 7:39 AM on November 22, 2006

The business world is full of clients like this. Fortunately, most aren't this bad, but it is a continuum and there are idiots at the extremes.

We used to say 'The customer never knows what he wants until he sees what he gets', and nothing beats a very detailed specification for the work to be done to avoid long term problems.

It's essential to get progress payments for projects like this, so that you can leave at any time and not be devastated. It's sort of a Mexican standoff. I'd shift gears and get paid to date, if possible, then proceed from there on a pay as you go basis. Then, let them change as much as they want... at each stage, set specifications to meet and get paid along the way.

I have had this happen with Tandy (Radio Shack), Siemens, DuPont, to name just a few names. Don't feel like it's all that unusual. A lot depends on the specific employee you are dealing with. You'll run into it often, and you'll need a tool set to and a mindset to deal with it effectively. Good luck!
posted by FauxScot at 7:53 AM on November 22, 2006

I go a step further than croutonsupafreak by using not only a spiral notebook but a voice recorder. It's an Olympus VN480, which is unobtrusive (though I make sure everyone knows it's on by announcing it as my aide-memoire) and transfers recordings to my pc where it's easy to digitally manage the sound: find relevant bits of conversations, etc. Having a sound file of every meeting has been very handy sometimes, and it's so easy to do.
posted by anadem at 9:24 AM on November 22, 2006

Lots of good advice here, but I'd add one thing that has been useful to me. Every time you have a discussion with them (be it a 30-second or an hour meeting), send them an email that says "just to clarify the points we discussed, we decided that X will happen on Y date, etc. I'll proceed with that: let me know immediately if your requirements change from this".

That works as a a reminder and a CYA: "Oh, you didn't mean that? Well, I emailed you about that , and you didn't respond..."

Some clients aren't malicious in their intent, just forgetful and distracted. This helps to focus and remind them. And a second for the voice recorder: I use an Olympus VN960PC that has a USB connection and software that automatically copies the files to my PC so I have a record of conversations. Radio Shack does a $20 phone recorder that connects to this for phone conversations.
posted by baggers at 11:15 AM on November 22, 2006

Every change needs to be put in writing and added to the specs.
Every change needs to add to the price, and/or a submission deadline change.

When the client says something is wrong, correct them - it is actually right, because it exactly matches their specs - but you are happy to have the client alter their specs (with the associated costs). Thus there is no slipping in changes unofficially, they have to go through the process.

It's because it's no skin off his/her nose to change things at whim, they can flip-flop with no loss. They have a fleeting fancy, and just need to say it, there is no work in saying it, since you are doing the work. To them it's free. Once there is skin off their nose to do these things, they stop doing them.
posted by -harlequin- at 1:03 PM on November 22, 2006

Incidentally, this is a client you can afford to lose, and quite possibly, can't afford to keep. If you can ensure the higher-ups know this, then you won't have to worry about a souring of relationship with the client once you implement a firm proceedure.
posted by -harlequin- at 1:07 PM on November 22, 2006