This is a tricky issue because often managers are under the same pressure.
While a poll conducted (and cited by Steve McConnell in his "Software Estimations: Demystifying the black art" book) said that managers inside companies prefer you to overestimate and come in early rather than underestimate and come in late, there are often many expectations in terms of time to market, etc that make this decision hard.
It's even worse if you're trying to win a RFP for some project. Some people will lie and say they can do something in 3 months when your estimate is 9 months. This can cause sticker shock and make you lose the business. So it becomes quite tricky. Customers often don't want to know what it will really cost.
But ultimately I've found that its best to stick to your guns and estimate.
The way we do it is we ask everyone to make their best estimate. But if anything takes longer than 5 days they have to break the issue into parts so that no issue takes longer than 5 days (this helps keep it real).
Then we grab everyone's estimates and multiply them by 2. This, almost always, results in an reachable goal. And we deliver on time (but rarely early).
Some people in the team overestimate others underestimate but because of the law of averages we can hit pretty close to the target.
We've probably lost some deals because our quote is higher than other people's and takes longer, but if the other side is so concerned with price that they would want to artificially push it down (without removing features) than we're maybe not a good match anyways.
That being said we've recently been subjected to some "emergency projects" where you save a company in distress and we've been amazed at what we can do under pressure. Like doing a 4 month project in 2 months and then even delivering that early.
It is virtually impossible to give an estimate on a big project, especially if it has parts that are unseen/unknown to most or all the members of the team. How can you estimate how long it would take you to do something you have never done before? Even with the doubling technique you mentioned, although it is a good one, but still would not work in some cases..
I might just write an article of my own to discuss this issue further..
I enjoy making things to solve problems or just for curiosity's sake. When I am not overthinking things I manage to jot a few posts down which you can find here on devto.
Definitely, the larger the project, the likelier the estimates are off. At that point, its easier to focus more on the time estimates for the individual components, and try divert whatever time "saved" to parts that need more time than budgeted. Easier said than done though!!
Yes it's problematic because some organizations want to know the overall cost before embarking on a multi-year project. That's a hard number to pin down often. It's maybe easier to set a burn rate and a 5 year horizon for those cases rather than trying to pin down the cost from a early set of features that may change in the intervening years.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
This is a tricky issue because often managers are under the same pressure.
While a poll conducted (and cited by Steve McConnell in his "Software Estimations: Demystifying the black art" book) said that managers inside companies prefer you to overestimate and come in early rather than underestimate and come in late, there are often many expectations in terms of time to market, etc that make this decision hard.
It's even worse if you're trying to win a RFP for some project. Some people will lie and say they can do something in 3 months when your estimate is 9 months. This can cause sticker shock and make you lose the business. So it becomes quite tricky. Customers often don't want to know what it will really cost.
But ultimately I've found that its best to stick to your guns and estimate.
The way we do it is we ask everyone to make their best estimate. But if anything takes longer than 5 days they have to break the issue into parts so that no issue takes longer than 5 days (this helps keep it real).
Then we grab everyone's estimates and multiply them by 2. This, almost always, results in an reachable goal. And we deliver on time (but rarely early).
Some people in the team overestimate others underestimate but because of the law of averages we can hit pretty close to the target.
We've probably lost some deals because our quote is higher than other people's and takes longer, but if the other side is so concerned with price that they would want to artificially push it down (without removing features) than we're maybe not a good match anyways.
That being said we've recently been subjected to some "emergency projects" where you save a company in distress and we've been amazed at what we can do under pressure. Like doing a 4 month project in 2 months and then even delivering that early.
But these projects weren't from scratch.
The 5 days trick seems interesting.
It is virtually impossible to give an estimate on a big project, especially if it has parts that are unseen/unknown to most or all the members of the team. How can you estimate how long it would take you to do something you have never done before? Even with the doubling technique you mentioned, although it is a good one, but still would not work in some cases..
I might just write an article of my own to discuss this issue further..
Well, it's also important to push for an MVP. If it's that ill-defined, then maybe lets focus on the first phase first and estimate the second later?
The larger the project is, the more likely your estimates will be off.
Definitely, the larger the project, the likelier the estimates are off. At that point, its easier to focus more on the time estimates for the individual components, and try divert whatever time "saved" to parts that need more time than budgeted. Easier said than done though!!
Yes it's problematic because some organizations want to know the overall cost before embarking on a multi-year project. That's a hard number to pin down often. It's maybe easier to set a burn rate and a 5 year horizon for those cases rather than trying to pin down the cost from a early set of features that may change in the intervening years.