Delivering estimates and client expectations?

Question

When a client asks for an estimate on how long it would take to develop different sections of an app, is it best to give them a total amount or what it would take for each section?

Is it better/more common to give a range of hours/days or just a single number?

Do you think most clients feel that if a programmer says it should take 50 hours that they should be billed for 50 hours?

If I say it would take 50 and it actually takes 60, do I tell them in advance that I'm going over on my estimate or just charge what was originally quoted?

Answer 1

This should be a discussion between yourself and the client.

When a client asks for an estimate on how long it would take to develop different sections of an app, is it best to give them a total amount or what it would take for each section?

Ideally, you want to break the project down in the tasks and subtasks and give an estimate for each task. Include extra time to deal with unforeseen mishaps and the like.

Do you think most clients feel that if a programmer says it should take 50 hours that they should be billed for 50 hours?

If I say it would take 50 and it actually takes 60, do I tell them in advance that I'm going over on my estimate or just charge what was originally quoted?

This is what you want to be discussing with the client as it's an agreement or understanding between both parties. E.g. if you said something like, "I'm going to finish this project in 50 hours, period", then you should only charge for 50 hours, period.

You want to avoiding tarnishing your reputation in any case, so it sounds like communicating more with your client wouldn't go awry.

Answer 2

When a client asks for an estimate ... is it best to give them a total amount or what it would take for each section?

Pieces. Always provide details in pieces. Always prioritize the pieces and always build the most important and valuable piece first.

Is it better/more common to give a range of hours/days or just a single number?

Better and more common have nothing to do with each other.

People don't retain much detail, so you can give all kinds of fancy ranges and probabilities and they're only remember one number. Which number they remember is essentially random, so it doesn't much matter what you say, they'll misinterpret it.

Since this varies, you have to know what they're going to remember. You have to know them and how the cope with uncertainty.

You're predicting the future. You cannot possibly know how long it will take.

Do you think most clients feel that if a programmer says it should take 50 hours that they should be billed for 50 hours?

That varies. Ask them.

If I say it would take 50 and it actually takes 60, do I tell them in advance that I'm going over on my estimate or just charge what was originally quoted?

If development is not a "dialog" you're doing it wrong. Since you're building in pieces, each piece is another exchange in that dialog.

Answer 3

First, however small the amount of work is , I would suggest that you brush yourself on some software estimating techniques. With this, you'll not go wrong with your estimates (most of the times) and the customer will also be relieved to know that you;re using a standard technique rather than guesstimates. Next, I don't think there are any projects which don't face an effort increase. Keep some buffer. It could be anywhere between 5-10% depending on the complexity.

Take stock every week/couple of weeks and definitely inform the customer if you foresee issues in meeting the deadline. If its because of increase in scope, you can charge the customer but if its due to some technical difficulties, you'll have to manage on your own.

You can give the final estimates Or if the customer requests, break it down to modules. Don't go to every work item but do a grouping and give the estimates.

And don't compromise on design and testing. This will ensure smooth execution of the project.