Five tips for handling stubborn clients

When a client asks you to implement a solution that isn't up to your standards, what do you do? Here are a few ways to handle this type of situation.

Consultants don't technically own the project they're working on. The project belongs to the client, and they're the ones who will have to live with whatever monster you create for years to come. Nevertheless, the project feels like your baby. You care about the quality of your work, and you can't bring yourself to mar it with inelegance or stupidity. But you may sometimes encounter a situation when that's exactly what your client wants you to do.

They don't think it's bad, because to them, it's a matter of following standard, documented practices. But you see that the standard has outlived its usefulness and that, in fact, it poses serious threats to the client's success down the road. You explain your thoughts and give your advice on the matter. But your client's technical lead is adamantly opposed to these strange new ways. What do you do? Here are five suggestions.

Note: These tips are based on an entry in our IT Consultant blog.

1: Go with the flow

It is the client's system, after all, and they're paying you to do what they want. You've given them the benefit of your wisdom, and they've chosen to ignore it, so just do things their way. Who knows, maybe they're right after all -- there's always more than one way to look at the pros and cons of anything. Of course, this makes you less than excited about working for them. In fact, you may subconsciously start to think of the whole project as tainted, which could lead to quality slippage in other areas as well.

2: Go away

Ask to be excused from the project because you have irreconcilable differences with the approach. If they won't listen to you, why stick around for the inevitable train wreck? On the other hand, it's highly likely that by dropping out, you could eliminate all future opportunity for engagements with this client. It might also be seen as a scare tactic or even a suicidal cry for attention.

3: Go up the ladder

Take your argument to the technical lead's boss. If you can convince the boss, maybe you can bring pressure back around from the top. Of course, this is likely to create other problems. If the technical lead has to give in, he or she will look for ways to assert control in the future. Watch for hidden daggers.

4: Go out to the masses

Discuss the pros and cons with as many people in the organization as might be interested. Create a buzz over your new ideas until the new ideas overwhelm the old ones. This approach can also cause resentment -- nobody likes to give in to mob rule. So you'll have to figure out how to build that support without casting yourself in the role of demagogue.

5: Go back to the drawing board

Look for new ways to make your argument. How can you express the benefits of the new approach more clearly? Is there a valid way to compromise -- getting essentially what you want, while satisfying whatever need is driving your client? Stop and think: Why is the client so attached to the current practices? What benefits from them, or what threats from your proposal, do they perceive? Maybe you should ask the technical lead just that question -- not in a snarky way, but really looking for reasons. Of course, if the answer is "because I said so" (in so many words), you've reached a dead end.

Other suggestions?

This situation isn't entirely hypothetical for me right now, so I'm keeping the details vague and the participants anonymous. I'm also genuinely looking for your help. What do you think? What combination of the above would you use? Do you have another idea that doesn't fit into these five strategies?


Chip Camden has been programming since 1978, and he's still not done. An independent consultant since 1991, Chip specializes in software development tools, languages, and migration to new technology. Besides writing for TechRepublic's IT Consultant b...


Listen to what they want and make yourself heard. Try negotiation. Give a little take a little.


My first instinct would be to document the issue(s).. using Google/similar to find similar problems and/or explanations and showing the pitfalls of the stubborn client's approach.. then I would ask the client to help me resolve those issues to his/her benefit.. I do realize this is frequently a lose-lose situation for the consultant, if you're confrontational you lose the client, if you're not, you botch the job and eventually lose the client and your reputation. Don't be stubborn yourself but try and lead the client around to your solution, framing it as in the client's best interest (which it certainly should be anyway).


This seems like a great way to present an arguement for why to implement something a specific way, but I've always had trouble with it in the past, aside from lengthy white papers, or the inevitable 'at this other client...' line. Great idea, I just personally have had trouble using it! One trick I've learned is simple, and works, is a basic pros, cons, and cost analysis. If you can quickly outline the pros (and cons) of both approaches, being objective, and then associate the cost with loss, it can be a cheap trick to close the deal, and get it done right.


Isn't what an IT Consultant is "selling" their expertise, as well as their labor? If the client chooses to ignore your expertise after due cautions and conversations, shouldn't you walk away if they refuse to use it? An electrician, for example, if they are ethical, wouldn't just use that random bare wire you gave them to run power to your building, just because you said they must. ;) But, I suppose they might be willing to choose between a cheaper (but relatively safe) circuit breaker box and their "ideal" one. While I understand that clients generally own the product of our work, isn't there a limit, ethically and for the good of the field, to what you should be willing to do? And doesn't agreeing to do low standard work because the client mandated it inherently risk a consultant's reputation? I'm trying to walk this tightrope, too... and BTW, I've done all 5 + #7 in the comments :)


One approach I've found helpful might be seen as "between" 4 and 5 - Go back to the drawing board (communicate a better solution more persuasively) by Going out to the masses, but with the twist of the "masses" being other folks who have solved a similar problem. By finding and showing the stubborn client examples of others "like them" who have solved a similar problem, you a) Keep your persuasion points positive and focused on their success b) Eliminate the "my solution vs. your solution" confrontation c) Help them lower fear of risk by hearing other's success stories (you can also try fear-of-failure stories, but for some reason it's harder to find supporting blogs/white papers about failures, and citing only your own opinion, well... see point b.) d) Demonstrate a honest effort to solve the problem (like ptailor129 suggests.) Even if this client fails to "do the right thing", you gain knowledge for the next round by performing at least a quick review of other's solutions....and who knows, while digging, you might even discover something better which neither of you considered.


I have come across very similar situations in the projects I work on. Go back to the original project plan and see if it needs to be revised to take into account the new information that you have uncovered during the project. Oh wait! Was there a project plan ever written? if not put one together and present it to the technical lead and ask their opinion? If it is good they may very well present it to their boss as though it was their idea. Either way the result is that the correct implementation is done and the technical lead looks like a hero.

Editor's Picks