Notes from the virtual office: Hourly v. Project Billing

I’ve been running my web development business for awhile now, since 2000 and billing comes up all the time. In previous incarnations as a freelancer or consultant I’ve used a variety of ways to bill, hourly, daily, but my all purpose favourite is project based. Project based billing is not for everyone and not for every situation, but I think when you can swing it, it is the most beneficial to all parties concerned.

I have a lot of problems with hourly billing. I find that this puts you immediately into an adversarial position with your client - not the best relationship if you’re trying to build something long term (which I always am). Not that this has to result in animosity, in many cases it doesn’t, but it sets the stage by giving you (the consultant) the financial incentive to work slowly and inefficiently and thus the client a reason to question what you’ve done. It requires a certain amount of trust between you and the hiring party, but if this is your first engagement, where does that trust form? Often this can result in billing disputes and questions about what you’ve been working on, etc.. If you’ve been doing the sort of work you’ve been hired to do for awhile now, you probably also have a library of techniques and code that you use - it does not take that into account either, your value is now not just your ability but to a large degree it is this library - that is, you are selling software (for example) as well as your service. Hourly billing just does not take that into account.

If you happen to have a lot of simultaneous clients hourly billing can also cut into your own productivity. Trying to keep track of how much time you spend on each client becomes an increasingly sizeable timesink as the number of clients increases. Answering emails, answering calls, and attending to myriad smaller projects is difficult enough, but then having to record the amount of time for each of these potentially short events adds to that and forgetting to record this information can cost you just as much.

Daily billing is great, but I have only done that when I’m onsite or travelling on behalf of a client. It makes sense since you’ll be focused only on that client for the whole day and the amount of time you’ll be spending is fixed. You need to, of course, make sure that you and your client understand exactly what constitutes a day. Typically, it’s easily agreed to that a day is business hours and work beyond that will be billed at half day increments. But whatever you do, make sure you agree on that first.

Now for me and my money, project billing is the way to go. I’ve been doing this long enough that, in general, I know what’s going to go on with a given project. Sure things unexpected things crop up but generally that is all factored in. Project based billing, when you have enough experience to fairly accurately predict the amount of effort that goes into a project is good for everyone. The client likes it because their costs are fixed and that’s easy to budget for. They don’t care what you do once they know the project fee because it doesn’t affect them. It’s good for you if you’ve estimated the project correctly because it saves your from record keeping and allows you to factor in cost for existing software (or other reusables). It focuses people on the value of the project instead of the cost of the project, since they won’t be worrying about how much everything is going to be in the end.

The downside to project billing is in those cases where you’ve estimated incorrectly or else the specs changed radically while you’re in the process. This can cause you to take a bath, whereas in an hourly setup it doesn’t matter since the price changes as the scope does. However, all is not lost. If the project changed because of the client it is completely reasonable to go to them with the original spec and tell them that in order to accommodate this new direction the cost of the project is going to increase. This gives them the option to keep going with the original or pay more for the new direction. Obviously, this is the case for major changes, your pricing should take in to account the inevitable minor changes and deviations from the spec. Holding someone to the letter of a spec is not a winning proposition, technology projects do and should have a reasonable amount of flex to them.

For me, I overwhelmingly prefer project based fees as I think it’s a win-win situation. I’ve talked to many hourly billers who say (privately or even surprisingly, publicly) that they’ll quote whatever hourly rate they think will get them the job. If a client wants a lower fee they’ll take it and simply charge more hours. It’s like this in many industries, I remember talking to a cab that said a woman got in wanting to go to the airport, the driver suggested a flat fee but the woman insisted on the meter. The cab shrugged and proceeded to take the regular route to the airport which was incredibly trafficked and ended up making more money than the flat rate would have been - if she had agreed to the rate he would have taken the fancy back streets he knew would get them there faster and ultimately cheaper. Hourly billing isn’t inherently wrong, but it’s things like that that can add to the distrust between client and consultant and puts the consultants interest at odds with the clients. A project based fee aligns their interest - getting things done as well and quickly as possible.

Jul 9th, 2007 · Comments RSS · · · · · Tags: business · nvo