TechRepublic member Kent Skinner sent me a private email asking about value-based fees, a concept promoted by the famed consultant's consultant, Alan Weiss. Weiss believes that you should bill clients for the value you provide them, rather than the time you spend on their project. He summarizes the dichotomy on his blog:

If a client is best served by a problem being remediated quickly, or an innovation being implemented rapidly, or an improvement being installed momentarily, then why isn't the consultant charging for the velocity of the work rather than for the duration?

In other words, hourly billing is inherently unethical. The client's best interests are served by a quick resolution but the consultant's best interests are served by a lengthy encampment. That isn't what I'd call a "partnership."

This makes a lot of sense, in theory. I've always agreed with Earl Nightingale that the money you receive directly relates to the service you provide. Since "service" is in the eye of the recipient, "value" is a better word. No matter how you bill, the perceived value that you provide your client marks the limit of what you can charge them. Violate that equation, and you won't keep your client very long.

Weiss also highlights another side to the same coin: Billing by the hour is unfair to the industrious consultant, because it penalizes getting things done quickly. Hourly billing therefore acts as an incentive to do the wrong things for your client in order to avoid cheating yourself out of the money the client would gladly pay you for the value you provide.

But the dichotomy that Weiss paints between hourly and value-based billing is not always real. It presumes that the client says, "I need someone to do X," and that the consultant can then respond "I can do X for $Y." Some tasks are that simple, but many are not.

The smart consultant should know that the client can usually only vaguely define X, so one way to stick to fixed-price billing would be to change the question in your response. "You're asking for X. For $Y, I can help you analyze your need for X and define what X means, and then we can talk about what it will take to implement X." Or if you're really brave, you can include the implementation in your price and inflate it accordingly. Either way, you force the client to make a value determination before the client even knows what they're asking of you. An hourly rate, on the other hand, allows your client to incrementally discover what they want to achieve. In that case, your time really is valuable to them, because it represents the amount of attention you're giving to their question.

In order to place a fixed price on your work, you have to be able to demarcate discrete results. Ultimately, what you're being paid for are results, but results are often hard to quantify — especially in advance. In research-based projects, the result your client wants is often an answer to the question, "Where do we go from here?" This question recurs so frequently that billing for the value of each time you answer it becomes impractical.

Placing a value on each result chunk also means that the scope of each chunk must remain unchanged — or else it requires a reevaluation. In software development, clients need the freedom to redefine scope dynamically. Sure, for very small projects with well-defined scope you can get by with a fixed-price contract, but even then it often requires rescoping and either you have to renegotiate the price or someone gets cheated.

Rather than drawing a line between value-based and hourly billing, let's draw a distinction between types of value. Some engagements (but very few in my experience) follow the model of providing a specific, discrete service that has a well-defined result. Many more engagements fit the concept of the consultant as advisor or as an ongoing participant in the growth of the client. The results provided in the second category are numerous and sometimes difficult to pin down. Beside the stated goals, the results can include intangible side benefits such as mentoring the client's employees. Can anyone tell me how to quantify this value other than by the amount of attention provided by the consultant?

At the root, however, Weiss is right — it must all come back down to value, or you won't succeed. So even if you bill hourly (which I almost always do), you must insure that you provide value to your client for each of those hours. Conversely, if you find that you're able to do the work so quickly that you're not getting your due, you don't have to abandon hourly billing — just raise your rate.

I admit that hourly billing is far from perfect. You really shouldn't be paid the same amount for all activities — designing a framework is far more valuable than tweaking the UI of a specific form, for instance — but nobody ever said that you always have to charge the same rate. A little flexibility here and there can go a long way towards overcoming the disconnect between hours and value. Furthermore, you and your client should work together to apply your talents where they'll do the most good. If you're converting time into real value, then you can charge handsomely for it.

Related IT Consultant resources

Get weekly consulting tips in your inbox
TechRepublic's IT Consultant newsletter, delivered each Monday, offers tips on how to attract customers, build your business, and increase your technical skills in order to get the job done. Automatically sign up today!

About Chip Camden

Chip Camden has been programming since 1978, and he's still not done. An independent consultant since 1991, Chip specializes in software development tools, languages, and migration to new technology. Besides writing for TechRepublic's IT Consultant b...

Full Bio

Chip Camden has been programming since 1978, and he's still not done. An independent consultant since 1991, Chip specializes in software development tools, languages, and migration to new technology. Besides writing for TechRepublic's IT Consultant blog, he also contributes to [Geeks Are Sexy] Technology News and his two personal blogs, Chip's Quips and Chip's Tips for Developers.