The problem is, in some places, developers know that their managers expect the estimations to be less than they really are, but the managers don't know, that developers usually give the shortest UNREALISTIC estimations, without considering ANY hurdles that might come up on the way.
So, a developer thinks it would take him 6 months to finish a project, but knowing that the manager would not like that, he says 5 months. The manager though, would like the project even sooner, so thinking they are doing their job, the manager reduces the 5 months to 4 months. BUT, in REALITY, it would take the developer at least 9 months to finish the project.
So in such case, the developer need to work for the last 5 months (month 5 to 9) under pressure from their management that they are OVER-deadline...
This happened to me, but it was WORSE than this. I estimated 6 months with 3 developers (incl. me), management reduced it to 5 months. Few days after the estimation, the other 2 developers were shifted onto other projects and I was left alone, and somehow, they thought the estimation should not change.
That was 2 years ago, and I am still working on that project!
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.
Great article, truly.
The problem is, in some places, developers know that their managers expect the estimations to be less than they really are, but the managers don't know, that developers usually give the shortest UNREALISTIC estimations, without considering ANY hurdles that might come up on the way.
So, a developer thinks it would take him 6 months to finish a project, but knowing that the manager would not like that, he says 5 months. The manager though, would like the project even sooner, so thinking they are doing their job, the manager reduces the 5 months to 4 months. BUT, in REALITY, it would take the developer at least 9 months to finish the project.
So in such case, the developer need to work for the last 5 months (month 5 to 9) under pressure from their management that they are OVER-deadline...
This happened to me, but it was WORSE than this. I estimated 6 months with 3 developers (incl. me), management reduced it to 5 months. Few days after the estimation, the other 2 developers were shifted onto other projects and I was left alone, and somehow, they thought the estimation should not change.
That was 2 years ago, and I am still working on that project!
This is exactly true.
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.