How do you think a client would feel if he got this bill?
Given that “fixed price fixed scope” billing is flawed, a natural next step for many small businesses is to try variable billing. This time we’ll look at some of the pros and cons of such an approach.
By “variable billing” I am referring to the practice of billing per hour (or per day) for your services. It’s a pretty common way of charging out time in the web development industry. Going back to the four variables of software development from my previous post, when billing in this way you are effectively fixing quality (or you should be!), and tying time and cost together. Therefore you are allowing scope and time/cost to vary based on the client requirements.
The advantages
On the surface, variable billing appears to be the answer to all our problems. We don’t have to worry about estimates, because the client is paying per hour, so we’ll just take as long as we need to get things done. Changes in the project are handled easily: we just drop what we’re doing and change direction, so we can give the client the features they want. Goodbye to underbid projects completed for free!
So why is the client often unhappy with this sort of arrangement? Why won’t many clients even sign up to it?
The disadvantages
Many of the advantages are to do with transferring risk away from the developer and onto the client. If the developer is freed from the risk associated with getting a feature done, then that means the client is bearing the full brunt of the uncertainty. Clients want a fixed price, so they can compare you to other suppliers. Just doing variable pricing makes the proposal process very difficult.
There’s also the lack of trust. If you’re just setting up a relationship with the client, they don’t know you from Adam: they have no idea whether whether you’re as good as your word. You might say 2 days for a feature, but if the bill comes in for 4 days, they aren’t going to be happy. It only takes one large unexpected bill to wreck a client relationship.
Another main disadvantage is more subtle. With this sort of approach, a client can sometimes micromanage the project, as they’re rightly concerned about getting value for money. Therefore it’s possible to get inundated with feedback, minor tweaks, irrelevant bug reports and requests for status updates. This burns through yet more of the developer’s time, adding to a client’s bill and dragging down project efficiency. Often clients will want a very detailed breakdown of exactly what time was spent on their project, causing more management overheard.
Conclusion: Useful in some circumstances
Variable billing works well when there’s a large amount of goodwill between client and developer. It doesn’t work so well at the beginning of a client relationship. It’s worked well for us on the two extremes of projects we take on – the very short and the very long:
* Software consultancy, where we’ve been providing short term expert advice on an ad hoc basis.
* Tiny changes, where there’s only a day or two of little tweaks to make to a site.
* Open ended long term projects, where we provide development resource over months/years.
Sometimes projects degenerate into variable billing as the trust grows, a client starts believing our estimates, and everything becomes more informal.
Interestingly, on our most successful long term collaboration using this billing method we have a regular monthly budget which we can’t exceed, but we use that up in a variable ‘per hour’ manner. This is strikingly similar to our current chosen method of billing, which I’ll discuss in the next and final post in this series.
Tune in next time for an outline of our current method (you may want to subscribe for the latest updates). If you’re in a hurry for an “answer”, you could always peek at our pricing pages if you want to know how we bill :) Thanks to Kent Beck’s excellent essay on Optional Scope Contracts (PDF) for many of the ideas in this series, and the feedback I’ve received from various people.
