by Steven J. Owens (unless otherwise attributed)
Note: In general, I highly recommend Janet Ruhl's books on contracting, as a good "nuts and bolts" resource. Unlike the vast majority of books out there, her book The Computer Consultant's Guide does NOT focus on marketing yourself, writing a business plan, or negotiating a contract. There are plenty of books on these topics (some are even good). What her book does deal with are all of those unsettling yet matter-of-fact, day-to-day, nuts and bolts unknowns.
Here's the table of contents, which gives you only a hint of what's in the book (for example, the first chapter, "What Do Computer Consultants Do?", lists and describes in a paragraph or two the various different kinds of consultant you could be, and what some of the strengths and weaknesses are):
In general, pricing is either "Time & Materials" or "Fixed Price". Time & Materials is a pay as you go approach, generally paying by the hour. A fixed price is a set amount for a specific delivered product.
In general, "Time & Materials" is better, because in general, people don't know what they want, and they don't realize how much they don't know about what they want.
A good "Fixed Price" contract is ideal, because you can figure out exactly what they need, and what it'll take to deliver it, and if you're good, you figure out how to deliver it for a price that's competetive but at the same time makes you a healthy profit.
HOWEVER, I strongly suspect the ideal fixed price contract is just that - a platonic ideal that will never exist in the real world. The software field's biggest problem is project management, and the number one problem cited by project managers is sliding scope, aka feature creep. There are enough books on this topic to build a house, so I'm not going to get into this here.
I strongly suspect that unless you're going to set up a full-fledge consulting shop, there are too many variables involved (and variables mostly outside your control) to seriously do a complex fixed price contract. The exception would be where there is either a very clearly defined, well-known and accepted specification (i.e. "We need an IMAP client") or a problem domain you're so thoroughly familiar with that you can spec out an unshakable set of requirements and have a quick turnaround time for delivery.
In a situation with any haziness or vagueness, it's better to have them paying you by the hour until they get what they want. Or at the very least, paying by the hour until they know what they want. To make the best of a bad situation, if they require fixed price and you decide you have to go with it, do two things. First, break the project out into a requirements phase where they pay you to figure out what they want. Second, generally break the pricing down into three chunks; the first when you start the project, the second when you deliver the code, the third when they finish their acceptance testing (and have a solid deadline for the acceptance testing, at which point they will pay you whether they've finished testing or not).
For time&material, however, it's best to give 'em weekly bills. Most of the time there's a lead time for billing - 30 days, or 60 days, or even 90 days (common for large companies). So the sooner you start submitting your bills, the sooner the clock starts. Also, by giving them regular bills you establish some regularity, continuity, a rhythm of expenditures that helps the client get used to paying you.
Remember the underlying psychology of this situation - most of the time, the client is not at all familiar with programming, and is uncomfortable dealing with unknown territory. Reducing the unknowns for them helps them and it helps you. Also, there are going to be knowns and unknowns for you - this is a regular part of software development. But you can clarify and delineate for the client what is known and unknown, which reduces the problem for the client. You can nail down the "X factor" and give them some kind of handle on it.
In your weekly billing, I hate it, but it's best to have a concrete list of things time was spent on. Make extra sure you track time spent on bullshit. If you end up spending any length of time dealing with management, or attending time-wasting meetings, or following up and chasing down promised information, make sure it's listed in the bill. Close the feedback loop so the client can see where their own responsibilities are costing them money.
One tricky bit is balancing up front time spent getting the contract vs. free consulting. You don't want to end up spending eight hours talking to them and then they say "Oh, fine, we don't need to hire you then." Likewise, you don't want to end up spending a week figuring out what they need before you actually get to start billing them.
I'd suggest you do the first meeting with them, scope it out, get a sense of what they're looking for. If they just want a tactical consult, you should be able to establish the parameters in the first hour of the meeting. You sit down and talk about what they want to do in general terms, and what kind of role they're looking for you to play.
Then you say, "Okay, so you really just want a tactical consulting gig to get the server and core up and running and get you guys started on hooking for VTK stuff into it. "So let's call that 8 hours as an initial gig, and then you can call me in for a followup consult later on, or we do spot-consulting via phone/chat/email as needed."
Or alternatively, you say, "Okay, sounds like you need a rough plan for how to integrate your VTK-based visualization client with the server Why don't we do a 20-hour architecture consultation...followed by two four-hour follow-up visits. The first one we'll go over the architecture and talk about your technical capabilities and what you can handle yourselves....and the second one we'll map out my further involvement with the project."
The general idea in setting up the gig is, again, to a) break it down, and b) map out the knowns and unknowns.
I'd say don't bill for the first hour, but go in with an intent to start billing by the end of the first hour.
In general people are always going to want to get a feel for what the money will be. You want to know what they have to spend, they want to know what kind of hole they're getting ready to dig. In general it's a bad thing for you to cite a rate and price before you know more about what they want, but you also want to get a good idea of what kind of money they want to spend, so you can avoid trying to sell them the wrong size solution. You also want them to be comfortable talking to you, which means you want to give them some idea of what they're getting into.
Don't always assume that rates are set in stone. Just because you are currently asking for one rate doesn't mean that rate will never go up. In fact, in a long, involved conversation on a particular consulting mailing list, a lot of folks commented that when they raised their rates, they did indeed lose a few clients - mostly the pain-in-the-ass clients. They kept most of their clients, and they got some new clients. Sometimes potential clients use your asking rate as a way of filtering YOU. They go with somebody who asks for more because they suspect a low-ball rate to be either a) lying about the eventual cost, or b) too inexperienced to know better.
In general, besides being able to raise your rate every now and then, you can use numerous situations as an opportunity to raise your rate, if you think it's a good idea. For example, you could quote an initial rate as a ballpark figure for a vague query, but then raise it after hearing more about specifically what they want.
For example, if you go in and they want a tactical consult, you can either stick with the current rate. Or raise it. Basically, you can decide a) okay, so this is a low-overhead tactical consult, they just want me to help them get it up and running, so it's easy, stick with my initial rate. Or conversely, b) this is a one-shot so I might as well get more.
OR do it the other way around; you can say that for a longer term gig you need to raise it a bit because of the overhead involved.
In general, I'd say you have to balance between not underestimating yourself (something competent people often do) and not raising your rate for arbitrary reasons.
Somebody once told me, from a first meeting they want to get:
a) Who they are, what they want to do, why they want something like XYZZY, what their requirements for such a project are, what lifespan and importance, schedule, etc. of project is, and what kind of roles they expect to take in its development
b) Let me introduce how I can contribute, what I know, my background, my experience, my interests, and what I can accomplish with the technology
Initial expectations are a tricky balancing act. On the one hand, you want to go in without expectations so you can investigate, get the background and figure out what they need and can afford. On the other hand, don't underestimate how out of their depth they may be. If the clients are are geeks, so it won't be as bad as in some of the situations I went into, but your assumptions can kill you. So be cautious about assuming.
You might do a bit of the feeling out during the opening minutes, while waiting for people to arrive, getting coffee, etc. i.e.:
"So how did you end up contacting (whoever referred them to you), anyway?"
This might spur enough discussion to tell you where he's coming from, without you making leading suggestions. This helps establish the "purpose" section of the agenda, by the way.
They might be ready to barrage you with their ideas about what they want you to do. Or you might need to prod them into telling you enough. Or you may need to interview them in depth. If they need in-depth needs analysis, of course, then you have to move that to after you start the clock.
Salesmen have this thing they do, called "qualifying", meaning, figure out who signs the checks (metaphorically) and thus who really has the authority. Lucky you, you're not selling snake oil, so you can just come out and ask, "Who makes the decision to spend money on this?"
In a technical consulting situation, you'll also often do the "technical tail-sniffing" where you and their local top gun will bounce terms around just enough to get a sense of how full or shit (or not) the other guy is. Sort of like a pair of modems vectoring in on a commonly acceptable speed (come to think of it, I'm not sure modems actually vector in (which would imply that one is moving up while another is moving down), but you get the idea).
Another tip I picked up from salesmen is to ask for the sale. At some point you have to stop and say, "Okay, so are we going to do this? Do we have a deal?"
Or, as one sales person I know put it in his own inimitable way, after the client asked for yet another of the interminable series of architecture and design meetings, "So should this be something we should be billing you for?"
One of those gotchas about negotiation is the classic "he who names a price first, loses". This is particularly annoying if you don't have a good idea of what to charge.
Blink Pricing is a technique you use when you're not sure what kind of budget they're expecting. You break your pricing down into increments, and then watch their faces very carefully as you discuss the pricing.
"That'll be an eight hour initial engagement at $100C/hour..."
"... that will map out the architecture, and then we'll have a 20 hour implementation phase..."
"...and then of course there's any custom development you need which may take 20 to 40 hours-"
"-but of course that's only likely if you have very specialized needs."
This can be a handy technique, and in general it follows the strategy I outlined earlier - map out the knowns and the unknowns. Break the risk down for them.
This's the kind of thing that comes either at the end of the first (1-hour) meeting or in the presentation of a proposal.
I can't teach you how to negotiate - for one thing, I'm not really qualified. For another, there are a lot of books out there on this topic and I certainly can't reproduce them here. However, one trick to watch out for is silence. It's a common negotiating tactic. People hate silence, they want to fill it with something. If it's a negotiating silence, it's almost always a mistake to fill it, particularly if you've stated your position and the other side is just stalling to see if you'll weaken.
I learned this almost by accident. I was in the somewhat contradictory situation of having already given away the store - having nothing left to lose made the negotiation process a lot of fun and very educational. The other guy kept trying to chisel a little more out of me and I just gently smiled, shook my head, and said "Nope, I've already given you my rock-bottom price."
He eventually tried the silence trick. He even left the room for a bit, to let me stew I suppose. Fortunately I'd brought along a programming book to read. This is a general habit of mine, which I recommend. It's a good way to kill time, if you pick an obscure enough title (dummies books are NOT recommended - I prefer O'Reilly books on obscure topics, often Nutshell books) it helps establish some technical credibility (both with the business guy, who can't understand what you're reading, and with the technical guy, who can), and it also strongly establishes that you're relaxed and confident.
So I read my book for five or ten minutes, and he came back into the room. He just sat there, staring at me. I just smiled and relaxed and let my thoughts wander. If you're feeling too much pressure to say something, find something else to focus on. Analyze his tie or his hairline or something - this may have the amusing side effect of making him nervous.
Eventually he looked at me and said, "We're not negotiating, are we?"
"Okay, we'll go with your last price."
Go in for the first meeting. Have an agenda. Literally, get a notepad, write it down. Stay high level for the first hour. Get a sense of what they need. The agenda is just to give you a structure to start with. Be ready to modify it if necessary, but having a list like that will help you avoid getting bogged down.
Keep the agenda simple. Give them a copy of it ahead of time, but if it's really simple (as below), don't sweat about getting it to them more than a few minutes before the meeting. What I personally like to do, if feasible, is write it out on a whiteboard and follow along the whiteboard throughout the meeting, checking items off or moving them to other sections. This gives the meeting a common focus (instead of everybody being busy staring down at the table in front of them) and helps keep everybody synchronized. You should still give people their own copies to write on, and of course jot your own notes down on your own notepad.
Here's my rough suggestion for an agenda. I wouldn't actually write all of this out, just enough key words (the titles) to remind yourself; this keeps it loose enough that you're thinking, not just reading off a printed sheet.
An agenda is useless if you don't use it. But it can also be crippling if you over-use it. An agenda should be more like a set of keyword notes that you follow and manipulate as appropriate. Generally a good approach is to have an agenda broken down into three stages:
You can move things down the list, so, for example, you bring up source licensing and either they say "no sweat" and you check it off.
Or you move it to the five minute section, and when you get there, discuss it briefly to see what their stance is and what your stance is, and if you can see some immediate way to resolve the differences, great. If it looks like it'll need further discussion about the merits of different approaches, move it to the general discussion section, or table it till a future meeting.