4 ms·

The hardest part of this is communicating it to a client. “What do you mean it will probably take 5 weeks, but could take between 2 and 10 weeks? That’s a prett

The hardest part of this is communicating it to a client. “What do you mean it will probably take 5 weeks, but could take between 2 and 10 weeks? That’s a pretty big span. The other programmer I asked promised it would be done in 5, period. Are you sure you know what you’re doing?”

myth2018 6y ago
I've made a comment some minutes ago about the difference between estimates and plans. Making the client aware of the difference may be useful. However, it's also a fact that most clients ask for being deceived. I've seen that scene over and over: Company A presents a fairly detailed 3-months plan while Company B salesperson says that the project is easy and they will deliver it in 1 month. Company B wins the project most of the time, only to (possibly) deliver it in 6 months or so. Some clients even train their employees to avoid such traps, making them informed of estimation techniques and encouraging them to use plain good sense, but those are exceptions. Software projects would be way less painful if clients, and not only software development companies, worried more about achieving higher levels of maturity.
ncallaway 6y ago
We used to try and present estimates as a range ("between 5 and 10 weeks"), but we've settled for trying to provide a single number rather than a full span. For our time and materials estimates, we try to provide an ~85% confidence estimate, while for fixed bid projects we try to aim for a ~95% confidence estimate (and there's usually a pretty big gap between those two numbers, for the reasons pointed out in the article). So, in this scenario, we'd probably say to the client that it'll be done in about 8 weeks (making clear that's an estimate, and not a promise). One number, rather than a range, seems a lot easier to explain to a client and if you end up low (say it takes 3 weeks), then you have a pleasantly surprised client.

myth2018 6y ago

I've made a comment some minutes ago about the difference between estimates and plans. Making the client aware of the difference may be useful. However, it's also a fact that most clients ask for being deceived. I've seen that scene over and over: Company A presents a fairly detailed 3-months plan while Company B salesperson says that the project is easy and they will deliver it in 1 month. Company B wins the project most of the time, only to (possibly) deliver it in 6 months or so. Some clients even train their employees to avoid such traps, making them informed of estimation techniques and encouraging them to use plain good sense, but those are exceptions. Software projects would be way less painful if clients, and not only software development companies, worried more about achieving higher levels of maturity.

ncallaway 6y ago

We used to try and present estimates as a range ("between 5 and 10 weeks"), but we've settled for trying to provide a single number rather than a full span. For our time and materials estimates, we try to provide an ~85% confidence estimate, while for fixed bid projects we try to aim for a ~95% confidence estimate (and there's usually a pretty big gap between those two numbers, for the reasons pointed out in the article). So, in this scenario, we'd probably say to the client that it'll be done in about 8 weeks (making clear that's an estimate, and not a promise). One number, rather than a range, seems a lot easier to explain to a client and if you end up low (say it takes 3 weeks), then you have a pleasantly surprised client.