Trust Fractures: How Hourly Billing Hurts Software Projects
My previous post illustrated that billing software projects by the hour hurts productivity. In this post, I’ll take it one step further by arguing that hourly billing hurts the project itself.
Over the years, I’ve worked with a lot of software consultants. The vast majority of them follow a project lifecycle that looks more or less like this:
- A client (let’s call him Bob) needs something built (a web application, for example).
- Bob contacts a consultant (Mary) because he knows that she builds web applications.
- Bob and Mary discuss the application until she feels like she understands it fairly well.
- Bob asks Mary how much it will cost to have her build the web app.
- Mary estimates that the project will take around 100 hours, she multiplies that by her $200 hourly rate, and sends an estimate for $20k to Bob.
- Bob approves the estimate, and Mary starts working.
- Mary keeps track of her hours while she is working. For each time entry, she includes a description of what she did.
- Mary sends an invoice to Bob every Monday for the hours worked in the previous week. The invoice includes a list of the hours worked with descriptions.
- Bob reviews Mary’s hours and pays her invoice.
Steps 8 and 9 repeat until the project is done.
Two Problems of Hourly Billing Process
I want to call out two of the problems inherent to this process:
A) Administrative overhead for Mary
Mary is spending up to four hours every week tracking her hours, preparing an invoice, and processing payments. If she has two or three projects going at the same time, she could be losing more than ten hours per week to administrative duties.
B) Bob will start questioning hours
Sooner or later, Bob is going to start reviewing Mary’s hours. This typically manifests itself with questions like, "Why did it take two hours to run the data import last week, when it only took one hour the previous week?" Addressing these questions can be a big time suck for both parties, and it adds no value to the project. More importantly, it creates a trust fracture between the two parties.
This behavior usually becomes more pronounced as the actual hours approach (or exceed) the estimated hours. If the web app isn’t done and Mary is 50 hours over estimate, Bob is going to become really irritable. In this situation, he’ll probably go back over every invoice looking for inconsistencies or items that he feels shouldn’t have been charged for.
It’s a vicious cycle - more time is wasted debating about hours, mutual distrust is increased, and the project is further delayed.
How to Fix the Problems of Hourly Billing
Most consultants try solve the inherent problems of hourly billing by optimizing the process. They think the solution is to use better time-tracking software, or to integrate their CRM with their accounting system, or - my personal favorite - to bill clients hourly for time spent resolving disputes about hours.
It is true that optimization can make these problems less bad. However, optimization treats the symptoms and ignores the disease. The real way to solve the inherent problems of the hourly billing process is to stop billing software projects by the hour. When a project fee is based on the perceived value to the client rather than the hours of the consultant, the issues listed above simply evaporate.
A software project is a goal oriented, ongoing collaboration between client and consultant. A project can’t be a true success for both parties without this mutual trust. Mutual trust is the natural result of the two parties sharing in the risk (and reward) of the undertaking. Value based pricing creates a shared risk/reward environment.