Monthly Archives: June 2005

In Defense of Differentiation

Cory Foy has posted on JoS that his company is moving to a system of forced ranking, where each employee is classified as an A, B or C performer.  (Aside:  This practice is known as Differentiation and was famously used by Jack Welch during his tenure as the CEO of GE.  Differentiation was most recently discussed in Welch’s book Winning.  Note that I am not an Amazon affiliate and make no money if you click that link, but I will say that I liked the book and encourage you to check it out.).  Cory is curious if such a system has ever worked out well.  The comments that follow Cory’s post skew against forced ranking, more commonly known as Differentiation.  This is no surprise, as most employees are unaware of one very important fact:

Your company is already ranking people, whether you know it or not.

Let’s be real here – is there a manager alive who can’t tell you who his star performers are?  Is there a manager alive who can’t tell you who his problem employees are?  Of course not.  Once you have those two data points, deriving the third (average performers) is a snap.  Is there anybody who really, truly believes that management treats every employee the same way?

Speaking for myself, if management is already differentiating employees into groups based on performance, I’d much prefer to have it be a codified, publicly-revealed policy than have it be a behind-closed-doors affair.  When it’s all out on the table, the employee at least has a chance to know where he stands and to find out how he can improve (or at least maintain) his performance.

In order to make differentiation work, you can’t just rank employees and let that be that.  You need to a) make sure every employee knows where he stands, b) set crystal-clear, measurable and attainable performance benchmarks and c) provide sufficient resources and coaching to give every employee a chance to hit his marks.  If you simply rank your people and then later punish them based on their ranking, you have just engaged in “gotcha!” management, and I have no respect for that.  But if you come up with good metrics, rank your people, and provide the feedback and guidance needed to let an individual work his way out of the Cs and into the Bs, or let a falling A correct himself to remain an A, you’ve done everyone a good turn.

Think about it.  If you differentiate with clear metrics and sufficient resources, when it is time to fire someone there are no surprises.  The employee is not living with an inflated estimation of his performance.  The manager has actual data to back up his decision.  The employee, presumably receiving feedback the whole time, will be aware that his performance has either been sinking or not making the cut, and will have had an opportunity to psychologically prepare himself, maybe even polish up his resume before the axe falls.  It is, in short, a much more humane experience than most firings.  An anonymous reply to Cory’s post reads:

Well, that sounds awful.  So basically it removes all incentives to help your coworkers?  So instead of helping someone when they have a question, you just blow them off because helping them out might bump you down a ranking?

In any well-thought-out system, helping your fellow co-worker should increase your ranking, not hurt it.  We’re not talking about Lord of the Flies here.

Case in point:  almost 3 years ago, I was laid off from a job.  It was a good job – I had interesting work to do, I was being paid well, I liked my co-workers.  It wasn’t perfect – no job ever is – but it was good.  At every feedback encounter, I was told that I was a high performer.  So far, so good.  So imagine my surprise when, in the second of three layoff rounds, I received a pinkslip along with several co-workers whom I had heard spoken of as not-so-good performers.  I was shocked.  A thought came to mind:  maybe I wasn’t really a top performer.  Maybe I’d been having smoke blown up my backside.  Either way, I had no way to know that I was even a candidate for layoff.  And of course, no company will tell you why they axed you after the fact, so to this day I have to wonder.  I’ve heard scuttlebutt that it was purely about salary, as the company was allegedly bleeding cash, but I’ll really never know, because that company did not practice a policy of open communication with employees regarding where the employee stood.  If there was anything I could have adjusted performance-wise to avoid being sacked, I never knew it.  If there was nothing I could have done to avoid being sacked, I never knew that either.  Does this sound like a humane way to handle such matters?  What makes this even more astounding is that the company built enterprise tools to help Fortune 500s manage the performance of their employees.  Oddly enough, these tools were not used in-house – we didn’t eat our own dog food.  If our own products had been used in-house, a number of people might have been a lot less surprised to be laid off.

To this day, when clients complain about employees not doing what they should be doing, I encourage them to make their performance expectations completely clear, because the sad fact is that employees often get in trouble for things that they did not know they were responsible for.  This is patently unfair.  I have even helped clients to create customized tools that help management and employee alike set goals reasonable goals together and come up with plans to achieve them.  It only seems right.

Given a choice between “gotcha!” management or properly practiced open differentiation, I’ll take a numeric ranking and a performance plan 100 times out of 100.

