Consulting: my experience on when to drop a client

Submitted by zac on 2005, April 15 - 8:50am.

Republished from Daniel Lemire's Blog.

I have been consulting for several years. I think my first consultant job was around 1999 or even 1998. I think I told the story on this blog before: I had planned to finish my Ph.D. and then move into industry. At that point, I faced a wall: very few companies in Montreal were looking for fresh Ph.D.s. I cannot blame them, but back then, it was a big disappointment for me. So, I went into R&D consulting with companies outside Montreal (Paris, Ottawa, Marseille). It seems there is a fairly good supply of companies lacking a solid R&D department, but needing the R&D. At least, that's true during some economic cycles. So, I provide ideas, software, documentation, against fair compensation over a couple of months or slightly more. I usually get to keep ownership of some of my work though some of it remain secret.

I stopped consulting for a few years while I was at the National Research Council of Canada (NRC). But now that I'm back as a university professor, I'm back into consulting.

Why do consulting? Firstly, it is fun: you get to work on mostly exciting (read:new) projects that have some importance. Secondly, it pays well enough. If you contribute significantly to a project, you might even be able to negotiate some profit sharing: I was once offered 5% of a company or some cash (I took the cash). Consulting is also a special kind of business: it is focused on your expertise and not on business expertise. You are may have to write bills and do some accounting, but you don't have to deal with bankers and venture capital, with hiring 30 people and finding offices. Consulting also keep you on your toes: you have to keep learning about the new trends. It also gives you valuable insights into what is really important in the industry and what isn't.

Why not do consulting? Uncertain times: you might make $30k in a few short weeks, and then make absolutely nothing for a month or more. If you can live with it, it is not so bad because you can use the free time to do other work like research or learning a new computer language. If times get tough, you might have to do some jobs you don't particularly care for. Also, consulting is not like building a company or a product: your clients do this, not you. Hence, your growth is limited: you can only sell the time you have and this has some pretty dire consequences on how you manage your …'business'?.

As a consultant, you sell mostly one thing: your time. And you have a finite supply of it. This means you must be extremely picky about the projects you do and clients you work with. You must make absolutely sure that it leads you somewhere because agreeing to one project means you can't do some other project someone else will offer you down the line.

This is somewhat counterintuitive at first. You'd think that you'd want to agree to do as many projects as you possibly can, and be nice to all clients. That might be true if you sell T-shirts, but not if you are a consultant.

So, how do you recognize a good project and a good client? Bad projects are not so bad as bad client since most consulting jobs are over short periods.However, sticking with a bad client can have terrible consequences. Fortunately, a good client is somewhat easy to recognize. A good client is someone who wants to work with you specifically and has good reasons to do so.

How to recognize a bad client:

  • He will try to bully you in accepting terms that are not acceptable to you. For example, I've had a client try on several occasions to intimidate me into lowering my hourly fee to about a third of my usual hourly fee.
  • He will have a selective memory. As a consultant, you don't carry along a lawyer, so you need to trust the client to remember the terms you've agreed to. This is usually not a problem with real business people as they can't stay in business with selective memories unless they are called Bill Gates. I suggest that the minute you find out the client as a defective memory, you run away.
  • You don't see how the client has any need for your skills or the client doesn't/can't understand what you can offer. This has happened to me quite often due to the highly specialized nature of my work.

Through Jarche, I found out this nice article in Startup Journal which points out the very same thing. Knowing when to drop a client or a project is one of the most important skill you can learn as a consultant:

I'd just been advised to seek a portfolio of engagements that will spawn new experiences and opportunities, listen to my heart and assess the tradeoffs of each opportunity. So I thought to myself, I don't love what I do for this CEO and working for him isn't expanding my network, making me rich or helping me to achieve my long-term goals. Should I allow him to chip away at me every time I see him?

No questions there. I resigned, confident that I can replace the revenue with more fulfilling and remunerative work. More importantly, I began to feel for perhaps the first time that I'm on the right road.

 

should republished content be editable?

Submitted by webb on 2005, April 15 - 7:31pm.

I get that his Creative Commons license allows it but should we make it inherent by the way we set the properties of the page. It seems like there might be some kind of content we don't want to jointly edit. Republished content like the above, case studies, etc.

What do others think?

re: should republished content be editable?

zac's picture
Submitted by zac on 2005, April 15 - 10:33pm.

I think the vast majority of content should be editable. Even if it's "static" content like a case study, there might be typos, etc that others can improve upon.

In the case of a story like this, I think we need to trust the judgement of the other community members. This piece is written in the first person, so if things are added to the story we're putting words in the author's mouth. Daniel authorized derivative works, not using him as a puppet.

This is a good point you raise, though. I'll be interested to see what others have to say on the matter. Whatever we decide as a result should go in the guidelines we haven't written yet.

Incidentally, right now members don't have control over whether a given page is editable or not. Post it as a "story" and it is editable only by the author and the admin. Post it as a "book" and it is editable.

Zac

Zac Mutrux
Consultant and Commonist
CompuMentor

How to fire a client ??

Submitted by Oz on 2005, April 17 - 5:06am.

This can be very problematic.
Over the years, I have had to fire a few, money is usually the start of the process.

If a client does not give me some form of satisfaction, then it time for me to move on. The money is only part of the picture.
When is it time it move on ??
The second time,you dont get a cheap thrill when the phone rings or the mail box pings. I say the second time as everyone including clients have bad hair days.
If do my job ,a time will arrive when its time for the client to "fire me" but is a good way.
Recently I had a client call up and tell me that they were moving to a bigger consulting company as their network had grown and matured . The network was past a small company and needed a 24 and 7 company. I was happy to hear that in one respect as it means my message had got through to the management.
In this case its like watching your children grow up..
You want to see you children leave but you dont want to see them go.

hmm, depends?

Submitted by eleland on 2005, April 18 - 10:25am.

This content is written in the first person, which makes it difficult to edit collaboratively unless folks follow explicit procedures to identify which edit belongs to which author. I would recommend that these reposts be as storys or pages, not book pages, this would allow the comments to generate. Also anyone could take the conversation into a collaborative space, linking back to this article for foundation material.

- Eric

firing perhaps the wrong metaphor

Submitted by eleland on 2005, April 18 - 10:31am.

Thanks for the comments Oz. It is about firing "in a good way."

I see it about setting expectations and measuring progress against these. With many projects, stakeholders will start out with a common understanding, but then the interpretation or will/ability to perform along the way changes. Keeping a stong focus on the requirements for the project allows stakeholders to part ways when requirements are not met, no necessarily because someone or some group is negligent.

- Eric

Managing your Consultancy

How to do it on your own!

Managing your Consultancy

  • You must login/register in order to contribute to this group.

Navigation

User login