billing a client for web dev work

maxmarmalade

Hi
We have recently set up a web design company (www.webintelligeence.ie) and we've being supporting an existing site for a client in England.
The client does not like open ended hours and payment e.g. requesting something to be changed, we do changes and bill him depending on amount of hours it took.
Instead, the client prefers we estimate the time it will take to make the changes, we make the changes and then he pays based on our estimate. 75% of time, we estimate pretty accurately - if we say it should take 3 hours it usually does. But a few times, we have estimated a bug will take 2 hours to find and fix but then it ends up taking 8 (in web development, this is unavoidable). So we only get paid for 2 hours work after doing 8!

Do we have any right to charge a client for 8 hours if we have given an estimate of 2? So whats the normal hours/billing policy people use?
Thanks

Raladic

If you agreed that you give them a quote for doing job x for y amount of money (on the basis that you thought y is made up of z hours), and they agree, then you have formed a contract for doing x for y.

Now if you afterwards turn out to have lost 6 hours, then you should have formed a different contract, as in pay per hour.

You can't change the contract afterwards for the loss of the other party, that would be like me going to buy a pizza for 10 euro and then the pizzaguy deciding he actually charges me 20 because it's a rainy day.


It is very normal in IT to charge for the job done, not how long it took you (e.g. if you gave the task to a new student, he might take 5 hours more than a long time professional). If you think a task may take longer, you should estimate based on this or calculate it into your overall costing (so that when in general you make a profit, you can take the occasional hit like this).

druidhill

(in web development, this is unavoidable)

Always factor it in before you quote the hours so.

If a quote for 2 hours takes 8, something is not right - either you have to improve your estimates or don't commit to anything until you get clearer requirements from client (in writing, typically an e-mail to CYA).

Also, this is something that can often balance out so I would not be too rigid - I'm sure there have been times you quoted for a number of hours and did it in less.

BrokenArrows

Maybe when looking into the quote you could keep an eye out for things which can potentially extend the time needed.

You can then go to the client and say we are quoting 2 hours but there is a potential that x,y or z could cause this to be more estimate a few hours here.

Then if you actually do find a problem with x,y,z you can contact the client and give them the new estimate.

Suppose it depends on how understanding the client is. Some people are just going to dig their heels in and say i want a solid quote which doesnt change.

The impact of this is that the average cost of their changes will need to go up so that you cover yourself for the occurrences of under quoting.

John_Mc

Bug fixing can be the most difficult to accurately estimate, especially when it was developed by someone else. I'm not surprised you've had to take a hit a few times!

You're going to have to come to some arrangement with the client as you can always inflate your estimates and to cover situations like this, and that's bad for them.

How about flagging it to them if you run into serious issues which will cause an overrun?

The Corinthian

maxmarmalade wrote: »

Instead, the client prefers we estimate the time it will take to make the changes, we make the changes and then he pays based on our estimate. 75% of time, we estimate pretty accurately - if we say it should take 3 hours it usually does. But a few times, we have estimated a bug will take 2 hours to find and fix but then it ends up taking 8 (in web development, this is unavoidable). So we only get paid for 2 hours work after doing 8!

Your client wants fixed prices, not estimates and is treating the latter as the former. I would stop this practice, if for no other reason than it is creating false expectations in your client (consider giving an estimate for a new project and they treat that as a fixed price too).

Do we have any right to charge a client for 8 hours if we have given an estimate of 2? So whats the normal hours/billing policy people use?

Yes, but realistically not when your estimates are so inaccurate.

Giving accurate estimates comes with experience, as you're better able to judge how long a piece of work will take and where Murphy's Law is likely to kick in. As a rule, estimates really should be within 15% of the actual T&M spent; other than being more professional, clients will trust you when you deliver accurate estimates and will be more willing to pay the overrun, if it's only 10 - 15%.