Wouldn’t you?

Andy Budd’s 10 Bad Project Warning Signs

Andy Budd really gets it.

Andy recently wrote a brief article entitled 10 Bad Project Warning Signs, and it is spot-on.  Reading the article, I felt as though Andy had opened his mouth and my words came out – I identified with his article that strongly.  I feel that Andy’s piece makes an excellent prequel to my own article about the 11 Clients You Need to Fire Right Now.  Follow Andy’s advice and you’ll avoid these kind of clients altogether.

Alright, enough gushing – let me quote the 10 top-level points of Andy’s article.  You can read it yourself to get the finer details.

1. The project needs to be done in an incredibly short space of time, due to a fixed deadline.

2. The potential client says that they have no idea about budget.

3. The potential client says they have a budget but won’t tell you what it is.

4. The client says they want the site to be as cheap as possible, or they have an extremely low budget.

5. The client expects much more from the project than their budget will allow.

6. You are expected to come up with design ideas for the pitch.

7. The potential client won’t tell you how many agencies they have contacted about this project.

8. You will be pitching against a large number of other agencies.

9. There is no central point of contact.

10. The potential client hasn’t provided you with a request for proposal and doesn’t have the time to fill in your design questionnaire fully.

I agree that these are HUGE problems.  Andy goes into more detail on exactly why these are problems in his article.  I don’t want to quote the whole thing here and spoil it, because you really should read it.  It’s obvious to me that Andy is a fellow grizzled veteran of the game, and he’s seen the myriad ways that clients – intentionally or not – sometimes make themselves virtually impossible to help.

I remember a recent client who was a combination of “tight deadline” and “no budget.” They wanted to do an extremely significant web project and have it launch within 2 weeks of our initial meeting.  Their total budget was tiny.  Both the deadline was the budget were a complete mis-match with the scope of the project.  Although I warned them that the project was high-risk and would require certain compromises in order to meet their budget and time constraints, and although they agreed that the compromises were OK so long as we could go back later and tune things up, in the end nobody came out happy.

Despite having agreed to the initial compromises, the client expressed disillusionment and bailed out of the “tune things up” phase of the project.  I was unhappy that they had bailed out on me on account of things that they had agreed to.  It was a great big mess, and one that could have been avoided if I had said “no” to the project.  The aftermath is bad for both of us: they’ll probably badmouth me despite my best efforts, and I’ll never trust that client or any business associated with them ever again.  Because I agreed to a project that was obviously ridiculous, we both lost.

Given the client’s grossly mis-matched budget, schedule, and expectations, that project had little chance of making it, and I suspected as much from the get-go.  Why did I accept it anyway?  Because the client agreed to significant compromises that brought the scope within what could be done for the time and money.  I had no idea that they’d suddenly go back on that, but frankly, after 12 years in the business, I should have been better able to identify this as a bad risk and move on.

Don’t make similar mistakes!  Give Andy’s item a good read, and have the courage to say “no” when a risky proposition comes your way.

Project Aardvark Revealed

Project Aardvark is a relatively novel publicity stunt organized by Joel Spolsky, the current grand master of small ISV publicity techniques.  The idea is to have a team of interns churn out a whole product over the summer, all while being filmed for a documentary.

From Yaron’s latest Project Aardvark blog post:

On the name front we had a meeting today and decided on the final name.  It’s all registered and a preliminary site is even uploaded.   Good luck finding it 😛

Much ado has been made about dropping hints as to what Project Aardvark does and how secret it is, but come on.  It’s a registered domain on a public webserver.  It’s not going to stay secret very long if you taunt people like that.  Eventually, some inquisitive soul is going to go looking.

In this case, the inquisitive soul is me.

I present the “secret” product of Project Aardvark:
From the site:

SidePilot allows people to help their friends, relatives, and customers fix their computer problems by temporarily controlling their computers via the Internet. It costs $9.95 for a day pass, or you can try it for free for five minutes

In short, it appears to be a competitor to

There you have it, folks – the big secret revealed.  And being the savvy marketer he is, I’m sure Joel is pleased as punch that someone took the bait and went looking for it, because now all the buzz-y conversations will start.

You’re welcome, Joel.  :p

Unavailable = Effective?

I’ve told you once, and I will tell you 1,000 times more in my career:  if you are not 100% unavailable for at least 2 hours a day, you probably aren’t getting much done that’s of any importance.

