The Moral Dilemma of Hourly Billing
by Jonathan Stark
In my previous post on value billing, I explained how I first came to realize that billing for software projects by the hour was fundamentally flawed. In this post, I reveal a paradox which I hope will help illustrate my point.
What Would You Do?
Imagine that you’ve estimated a 40 hour job at $200/hr for a total of $8000. The client happily approves it and you rejoice.
After some initial research, you discover that there is a tool available for $1000 that will allow you to deliver the project in 5 hours, rather than the 40 hours that you’ve estimated. What do you do?
A) You buy the tool for $1000, you deliver the work in 5 hours, and bill the client for 5 hours. Result: You work 5 hours, pocket $0, own the tool, and the client loves you.
B) Have the client buy the tool for $1000, you deliver the work in 5 hours, and bill the client for 5 hours. Result: You work 5 hours, pocket $1000, the client owns the tool, and the client loves you.
C) You buy the tool for $1000, you finish the work in 5 hours but wait to deliver it at 30 hours, and bill the client $6000. Result: You work 5 hours, pocket $5000, own the tool, and the client is very happy that you finished faster and cheaper than promised.
D) You don’t buy the tool, you deliver the work in 40 hours, and bill the client $8000. Result: You work 40 hours, pocket $8000, don’t own the tool, and the client is satisfied.
I think that all of these options suck, and I don’t advocate any of them. What’s interesting to me is the moral dilemma between C and D. C is clearly dishonest, but it’s undeniably better than D for both you and the client. The client saves $2k, receives their work 10 hours earlier than expected, and you make $1000 per hour!
I can imagine a variety of other options, and I’m sure you can, too. Unfortunately, none of them would address the underlying issue: that billing by the hour for software projects makes no sense. Software projects should be billed based on the client’s perceived value of the outcome. Period. How many hours it takes you to deliver it is irrelevant; in fact, the fewer the better!
Hourly Billing Punishes Increased Productivity
When I first switched to value billing for software projects, I was struck by my sudden inclination to research and purchase tools. These days, I don’t think twice about dropping $500-$1000 for something that will make my work go faster or better.
Herein lies an insidious truth about hourly billing: If you are billing by the hour, you have a subconscious incentive to NOT become more efficient. Because of this, your skills will stagnate and your clients will suffer.
Comments
Excellent series – I am enjoying and identifying with this.
12 years ago, we wrote an app for a bus company to handle charter work. It cost them about $5000 (on an hourly billing basis). Last year, the CEO approached us again and said that the system was still in use, never failed, and was a crucial lynchpin in their $5million/year turnover business.
What does that work out at? Less than $500 a year?
He asked us for some modifications to be done to the software. Needless to say, we approached it from a value based perspective, and I think everyone ended up happy out of the deal.
Hourly billing is now out the window as far as I am concerned.
@devan Thanks for your comment! I wonder – did you get any resistance from the client when you changed to a value based approach?
@jonathan Actually we didn’t get any pushback at all. I think after 12 years of the software working flawlessly, we had a pretty high trust value with them.
Good business people also seem to understand the concept of ROI. We pitched our proposal to them using the “You will pay for the mods inside of 3 months by saving employee Joe 4 hours of work per week” style.
@devan Thanks for the feedback. Hopefully it will spurs others into giving it a try themselves.
Honesty is one of my character strengths, and my reputation for honesty has landed me more work than even my reputation for good work has – and yet I don’t see option C as “clearly dishonest”.
Maybe it’s because my estimates are calculated by how long the project will take using the tools I have at my disposal at the time.
Time is simply a way I come up with a reasonable number for the client. Once the estimate has been agreed upon, the price is fixed. Time and cost are no longer factors. They are off the table. It now becomes about me providing excellent results as I promised.
What if the project consumes more hours than I previously estimated? I eat the difference. I don’t go back to the client and ask for more money. We already agreed on a price.
And why should my client be concerned or aware of every hour, plus or minus, I spend on his behalf? I’ve already worked in a factory where I had to use a time card. I’m done with that. Never again.
Like I stated before, it’s not really about the time. It’s about doing work I love, getting the job done right, and doing so at the agreed price.
Now, it goes the other way as well. If I discover a tool that helps me get work done faster than previously estimated, and with the same quality result, great! Both the client and I win.
Finally (this is turning out to be an epic rant, sorry about that), I don’t involve clients with my development/working processes. My clients would much rather focus on their business anyway. They only want to see an excellent finished product, at the agreed price, and within the agreed time frame.
It all boils down to results in the end, doesn’t it?
You must be logged in to post a comment.