The simplest, short term, solution is for you to bloat your estimates, especially when something like a bug hunt, or anything that is difficult to quantify, is involved. Don't quote two hours; quote six - and if it only takes two hours, just charge them that and they'll feel that they got a good deal.

How you do your estimates needs work too, because if you're quoting two hours and it takes you eight, then you've a problem in your analysis. How much time and how do you approach analysis when formulating an estimate, for example? If it's 'off the top of your head', then you're doing it wrong.

Another approach is to get your client to prepay for T&M or sign up to an SLA. The former could be, for example, 120 hours, paid up front, valid for 12 months and with a 20% discount on the normal rate. The latter could be, for example, 15 hrs/month, paid up front, with a 35% discount, but that cannot be carried over to subsequent months.

The psychology with both is that once paid up front, the client is less worried about 'spending' the hours and it cuts down the number of times you 'remind' them that they're spending money. Additionally, with the SLA approach, you'll have months where you lose out, but other months where you'll only do five hours and win out. Business-wise, SLA's are also better for cash flow.

Ultimately, what it comes down to is formulating a model that best suits your client and their psychology and being accurate in your estimates.

maxmarmalade

Thanks everyone for such comprehensive answers.

I worked for a web dev company a few years ago in Dublin and when a client came and said they want x,y and z done, we said yes that will be €€€ per hour. Then we just tracked the time it spent to make the changes and billed the client. We never had problems with a client complaining or not paying up. Maybe this was because it was during the Celteic Tiger and clients were far looser with the purse strings.

Nowadays, its impossible to get a client to agree to this procedure. Oh well, I shall take on board a number of the suggesstions, such as flagging the client when a bug fix runs past an estimate. Also @Corinthians SLA suggestion is a nice idea too.

The Corinthian

maxmarmalade wrote: »

We never had problems with a client complaining or not paying up. Maybe this was because it was during the Celteic Tiger and clients were far looser with the purse strings.

While true to an extent, those clients who will treat all commerce as some form of horse trade will always be around. They tend to be SME's, with under ten employees, who will always seek a 'good' deal, rather than a fair one, will avoid paying for any kind of analysis, project management or even changes, will stretch 30 days credit to 120 days and who will pay invoices only so long as they'll need you in the future.

Identifying them is also an experience thing. You'll get burnt once or twice, but after than you'll learn how to spot, handle or simply avoid them - and most Web dev firms will avoid them, as long as the market is not too tight, once they're able to deal with larger companies.

The economic crisis has made them more difficult to avoid, and increased these negative tendencies in companies that might be more honest during a boom; but I assure you, they're always there.

Feathers

Another approach to soften the blow a bit would be to give the client 3 estimates: how long it will take if it turns out to be best possible scenario, average scenario & worst case scenario.

He'll still have to understand that they're estimates, but giving a range gives a better indication that there's leeway involved. If he really wants to push for a hard number of hours after that you give him the top one, just in case. Again, as others have said, it also puts some onus back on you to keep estimates realistic: if you've the best case scenario as 5 minutes, average as 2 hours and worst as 2 days, you're not taking on board all the issues involved in the fix.

When doing estimates, if you're another senior developer you can bounce ideas off, try estimating individually & then discussing any tasks that vary wildly.

maxmarmalade

Feathers wrote: »

Another approach to soften the blow a bit would be to give the client 3 estimates: how long it will take if it turns out to be best possible scenario, average scenario & worst case scenario.

He'll still have to understand that they're estimates, but giving a range gives a better indication that there's leeway involved. If he really wants to push for a hard number of hours after that you give him the top one, just in case. Again, as others have said, it also puts some onus back on you to keep estimates realistic: if you've the best case scenario as 5 minutes, average as 2 hours and worst as 2 days, you're not taking on board all the issues involved in the fix.

When doing estimates, if you're another senior developer you can bounce ideas off, try estimating individually & then discussing any tasks that vary wildly.

Good idea. We're about to do a big estimate for American client so best/medium/worst case scenarios is a good idea