Burning Consulting Questions: How To Get Clients?

I talk to a good number of freelancers/consultants, and I hear this same burning consulting question from a lot of people, both new and established:

I understand you run a successful consulting business and was wondering if you have any “tips” regarding how to get clients?

OK, here comes a “Constulants hate him” moment: I haven’t had to work all that hard to keep my business busy. I’ve been reasonably fortunate in two ways regarding client acquisition:

  1. 80% of my firms’ work comes from word-of-mouth referrals, and
  2. The other 20% comes from people just phoning in after finding my company on Google.

The majority of my business revenue comes from selling new projects to existing clients, far more so than by selling new projects to new clients.  My experience has been that the best answer to “how to get clients” is “sell to the clients you already have”.

That said, at the moment I do find myself looking to fan the flames of marketing a bit. I recently devised a new strategy for marketing my business locally, and I’m not 100% certain it’s going to work. Keep Reading…

12 Things I Learned in 12 Years of Freelancing

So, it turns out that Cogeian Systems turns 12 years old this month. I’ve decided to share some of my experience from these 12 years. Maybe it helps, maybe it doesn’t…but I hope it does.

1) Sometimes turning down work is a good idea.

I am a firm believer that freelance and consulting work is like sunlight; there’s enough for all of us to get a tan. But sometimes it doesn’t feel that way. Sometimes you’re up against a mortgage payment and the sales funnel is covered in dust. In these moments, a nightmare client will *always* appear, sensing your weakness and desperation, enticing you with a big fat check (but not as fat as it would be if you weren’t desperate), if only you can accommodate their abusiveness, idiocy, or micro-managing.

What do you do? Keep Reading…

Productive Jealousy – Is There is Enough Sun for Everyone to Tan?

One of my all-time favorite articles is Productive Jealousy on Signal vs. Noise.  David Heinemeier Hansson insists that jealousy need not be an angry or destructive emotion.  I tend to agree with him – in fact, negative emotions are my primary motivation.  I suspect that there is a conception out there that in order to be productive and successful you have to be all sunshine & rainbows, hoping to make the world a better place.  In truth, just as much productivity is fueled by “I’ll show you!” as it is by “Gee, guys, isn’t this spiffy?” Keep Reading…

So You Want To Be A Software Consultant?

So you want to be a software consultant, eh? I hear “how do I get into the business” questions a lot. I suppose I could save this for my next Monday Consulting Questions article, but I think I’d like to finish the month with a bang. So, let’s talk about it today.

There are several things I think you need in order to launch and have some assurance of success. Note that this list is by no means conclusive, it only represents the things that occurred to me in the shower this morning.

Experience. Ideally, you’ve been developing software professionally for at least 5 years, with steadily increasing responsibilities. You want 5 actual years of experience and growth, not 1 year of experience repeated 5 times over. But wait, there’s more. Hopefully you’ve also been able to spend about a year as a Team Lead or in some other position that lets you work at a slightly higher level, learning to manage people and allocate workloads. It would be super super ideal if you managed to get some project management experience too. In fact, I’ll go so far as to say that when launching a software consulting business, being a good project manager will be at least as important as being a good coder. If you don’t have any project management skills, be prepared to learn some.

Humility. Just because you’ve been a dev for 5+ years does NOT mean that you know it all. Preferably you’ve made some serious blunders, learned from them, and done better the next time a similar situation presented itself. If you’ve never fallen on your face, odds are you haven’t attempted anything worth a damn.

Wisdom. Read these: Peopleware; The Mythical Man Month; Code Complete; Under Pressure and On Time Project Planning, Scheduling and Control; Slack; The Art of the Start; Book Yourself Solid; Million Dollar Consulting; Influence; The Time Trap; The E-Myth. Don’t argue, just read them. Read them all. Then read them all again. You don’t have to agree with them or even do what they tell you to do. But you do need to read them.

Contacts. When I say contacts, I’m talking not just about people you know, I’m talking about people you know who can be of help to you in launching your firm. People who can hire you for project work. People who can introduce you to other people who can hire you for project work. People who like you. People who want to see you succeed. People who will benefit if you succeed.

Clients. I can hear you already: “Well, DUH, Christopher.” But bear in mind that when I say you need clients, I’m saying that you need clients BEFORE you launch your firm. Don’t form a corporation, rent an office, buy computers with fancy 20" dual LCDs, hire a staff of 5, and then try to find clients. Oh no. Get yourself a few projects first, THEN launch. Deposits for several projects can make for decent start-up money. Work your network of contacts to find your first clients before launching your business.

Money. I’ve heard it said that professional services (like software consulting) are the easiest type of business to bootstrap. This may or may not be true. There’s another saying, though, one that I particularly like: always be prepared. Try to have as much of a financial cushion as possible before you launch.

A Team. Now, this is going to be controversial, since there are plenty of successful one-man operators. In fact, I used to be one, and even argued with Joel Spolsky about it. But the fact of the matter is, the sooner you are able to start delegating work, the sooner you can spend time working ON your business instead of working IN your business (kudos to The E-Myth for that saying). Working ON your business means you are building a system for doing business that will work even if you’re not actually billing. Basically, having a team means that you don’t have to do ALL the billable work. Starting out you will likely not be able to hire employees full time. Find some trustworthy subcontractors (former co-workers seem to work best) to begin with and make actual hires once you’ve fattened up.

