Christopher Hawkins - effective Software Development and Web Design project management

Monday, June 13, 2005

11 Clients You Need To Fire Right Now

Since I'm constantly writing about what developers do wrong, it seems only fair to address problem clients as well. I recently had to terminate my business relationship with a couple of clients, and a couple more may be on the way. I know I'm not the only one, so perhaps these insights will be helpful to other independent operators.

Everything in nature has a life span - creatures, relationships, weather systems, everything. We rarely know how long that life span will be, but once something's life span is at an end, it is usually obvious. The same is true of client relationships. Sometimes, it is necessary to fire a client in order to serve the bigger picture of what you want your business to become.

Now, it's one thing to suggest that some clients are best avoided to begin with, but considering the way most small businesses operate right on the razor's edge, it sounds downright crazy to say that you should actually get rid of current clients! But it is the truth. The relationship between client and provider - like every relationship between human beings - must be a value-for-value proposition in order to survive. This is commonly referred to as a "win-win" scenario.

Technical projects are tough. You can crack open a textbook and find the classic 7-step project management methodology, but out here in the real world, strange things happen. People don't always do what they say they will do. Things take longer than expected. Third parties toss the occasional monkey wrench into the works. These kind of things have to be taken in stride while keeping your eyes on the prize, so please don't get the impression that I'm suggesting you cut off all your clients for any perceived infraction. Odds are, you do something that bothers your clients on a semi-regular basis, too.

That said, over the years I have noticed certain abusive behaviors that are highly problematic and are often symptoms of behind-the-scenes issues that you have no control over, but that will affect you negatively anyway. So when you notice these abusive behaviors, stop to think about your past history with the client before terminating them. Now, on to the specifics.

The 11 Abusive Client Types

You should fire your client if the client consistently proves to be one (or more!) of these abusive types:

THE DISILLUSIONED consistently expresses disappointment with your work even though it is of good quality and conforms to spec.

I used "and" instead of "or" because as we all know, just because something is to spec does not mean it is of good quality. ;) As you gain experience and complete more and more projects, you will discover that certain clients are not satisfiable. They ask for x, you give them x, and they complain that they wish it was y. You can do your due diligence, be cautious when gathering requirements, lead the client through a thorough analysis of where they are and where they expect the project to help them go, and even receive positive feedback throughout the various project milestones. Sure, they signed off on the spec. Sure, they saw the deliverables every week and approved them. Sure, they told you that you were doing great. Yet, once the project is complete, the client is crestfallen.

What happened?!?!

If you held up your end - and you need to be really sure you did so - nothing happened. You just had the misfortune to take on a chronically unsatisfied client. The problem is, this dis-satisfaction is likely to result in being badmouthed, stiffed on an invoice, or even dragged into court!

A client who is constitutionally incapable of appreciating your work is not a client you should be involved with.

THE SUSPICIOUS consistently expresses a lack of trust, disdain for your work, or questions your integrity.

There really is something odd about software development (and other types of computer-centric work, such as graphic design) that makes people think they can just pick it up over a weekend( I think it has to do with the ubiquity of the PC as a tool, and the fact that people confuse the tool with the skills, but I digress). As such, you will sometimes encounter a client who regards you as something of a scam artist, someone who is charging premium rates for doing what (in his mind) essentially amounts to typing. "After all," he thinks to himself, "my 15-year old nephew seems to know his way around the computer, and he only charges $10/hour. Why, I'll bet I could get HIM to build an enterprise-class ERP system instead of this Christopher fellow, and save myself a bundle in the process!"

Once you become entangled with someone who regards computer work as some sort of overpaid custodial function, you will never be able to submit an estimate, fix a bug or even suggest a solution without being second-guessed and third-degreed to death. If your credibility starts over at 0 at the beginning of every conversation, you will be spending valuable time explaining yourself that could be used doing something with some sort of economic yield for your client. This is not a situation you want to be in. I guarantee that no matter how many times your client forces you to spend two hours to explain the 15 minutes you spent refactoring his data access code, if these kind of things happen to add up and put you behind schedule, your client will not share the blame with you. This goes double if you have that special flavor of suspicious client who will not allow you to speak to their IT department, ISP or previous developer for fear that you will all plot against the client. Being the guy with whom the buck stops can be a lonely road to walk sometimes.

A client who is constitutionally incapable of trusting in your expertise is not a client you should be involved with.

THE CHISELER consistently complains about your bill, even though it conforms to the estimate they agreed to.

So you did your job with regard to setting expectations, you wrote out an estimate that mapped back to the functional spec so everyone knew exactly what was being built and what it was going to cost, and your client signed off on the estimate. Not only that, but you managed to beat your own estimated by 5%! Congratulations, you've done a great job!

