Clients who pay by hour are committing themselves to be failures

Facebook Twitter LinkedIn Pocket Email

Last Updated:

Facebook Twitter LinkedIn Pocket Email

For me, a project is a collaborative initiative between me and my client to achieve a specific goal within a stipulated time-frame. And projects are usually billed by hour or by a fixed quote.

I am talking from a software perspective but this applies to every professional/consultant/freelancer who belongs to the service industry and I would like to highlight why sticking to hourly billing is a serious mistake for both the client as well as for the person delivering the service.

Here are the top 5 reasons why hourly billing is bad for the client and why it should be avoided at all costs irrespective of whether you are starting out to hire professionals or if you have done the hiring in the past.

1. You are losing the cream

Highly skilled and high profile freelancers/agencies stay away from clients who wants to pay by hour for a project.

A skilled developer/consultant may have spent thousand of hours practicing and fine tuning his/her skills. So he/she would be able to deliver a project in the shortest span of time when compared to a newbie.

Also when it comes to intellectual works like software development, quality trumps over hours worked!

Don’t hire guys like these 🙂

2. Hourly billing kills the mutual trust

[ctt]You cannot expect people to trust you if you don’t trust them back[/ctt]

You cannot expect people to trust you if you don’t trust them back, right ? Mutual trust is the most important ingredient for a project’s success than the coding style or the tool(s) that we use.

There is no point in awarding a project if the mutual trust is not there from the beginning and the selection was done purely based on the low hourly cost . If the client is suspicious whether the professional/consultant is bloating up the number of hours worked, then the project is doomed from the beginning.

Fixed pricing is same as that of Value based pricing  and is based on a risk/reward perspective which is in sharp contrast to the hourly billing. This is particularly important in software project(s) because software  development is an intellectual, problem solving endeavor where the ultimate outcome is more crucial than the number of hours taken to fix a problem.

3. It kills the project’s productivity

When a professional is billing by hour, the subtle mind’s natural tendency is NOT to  become more efficient nor to find any effective methods/tools to get the job done. This curtails the professional development which in turn will affect the client if there is a retainer agreement or if the professional is being hired for a long period.

4. You lose track of the final outcome

When you are paying by hours, cognitive biases automatically creep inside your mind and you will be concentrating on reducing the total cost by reducing the total number of hours worked rather than thinking about the final result. This leads to project failure, result-wise or time-wise.

5. It creates technical debt

When a client tries to squeeze the number of hours worked for a project, the consultant/freelancer will surely cut corners. This creates technical debt which causes more harm than good especially in the case of software project.

And ultimately, its the client who will suffer in the longer run since he/she is the one who is is going to pay the interest accrued for the technical debt!

In summary

As a client…

  1. Always stick to fixed project billing especially for intellectual works.
  2. You get what you pay, the cheaper guy/gal may be cheaper to hire but costlier in the longer run.
  3. Frame  conversations around goals.
  4. Remember to pay for results and not hours.

[ctt]Clients who pay by hour are committing themselves to be failures[/ctt]

You will like...

Meet the Author
author
Charles Gribble

I'm the in-house content geek of MotiveSense. When not working, I hike, cycle and weed out my garden.

Responses
David T

Nice and enlightening post about the fallacies of paying by hour.