Nerves of Steel. Launching a business of any kind is tough. When you’re just starting out, you can’t just code. You need to do your own books, you need to sell, you need to write the proposals, take out the garbage, negotiate the lease on your office, pay the bills, serve as technical support, beg your creditors for extra time to pay bills, and oh yeah, you might even write a little code from time to time. Clients will abuse you, they will slow-pay you, they will change their minds twice daily about what it is they really want you to be building. Cash flow will ebb and flow sharply sometimes. You may experience the rush of feeling like you hit the lottery one month, then the despair of feeling near bankruptcy the next. Of course, all of this can be managed, but you probably won’t know how at first. If uncertainty is emotionally difficult for you to deal with, re-think launching a firm.

I’m sure there is more to launching a software consulting firm than what I’ve laid out here. In fact, I know there is. However, I’m not going to be able to think of it all in one sitting; it’s a strange and varied universe we live in, and there are plenty of things that can make your consulting experience very unique.

If you would like to suggest additional requisites that belong on this list, go ahead and leave a comment.

Do Your Clients Ever Make You Furious?

If so, I offer a free 10-day e-mail course that can help you resolve exactly the kind of conflict that’s outlined in the article above.  Paying late, not responding to emails, arguing about art direction…enough is enough.  Sign up for Conquering Client Conflict today and learn to make more money & get more respect by squashing these conflicts.

Monday Consulting Questions: Scope Creep and Getting Paid

Today I’m just going to tackle one Consulting Question.

Q. I need to negotiate payment on a project that went out of scope. How do I do this?

A. Trying to get paid for out-of-scope work after it’s been done can often be like trying to un-ring a bell. Depending upon the circumstances, it may not even be possible to get that scope creep paid for. So, let’s look at the circumstances.

The first thing to think about is, how do we know this project went out of scope? Do we have a measurable way to determine what features comprise the project’s scope, like a functional spec? If not, you have a real problem, because without some record of what the project’s expectations were at the start, anyone can interpret anything however they want. To be honest with you, if you don’t have anything to prove that the project is out of scope, you’re sunk. Start negotiating and be happy to get whatever you can get.

Now, if you do have a scope document, you’re on more solid ground. However, you’re not out of the woods just yet. Did you set the client’s expectations correctly? That is, did you either:

a) notify the client at the outset that additional features would increase the cost, or
b) notify the client at the time of the change request that the change would increase the cost?

Yes, I know your client is staffed by adults and that adults have no excuse for thinking that more work costs nothing extra, but to be perfectly honest, nobody cares about you or whether or not you are treated fairly. It’s sad but true:

You get what you negotiate. Nobody will be fair with you; you have to defend yourself at all times.

So, if your client can throw up the “but you didn’t TELL me this would cost extra” defense, you’re in a tough position with regard to scope creep once you let it happen. At best, you can point to the scope doc and offer to remove the additional features if they don’t want to pay for more then the original scope. But in all honesty, the moment a client plays the “but you didn’t tell me” card, you’re sunk.

The third scenario — the one that puts you in the best position — is that you have both a scope document and you have communicated effectively with the client. The scope documentation proves what you were setting out to build, which means that anything not in that document doesn’t exist. So, changes are easy to identify and scope creep is easy to illustrate. The communication ensures that at the very start of the project OR at the moment a change request came in, the client was informed that yes, when you request more work, you have to actually PAY for it.

This is a one-two combo that even the most dishonest of clients will have a hard time applying twisted “you should work for free” logic to.

Here’s how I manage scope creep at Cogeian Systems:

  • Every project has a scoping phase, even if it is lightweight. We believe that figuring out what you are building is a normal part of any project. Any client that refuses this and tries to order you to “just get started” is a client we don’t want. Experience has taught me that ambiguity is frequently an ingredient in abusive client behavior.
  • Clients are informed before the project even begins that changes to the project plan WILL result in a revised estimate. Sometimes, the revision means that the estimate goes down. Sometimes, the revision means it goes up (obviously, in the case of scope creep, the estimate goes up). The determining factor is whether we are adding features (which is usually the case) or consolidating/eliminating features.
  • Clients are also informed that some degree of scope creep is normal, because nobody can know in perfect detail what a project will consist of. There are unknowns in everything, and software development is no exception.

I don’t necessarily think that scope creep must be avoided. It CAN be avoided, but I don’t think it MUST be in every case; sometimes scope creep is a good thing for a project — it can be a sign of opportunity for the client, and a chance to (ethically!) up-sell for you as a consultant. However, there is no question that scope creep must be managed. The client must have an opportunity to think about the consequences of change in terms of additional cost, longer delivery time, additional complexity, etc. And the developer must be paid for the work provided.

So, the short answer is, you get paid for out-of-scope projects by defining a change process before the work ever begins. Barring that, it’s up to you and your negotiation skills. Try to do better next time.

Do Your Clients Ever Make You Furious?

If so, I offer a free 10-day e-mail course that can help you resolve exactly the kind of conflict that’s outlined in the article above.  Paying late, not responding to emails, arguing about art direction…enough is enough.  Sign up for Conquering Client Conflict today and learn to make more money & get more respect by squashing these conflicts.