[This post was inspired by a recent blog post on Diana Schneidman's blog Stand Up 8 Times titled Freelance Pricing: A Case Study. She presents a case for hourly charging and asked for comments. I posted my own comments, and this blog post is an extension of my thoughts on the matter.]
I've been doing freelance software development work (mostly database Web applications) since about 1995. When I started out, I charged by the hour, mainly because I had one large client who provided most of the projects and they varied dramatically in size. The client trusted me to charge for actual hours worked, and I got paid for every hour I put in on the projects. It was a nice arrangement.
When things slowed down for my primary client, I naturally had to look for additional clients with different projects. The new clients often had only a single project they wanted to get done, and they were extremely cost conscious. With these new clients I still charged by the hour, but I had to create reasonably accurate estimates so they could decide whether or not they could afford the project. In some cases, they wanted an estimate because they planned to shop around, but that was actually rare. Most of the clients came to me on referral, so I enjoyed a level of trust from the beginning of the relationship.
I eventually ran into a big problem with the hourly model. A project came along that kept growing in scope as I worked on it. Because I was working hourly, I just incorporated the additional features as the customer requested them. When we were done, the project cost two or three times what I originally estimated, and the customer was upset by the huge invoice he got the next month. Of course, the reason the project cost almost three times the estimate was because the customer had nearly tripled the scope.
That was when I realized one of the big failings with the hourly model and estimating: It is much more difficult to manage expectations. Customers think they can request additional features, and you can just "squeeze them in" at no additional cost. Even now when I do hourly "enhancement work" on a project, I warn customers: "if it takes me time, it costs you money."
Another thing about the hourly model is that it tended to make me anxious for various reasons. I would stress about things that took longer than anticipated because I didn't want to overrun my estimate.
One reason for anxiety is that most responsible consultants don't charge a customer for "learning on the job." In other words, the customer hires you for your skills in your chosen field, and you are expected to have a certain level of competency in that field. If you claim to be an ASP.NET expert, then you should not be charging the customer for the time you spend learning how to program in ASP.NET. Sure, every project has certain things you may not have done before and have to research, but core competency should be developed on your own dime. The problem is that drawing the line between core competency and project-specific knowledge can be mighty fine.
Another reason for anxiety comes into play when you are doing maintenance work on an ongoing project. As you add enhancements, you often find a certain amount of re-factoring of previously done work is desirable or even necessary. If the change is necessary, there's no question about whether or not the work is billable. However, if the change just makes your job easier now or in the future, but the customer does not receive additional value from it (other than the possibility of future reduced fees), is it fair to charge the customer for that work? I often found myself thinking "I really want to change this, but the customer isn't going to see the value of paying for it." As performance coach Dick Haab once told me, "one cause of stress is the gap between where you are and where you want to be." I usually solved the conundrum by just doing the work on my own time, but that didn't feel right either.
The last reason I'll mention for anxiety is when the customer requests changes to the scope of the project. After my prior experiences with this situation, I know that the customer isn't going to recognize the request as being "out of scope" and therefore "more expensive." For some reason, they expect the changes to be worked in for no additional cost, and with no change to the schedule. It's crazy, but it's true.
The last straw for me and hourly charging was when one customer asked for a "not to exceed" contract. If you do consulting, NEVER fall for that arrangement. What it means is that you get to charge for the hours you work, but only up to a pre-arranged maximum. Beyond that point, you are still responsible for finishing the project, but you are working for free. The problem with "not to exceed" is that YOU, the consultant, accept ALL of the risk on the project. If your estimate is higher than the actual hours, the customer gets the benefit because they only pay for the hours you worked. If the estimate is low, the customer still gets the benefit because they only pay for the amount of the estimate.
I realized that doing projects on a fixed bid was the best way me to go for me. The customer can determine whether or not the project fits their budget, and I don't have to worry about any training or re-factoring decisions I make while completing the project. If changes are requested, I let the customer decide if we will bill them separately by the hour, or if they want to put them off to the next release (which gets a new quote). Either way, the quoted project/release is not affected, and I can still remain flexible to changes. Also, we both share the risk. If the project takes less time than I estimated, the customer still pays the quote. If the project takes more time than I estimated, I'm basically just accepting a lower hourly rate for the project.
Quoting by the project versus the hour requires a few key behaviors on your part:
- You have to be good at estimating, or at least realistic about your failings when estimating. If you routinely quote too low, realize that you need to pad your quotes accordingly.
- You have to very clearly define the scope of the project. You don't want any "I thought we agreed to X" conversations later. If it isn't in the quote, it isn't in scope.
- When additional features are requested, clearly identify them as "enhancements" and negotiate how they will be handled (incorporated for free, completed at an hourly rate, or put off until the next release).
Another thing responsible consultants do is offer to fix bugs at no charge. If you deliver a project and it fails to perform the way it was designed, you don't charge the customer to fix it. Your testing should have discovered the problem, and fixing it at no charge is just a courtesy to make up for the inconvenience to the customer. Clients love the free bug fix policy, but you'll find they try to stretch the definition of "bug" in order to get you to add enhancements for free.
Here's an example of what I mean. After the release of one project, the customer realized that the number of users he was going to add to the system made the existing user maintenance pages unwieldy. The customer tried to pitch that problem as a bug. But the fact is that the user pages still worked exactly as they were designed to work, and as they had been working for years. If we had realized earlier that the increased number of users was going to become a problem, we would probably have incorporated changes to the user pages into the quote for the current release. By requesting the change after the release was done "because we should have anticipated that problem" is basically trying to sneak the enhancement in without getting charged for it. That enhancement was not in the quote, so it was not in scope for the release.
You may be thinking that the situation I just described is a gray area. If so, here's another way to look at it. Customers request enhancements all the time that end up on the wish list because the customer doesn't want to pay (or wait) for them right now, even when the changes are important and must be incorporated eventually. You wouldn't give those enhancements away for free just because the customer comes to you later and says "I meant for that to be in this release."
Like I said before, if it isn't in the quote, it isn't in scope.
Quoting by the project isn't for everyone, and I don't think it is a one-size-fits-all solution. The choice of charging by the hour or the project depends a lot upon you, the customer you are dealing with, and the size of the project. I still do both.
Posts
0 comments:
Post a Comment