So why is your client complaining about how expensive this project is when they had a chance to either sign off or bail out before the work ever started?

It is said that there are no price objections, only value objections. But if you did your job correctly, the client was provided with enough documentation to know exactly what they were buying and what it would cost. Assuming you did your job right, you've likely stumbled onto another form of chronically unsatisfied client - the kind who is always disappointed with the bill, even if he is happy with the delivered work. Some folks really do want something for nothing, it seems, and they will use passive-aggressive tactics to try to get you to lower your bill. Some will even go so far as to refuse to pay, even though the invoice is less than the estimate. Don't fall for it.

A client who is constitutionally incapable of honoring a deal is not a client you should be involved with.

THE BULLY consistently is verbally abusive or threatening to you.

I don't think this even needs an explanation. We're white-collar professionals, not street thugs. Any client that will curse you or attempt to physically bully you (believe it or not, I've seen it happen) needs to be dropped with all due haste.

THE SOMETHING-FOR-NOTHING consistently increases the scope of the project but refuses to pay for the additional work.

Estimates are a funny thing. The very word "estimate" means approximation, not precision. However, it is often the case that when a client receives an estimate detailing "x cost for y units of work", it is read as "no more than x cost for as many units of work as I ask for". I don't know why so many clients seem surprised to learn that if you change the specifications, the amount of work involved - and therefore the total cost of the work - changes, but this is the case more often than not. I also don't know why so many clients treat an estimate as though it is written in stone. Although a service provider should take great care to produce as accurate an estimate as possible, it is still just a highly-informed guess.

But I digress. As I said above, when you change the work to be performed, you change the cost to perform the work. It is a simple relationship. But it is often the case that a client will ask for an additional feature - a BIG one - and then express some combination of shock, disgust, resentment, or even outright anger when the estimate is revised upward to account for the additional work. Certainly these folks don't add items to their grocery purchase after the cashier has totaled them up, expressing shock or anger when the cashier adds the price of those items to the existing total. So why do it with software projects? Again, I suspect this has something to do with the ubiquity of the PC and the inclination of non-technical people to mistake the tool for the skills, but I'm digressing again. The bottom line is, x amount of work costs y amount of money. If you change x, you change y. It really is that simple.

A client who is constitutionally incapable of offering additional value in exchange for additional value is not a client you should be involved with.

THE SLOW PAY consistently pays invoices late.

In any small business, cash flow is king. Heck, in any large business, cash flow is king. So let's just say: cash flow is king, period.

Once you and your client have come to an agreement on payment terms, so long as you are keeping up on your deliverables, your client should be keeping up on his payments. Jack Welch once said "If it's Friday and you got paid, you and the company are even". Well, this applies to business as well. It's tough to have a healthy relationship if one party feels as though the other has gotten "one up" on him. Well, the best way to keep everyone even is for you to make your deliverables on time and for your client to pay the bill on time. Anything less than that from either of you means that the other is being taken for a ride.

A client who is constitutionally incapable of paying a bill on time for work that was delivered on time is not a client you should be involved with.

THE FLAKE consistently is late meeting responsibilities, but still holds you to the original schedule.

We're all well-versed in the classic three-dimensional attributes of a software project: time, cost and features. We're also probably well-versed in the problems that can come along with servicing an undisciplined client who cannot meet his responsibilities according to the project schedule. This by itself is one thing, but when the client is in charge of action items that are blocking other action items, it is a problem. This problem is compounded when you are expected to deliver the project on time despite these blockages. If you've done your due diligence but your client consistently cannot or will not fulfill his end of the project agreement with regard to approvals, copy, design meetings, etc. then your client has no business thinking that his tardiness with these items will NOT impact the schedule.

A client who is constitutionally incapable of understanding that in order for a project to be delivered on-time, everyone must meet their obligations is not a client you should be involved with.

THE LIAR consistently lies to you.

Again, this doesn't even need much of an explanation.

A client who is constitutionally incapable of being honest with you is not a client you should be involved with.

THE BLACKMAILER consistently refuses to pay an invoice until you perform additional work at no charge.

I see this a lot, believe it or not. The Blackmailer is a special subset of the something for nothing. Instead of taking umbrage, he takes hostages - your dollars.

Suppose you and your client disagree on the accuracy of an item or two on Invoice A. Further suppose that Invoice B is also due, for a project unrelated to what's being billed on Invoice A. This brand of client will refuse to pay Invoice B until you see things his way on Invoice A, even though they are totally separate issues. This is nothing more than good old-fashioned blackmail dressed up in a flannel suit. The proper way to handle this is to pay Invoice B when it comes due, then either continue negotiating Invoice A or pay the uncontested amount and THEN negotiate the remainder of Invoice A. That's win-win. Blackmail is always win-lose, and anyone who believes in win-lose in a business relationship needs to be cut off.

A client who is constitutionally incapable of engaging in good-faith dealings is not a client you should be involved with.

THE MONEY PIT consistently is unprofitable.

There can be many reasons a client is unprofitable. In essence, a client is unprofitable if they take up far more time and effort than the fees you are able to charge them are worth. In many cases, this can be a client who demands cut-rate prices, extra unpaid support, or who repeatedly does things that require you to work harder. Heck, it might even be your own fault for agreeing to a bad deal - it's happened to all of us. Just like your client, you are in business to make money. If you and your client are unable to work together in a way that allows you to make money while providing good value to the client, it's time for that client to go.

A client who is constitutionally incapable of offering you a fair rate for your services is not a client you should be involved with.

THE CLINGER consistently makes unreasonable demands regarding your availability.

In this business, you've got to be available to support your clients. We all know that. However, there is a certain standard of reasonability that must be applied to how determine how available you should be. First off, I have a well-known and often contested belief that if you are NOT 100% unavailable for at least 2 hours a day, you probably aren't getting anything done that's of any importance. But at the same time, I'm saying you've GOT to provide reasonable support. Well, certain clients don't care about reasonability, they want the emotional payoff of seeing you get cracking on their latest request...NOW! If I have scheduled development work on the calendar, and a client calls in with an "urgent" request for a new feature, if that client is otherwise stable and the request is not a bug fix, that client is getting put in the next opening on my schedule. They are not getting put at the front of the line just because they want a new feature built by next Wednesday.

This is actually good for the client, as it helps them to impose discipline within their technology projects. And as I've said before, it is good to tell your clients "no" sometimes, so long as you have a good reason for doing so. Anyone who calls with a bonafide emergency gets taken care of right away, no questions asked. But "hey, I thought of this cool new feature, can you have it done by tomorrow"? No chance. As a service provider, you are not a member of staff at your client's company. You are an external provider of services and although you need to available for a reasonable amount of time on a reasonable amount of notice, you will never be able to provide good service if you practice interrupt-driven development.

A client who is constitutionally incapable of applying a "reasonable man" standard to requests for your time is not a client you should be involved with.

Letting them down Easy

There's no need to be rude with a client, although you should be firm when it is time to dissolve the relationship. Not mean, not haughty, not "now I have a chance to get back at him for being mean to me/wasting my time", but firm. Once you've made the decision to terminate, have faith in your own judgment and don't even entertain avenues of conversation related to NOT dissolving the relationship. Rejection is powerful stuff, and an abusive client - much like an abusive lover - will be spooked enough to say anything to avoid allowing the rejection to be final. People react very strangely to the word "no". Clients - particularly abusive ones - are not at all accustomed to being told "no".

Before you signal your intent to terminate, get your ducks in a row in order to make things easier for both yourself and the client. Have their invoices to date prepared as both hard copy and PDF. Have any client-owned project materials that are in your possession boxed up and ready to FedEx to them. Have any source code or database scripts that they have paid for burned to CD and ready to FedEx as well. And if you can do so, have a referral to a different provider ready for them - preferably a provider to whom you have spoken to and qualified as being interested in taking on the client and the project.

As far as the "how" of terminating a client goes, I have done it both face-to-face and via eMail and phone (due to distance). Despite the fact that I am not conflict-averse, neither way was easy. I suspect that most of you will be somewhat conflict-averse and prefer to use the phone or eMail. Be careful - remember that eMail does not convey any kind of tone or vocal inflection, and runs the risk of coming off as brusque or cold. I suggest that you make a list of your reasons for firing the client and review them for your own clarity, but do not get into an argument with the client - each point you bring up is ammunition for an argument about why that item is not really grounds for dissolving the relationship, but you've got to avoid unproductive conflicts. Stay polite, no matter how hot the client gets with you - remember, you are not trying to exact revenge, you are just trying to save yourself from further abuse.

As a service provider, your game needs to be tight. You need to be delivering on your promises and staying on top of your projects. If you are doing so, and you are being abused by one of these 11 client-types, you need to seriously consider nipping the relationship in the bud and giving yourself an opportunity to let the void fill with higher-quality business.

Discuss This

06:18 PM

About Christopher

I am the founder and principal developer of Cogeian Systems, specializing in custom software development, web design/development, and crisis management for software projects.

In May of 2012 I also founded SmallSpec, a web app that enables freelancers and small teams to create painless functional specifications.

Everything you see in this blog is my own personal opinion, based on my experience in the software field.

Follow Christopher on Twitter

©Copyright 2004 Christopher Hawkins | web design: Cogeian Systems