Although I not-so-famously disagreed with Jason Fried on the issue of functional specifications, I find myself 100% in agreement with Jason’s position on spending time alone.  Jason’s recent post demonstrates a solid understanding of what it takes to be effective and productive:

Getting in the zone takes time which is why interruption is your enemy. It’s like REM sleep – you don’t just go to REM sleep, you go to sleep first and you make you way towards REM. Any interruptions force you to start over. REM is where the real sleep magic happens. The alone time zone is where the real productivity happens.

I couldn’t have said it better myself.  But Jason takes it one step further than even I did:

So, what do you do if you aren’t 8 time zones apart and forced into alone time? You require it. Set up a rule at work: make half of the day alone time. From 10am-2pm, no one can talk to one another (except during lunch). Or make the first half of the day alone. Or the last half. But make sure to make the alone time zone contiguous – interruptions kill productivity.

Wow.  Half the day!  It seems excessive, but I like it.

We live in a grossly over-connected world, and I am convinced that the communication overhead we all have to put up with makes our professional efforts feel like running a marathon while knee-high in molasses.  I don’t think anyone can challenge Jason’s’ assertion that developers are most productive when nobody else is around – in fact, this stands for most jobs in most industries.

As usual, I can hear all you would-be artiste types getting ready to use this as a justification for refusing to communicate with anyone, ever but bear in mind that before you can set up a no-interruption schedule, you have to actually talk to customers, co-workers and managers alike to figure out what it is you’re supposed to be building.  And yes, that might include writing a functional spec.  Deal with it.  😉

But in general, yes – be less available.  Be more defensive of your time.  Be as in control of how your time is spent as you possibly can.  Your clients may whine at first, but once they see the results, they’ll thank you.

Interesting Responses To “11 Clients” Article


I seem to have stuck a chord with some folks – both good and bad – with my article about 11 Clients You Need To Fire Right Now.  I’ve gotten more feedback on this piece than on anything else I’ve written to date.

From my eMail:

“Don’t expect to stay in business for very long with that attitude.”

“Without burning bridges, you just enumerated a series of client archetypes that we have all worked with.  Great job!”

“You can’t just fire a client if you are under contract to complete a job for them.  I hope you get sued for breach, you smug ass.”

“I’ve always been afraid to stand up for myself against abusive customers, for fear of losing a contract.  But if you can do it, maybe I can too.  Thanks for talking about this!”

“You are now #1 on my list of vendors I will never work with.”

From my discussion forum:

Fletch writes, “I can think of a great topic for an article called “The One Software Developer Who Should Be Fired Right Now.”

John Borkowski writes, “Every one of the clients listed in the article will cost you money– at best by wasting your time, at worst by not paying at all.  If anyone honestly wants to serve clients like that, I have about 30 referrals for you.”

Gary writes, “If a vendor broke a contract with me because he didn’t like the payment schedule or because he decided I wasn’t a big enough fish, I’d see to it that vendor never worked in my industry again. Period.”

Around the blogosphere:

Eric Wise writes, “I couldn’t agree more.  It always amazes me when clients consistently pay late knowing that my company has employees and subcontractors that I’m responsible for.  I often wonder how they would feel if mysteriously their next paycheck was a month late.  Generally though I don’t consider this a client firing event unless the lateness is extreme.”

Kevin Dangoor writes, “I think everyone who has been doing software for a while has worked with some suboptimal clients.”

Joey deVilla writes, “I’m certain that Hawkins is speaking from real-world experience; I’ve seen a number of these client types from my consulting days and from horror stories told around the bar at developer gatherings.”

Overall, traffic has spiked by 100% in the past two days.  It seems as though the other consulting pros of the world have felt the same pain I have with regard to abusive clients.  Of course, the bad ones serve to help me remember to appreciate the good ones.

A word about breach of contract, which seems to be a relatively common concern when discussions of firing a client come up:  don’t you all write termination clauses into your contracts?  The client might decide they don’t like you, either, and want a way out of the contract.  Nobody wants to get up every morning and either work on or pay for a contract he is unhappy with.

In general, my company has a policy that either party to a contract can cancel for any reason with 10 days notice.  Work to date must be paid for in full, of course, but if a client isn’t happy with our service there’s no way I’d try to strong-arm them into staying.  And it works going the other way as well.

Is my company the only one that does this?

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.