For estimation, I like to carefully calculate exactly how long I think it will take, add some padding, then double it (for all the unknown unknowns). Then add some padding, and double it (to cover overhead and communication and documentation). Then add some padding, and double it (to cover changing customer requirements, and the fact that the last 10% usually takes longer than the first 90%). Then add some padding.
Also, here are some additional cons of an hourly rate:
* The better/more efficient you get, the less you earn for a project of fixed size.
* You are incentivized to drag your feet, while your customer is incentivized to expect superhuman feats of coding in a given time.
* People don't like being charged for phone calls, meetings, email, specs, documentation, testing, "small" changes, etc.
* Some customers are inclined to nitpick itemized time sheets.
A different approach I like is to break the project up into features of manageable size. This forces you to spec it out enough so that you can break it into chunks easy enough to estimate. Then you can put a price tag on each, loosely based on effort but also based on value to the customer. And then the customer can play "feature bingo" to decide exactly what they want, instead of haggling about your rate or the project's scope.
Comments
For estimation, I like to carefully calculate exactly how long I think it will take, add some padding, then double it (for all the unknown unknowns). Then add some padding, and double it (to cover overhead and communication and documentation). Then add some padding, and double it (to cover changing customer requirements, and the fact that the last 10% usually takes longer than the first 90%). Then add some padding.
Also, here are some additional cons of an hourly rate:
* The better/more efficient you get, the less you earn for a project of fixed size.
* You are incentivized to drag your feet, while your customer is incentivized to expect superhuman feats of coding in a given time.
* People don't like being charged for phone calls, meetings, email, specs, documentation, testing, "small" changes, etc.
* Some customers are inclined to nitpick itemized time sheets.
A different approach I like is to break the project up into features of manageable size. This forces you to spec it out enough so that you can break it into chunks easy enough to estimate. Then you can put a price tag on each, loosely based on effort but also based on value to the customer. And then the customer can play "feature bingo" to decide exactly what they want, instead of haggling about your rate or the project's scope.