As stated in Our Philosophy, we don’t do hourly billing as of the summer of 2016. We’ve been asked questions about why we don’t bill hourly often, so I decided to write an article that explains the what, why, and how of this change.
Hourly Billing and Software Development
Hourly billing is extraordinarily common among software consultants. It’s so common that to price by any means other than a calculation of hours is nearly unheard of. When you ask consultants why they price by the hour, you’ll hear the same answer:
Everybody does it.
We don’t believe that the crowd is a good enough reason to overcome the many ethical problems associated with hourly billing, which is why we made the switch.
What are the Ethical Problems of Hourly Billing?
There are many ethical problems with hourly billing. They are:
- Discourages a Focus on Value
- Incentivises Ineffeciency
- Penalizes Long-Term Relationships
- Encourages Employment Inequality and Outsourcing
- Enables ROI-Poor Projects
Discourages a Focus on Value
The first problem with hourly billing is the lack of focus on value. When clients shop for a software consulting firm, the shopping is often done on price per hour or a calculation of price per hour. Unfortunately, this is a poor metric of appropriate fit.
Better metrics are:
- Personality match between project leads and client stakeholders
- Communication style match between both parties
- Expertise match between project needs and the development team
- Ability to complete the project on-time and in-budget
- Agreement on features and project objectives
- Proven track record with projects like yours
- Ability to create quality requirements if stakeholders cannot
None of these metrics have anything to do with price or if we bill hourly and everything to do with intangible factors. And it’s these very factors that will make or break your software project. According to one website we found, up to 68 percent of all software projects fail, mostly due to poor requirements. This is huge. Do you think spending more per hour alone is going to fix it?
When we look for clients, we ask questions that will indicate whether or not we’re both a good fit for each other. We do turn down clients we don’t feel we can help. We also turn down clients who insist on an hourly rate or who do not have a clear return on investment for their project. A clear business objective is required in order to build the right features and stay on track. Otherwise, you end up with “scope creep” and projects that change course ten times. We don’t want that, and neither do you.
In a bill-by-the-hour project, there are two competing motivations:
- The client, who wants the work done as quickly and cheaply as possible
- The consultant, who needs a certain number of hours in order to be profitable
Forgetting the conversation about value, let’s talk about the ethical dilemma this poses. For the software development consultant, there is a legitimate need to remain profitable but also to produce quality work. The client who focuses on hours puts two competing demands on the consultant: price competitively and produce quality work. Which do you think wins out in that war? When the consultant prices below market rates (or even at market rates), he or she must take on a certain amount of work in order to break even. This ever increasing work load can cause project quality to slip.
The hourly pricing driver means that the consultant has absolutely no external incentive to complete the work at a faster rate, even if he’s capable of it. Therefore, the client loses because he’s not seeing his ROI as quickly as he could and the consultant loses because he has to do a job inefficiently. (Programmers are, by nature, people who value efficiency, so this is rough) This result causes resentment on both sides. In some cases, it also causes lying and an exaggeration of hours worked.
That is an ethical dilemma we want no part of.
Penalizes Long Term Relationships
When software consultants start work on a new project, the work will be slower than when the project nears completion. This is because it takes time for the developer to become familiar with the client’s development environment, the code base, the client’s communication style, and the problem that’s being solved. So a developer may take less time to perform a task at the end than he does at the beginning.
In an hourly model, a developer is therefore paid more at the beginning and less at the end if he’s being honest with the hours worked. This is despite the fact that efficiency brings the client an ROI faster and despite the fact that the code at the end of a project is likely to require fewer bug fixes than the code at the beginning. So why should its value be worth less? It makes no sense.
We do not want to feel like we need to inflate our hours worked in order to remain in business. We value our long-term relationships and as such, we bill based on the value the project will bring and not on the hours it takes to complete it.
Encourages Employment Inequality and Outsourcing
Another problem with hourly billing is that, for the development consultant, it reduces the ability to grow. As a consulting company grows, it requires staff it didn’t need in its infancy. This includes HR staff, marketing and sales help, and facility management. These functions are not directly billable to the client in any model. So how does the traditional consultant address these issues?
Well, they do it by hiring more and more junior staff and paying them less per hour, or by hiring outsourced staff they can pay less per hour. For example, if a traditional consulting company bills at $110 per hour, they might only pay a staff member $25 an hour, thereby pocketing the rest. They do it because in an hourly pricing model there is no other way to increase profitability than by increasing the profit gained on each hour.
This model also encourages consulting companies to continue working on projects long after they should be finished, perpetually billing clients forever. For example, we’ve heard stories of project managers discouraging automation that would reduce hours. We’ve also seen the horror code that comes out of outsourcing development overseas in order to “save a buck”.
We want no part of this ethical dilemma. We pay our employees well and keep our staff lean. We increase profitability by taking on tougher and more important projects, not by churning more hours and paying staff below-market salaries. We believe that quality clients who value integrity will agree with our choice.
Enables ROI-Poor Projects
Finally, an hourly billing model enables ROI-poor projects to be contracted out. When the focus is on simply doing to do something, rather than on the value gained by completing a project, things go wonky. Projects that have no business seeing the light of day end up being worked on and, to no one’s surprise, they fail to bring a company more revenue or reduced costs.
Our value-based questioning forces you, as a prospect, to answer some tough questions about your project. Questions like:
- Why do you want to start this project?
- What business purpose will this project serve?
- Is there a market for this project?
- What is the goal return on investment in dollars?
We ask these questions because we only work with projects that will help your company. If contracting through us will bankrupt you, we don’t want to be involved. We want to see our code being used to enhance your business. This is why we tie our own financial success to our ability to build features and software that increase your bottom line.
SlideWave’s Alternative: Project Billing Based on Value, Not Time
We bill a flat-fee project rate that is tied to the value of your project. We believe that we should not be paid more than the value you’re going to see. Otherwise, you’d be in the red just by hiring us, which goes against our philosophy of doing business that improves communities. Plus, we believe getting your software done faster and better is a good thing, not something to penalize. Don’t you?
SlideWave is an agile, full stack development team that focuses on high performance and complex software projects. Think 3D simulation, "soup to nuts" enterprise automation, and web-based applications. To learn more about us, click here.