I was very surprised by the last article I posted about how charging by the hour sucks.
It received some heated comments on Reddit.com and some disagreement in the article comments.
I feel it is important to clear up some of the misunderstanding and clarify some of the misplaced assumptions.
Is charging by the project too rigid?
First, it was assumed by many that what I was proposing was a rigid and set way of billing customers that didn’t leave room for changes. The argument was that if you are billing by the hour, you can easily just add more hours to it. One individual said it was much easier to deal with scope creep when billing by the hour because you can always add more time.
Scope Creep
I completely disagree; web design scope creep is and will always be a major pain no matter how you are billing. Scope creep gets out of control when the project was not well defined at the beginning, because the client is assuming one thing while you are thinking something else.
The client already thinks that the estimate you gave them includes everything they are thinking. So whether they are paying by the hour or per project, they are going to be surprised when you tell them later on that what they assumed is not what you billed them for or part of the estimate.
What I like about billing by the project is that it forces you to define the scope of every project up front. Billing by the hour does not. Too often web designers give an estimate and dive into a project blindly, and billing by the hour makes this very easy to do. So charging by the project helps you to prevent problems down the road.
Define Everything Up-Front
The second assumption was that it is impossible to know what a project will consist of up front. While I agree that you will never know every little detail to begin with, and there will always be surprises, that doesn’t mean you can’t define project boundaries before beginning the work. Even when you are billing by the hour, most clients expect an estimate or even a bid up front. Either way, you want to have as many details as possible to begin with.
Yes, it is true that clients will usually not be able to provide these details, but that is where you as the expert should come in. Don’t put the burden of defining the project scope on the customer; the burden is on you if they don’t know what exactly they want. Talk it through with the client, look at their competition with them. List out the pages that similar sites have, and ask them which ones they want. Then part of the project scope is up to X amount of pages. (X being the number of pages they said they wanted, with a little extra padding.)
Next, talk to them about dynamic elements. Do they want any kind of animation or video? What about search capability, a blog, or small elements like a tag cloud? Show them examples and get them to think about what it is they really need. This is a good opportunity to up-sell them and convince them of a bigger vision for their website.
Set Boundaries
Now, you have set boundaries of X number of pages with these specific dynamic elements. If they want to add more pages later on that is no problem, but you refer back to your agreement and inform them that this is beyond the original scope and will incur additional fees. The key is to put a number to everything you possibly can.
One big advantage that I haven’t mentioned yet is that most clients have a budget in mind. Charging by the hour makes it easy to go over budget, while strictly defining the scope of a web design project and giving them a set price makes going over the budget nearly impossible. In the end, this leaves you with a much happier client.
For the last 6 years, I have been mostly serving the tax and financial industry, and this system has worked very well. Maybe it would not work with every type of client; I just haven’t found that type yet. If you still think I am wrong, please let me know in the comments below.
Download My Web Design Quality Control Made Easy Guide
Get a jump start on being more than just a web designer by taking the quality of your websites to the next level with this easy to follow guide and checklist. No risk, no spam, just help from one web developer to another.
Well it was an great idea, Thanks for sharing it.
I think it’s great you wrote a follow-up to your last article, it really shows you’re listening to your audience, which is nice!
I also agree that scope creep is universal to all web projects, and it’s more about communicating with the client and managing their expectations. This is not so much an argument for or against fixed-price contracts, it’s just a matter of effective communication to your client. But if they want to add something to a project mid-way through, you don’t have to re-evaluate the project, create a new contract or any of that, if you’re billing by the hour. To me is just seems more seamless.
Even when billing by the hour (which I do for most of my freelance projects), I set very clear guidelines on what I will be delivering to the client, with an estimate of the time involved. While this isn’t a fixed price, it helps with a client being able to manage their budget. If things start to blow out, all I need to go is let the client know where we’re at with the billable hours, so they’re on top of everything and don’t get a shock at the end of the project.
I also think this helps show a client the value of the work I’m doing, because they get a more intimate understanding of the time required for each task. This means (in my experience) I get less of those client interactions where they have no idea of the work involved, and get frustrated when I tell them that a particular task will cost them ‘X’ dollars.
Fixed-price contracts just makes things less flexible, so as I get to know the client’s business and needs better, I can’t suggest things that are outside the original scope unless we write-up a new contract or go through a project amendment sort of process. Just seems like unnecessary paperwork for something that could be more flexible. I’ve got to make it as easy as I can for clients to pay me extra, of course! Though the hourly approach benefits them in that the project will be more tailored to their needs as I learn more about the business, rather than what I knew about the business when I wrote up the contract.
That said, I understand some clients have a strict budget in mind when they’re wanting a website, and in these cases a fixed price is best for them; I just avoid it where I can. Fixed price projects are pretty much the norm at the web design agency I work for (when I’m not doing freelance), and seems to suit them just fine, so nothing against that … just sharing my thoughts.
Thanks Daniel, great feedback!
Yes, when the project needs to change mid-stream I would just amend the original agreement or ad a new agreement, it doesn’t have to be anything fancy.
Also, don’t get me wrong, I am not saying that charging by the hour should never be done, sometimes I still prefer that, it just depends on the client and project.
Really I want to bring attention to this as a viable way of charging customers and help web designers and developers see some of it’s advantages.
Another advantage that I forgot to mention is that it makes it easy to scale back a project to meet a particular budget. If you quote someone 5 thousand and they can only afford 4, then you just cut several aspects of the project. It makes it nice cut and dry.
Interesting view. One thing I’ve been thinking of doing with one prospective customer is giving a cap and charging hourly under that. (I have a very good feel for the scope of this project.) That gives the customer a number they can use for budgeting, but if it takes me half the time, they get to see the savings. I don’t mind taking the lower money, because I’m used to budgeting my time hourly anyway – the result is that I have more time to use for another project. If I end up going a bit over, well, then it’s no different than having underestimated the time a project would taken me with a hard agreement.
This is not something I’ve had a chance to try out yet, though, so we’ll see how it works in practice. Thoughts?
I agree that asking lots of questions and defining the project scope up front is very important – because you’re right – a client wants to know what their getting for what price, no matter how you charge.
But I’ve switched to charging by the hour, and here’s why:
1. Switching to an hourly rate has allowed me to define the known parameters along with an estimated price range, and then learn the finer details as the project proceeds (and getting paid to do so). I no longer have to spend hours (unpaid) on a proposal trying to nail down every possible detail just to land the job.
2. I no longer have to wait to get paid. I used to charge half up front, then the other half to launch the site. Too often projects slow towards the end, waiting on the client. I now charge a client half the estimated cost up front, and then bill hourly against that amount. When it runs out, I’ll invoice monthly, up front to continue the work.
3. Like Daniel Ogden said above – dealing with the inevitable scope creep is much smoother. Add ons are easily handled with a ‘No problem, I’d guess X to Y hours for that.” Contract addenda are more obtrusive to the designer/client relationship than ‘a couple more hours.’
Over time I may be proven wrong. My methods seem to change slightly with every bump in the road. So far though, charging by the hour while providing a solid price range has worked well.
Being new to the industry this is a very helpful subject. The comments and ideas shared have helped me…thank you everyone.
For the last 17 years, I estimate project by range from low to high, I pad the high price with as much allowance for totally doing the job over again and the low price is when the customer has all their content organized and they are not changing things constantly as well as other factors. However, one thing I do that makes my life easier: I only take projects that I can complete in house and only those that meet certain criteria, this is so I can make my deadlines and have a life.