It used to be a common feedback I would get when I taught Construx's Software Estimation seminar. I would show the bright developers how to estimate their software projects several different ways and they respond with the whine, "This is all fine and good but our management won't let us."
I would question them as to why they they thought management, who had hired me to come show them how to improve their ability to estimate, would then turn around around and tell them that they can't use these techniques. This did not make sense to me at all. I know management can be a little strange at times but even they can't be that clueless.
The bright developers would explain to me that if they used the good and wise techniques presented in the seminar that they would come up with estimates that far exceeded the desires of the managers who had asked them for an estimate. In a sense, when presented with an estimate that didn't match the already made commitments made further up the chain, management has said, “Estimate THIS!” and held up a single finger, not the index.
In reality, management didn't want an estimate at all. They wanted a plan, or more like a miracle, that would allow them to keep the boastful promises made in the heat of a compensation impacting meeting. Management's ability to get promoted, secure a bonus, shine in front of their peers, or to get a raise depended on the developers' ability to spin gold out of straw. The problems is that the developers don't have a midget running around with a hard to pronounce name who can do that. Instead, all they can do is mix the straw with mud and hope to make enough bricks to be useful.
I said I "used to" get this feedback, I don't as much anymore. That is because I realized a few things I need to do when teaching estimation. The first is to make the bright developers understand that management has nothing to do with the estimate. The purpose of the estimate is to give knowledge to the development team, not to the managers. With this knowledge, the development team can make appropriate decisions, including looking for another job. The second is that it is rational for managers to want miracles. Heck, I would like to win the lottery. My odds are pretty darn low I know, especially since I don't buy lottery tickets, but I would still like to win. Wanting a nice thing is a reasonable act. However, wanting something -- even in a rational manner -- does not make it so. The third is that when the rational targets of the managers exceed the estimate calculated by the developers, there is going to be pain. Maybe not outright torture, but discomfort to be sure. The only choice we have is when will we experience the pain; early pain from staying with what is possible or late pain from not delivering on the commitments.
So I present the seminar not so much on how to calculate a date (given a feature set) or a set of features (given a date) but how to come up with enough facts and data that allow the bright developers to have a professional discussion even after an manager says, "Estimate THIS." I think this is the key challenge for estimators because our "standard" estimation technique of taking our best guess based on our personal memory of having done something sort of like this in the past has as much validity as an Elvis sighting. If we have facts and data that has at least the appearance of empirical consistency we will be in the position to respond with something like, "I understand you want that straw spun into gold. I would like that too. I must point out that this is not possible given our current development capabilities. I am happy to walk through the data with you, if you desire. Given this reality, I would like to suggest one of these three brick alternatives we could make within the constraints you have presented." It is probably best to leave out the "Your mama" we want to lead with.
In a nutshell, we estimators have to take our professionalism up a notch when faced with a rational but unachievable target. We need an analytical estimate based on historical data to back us up. Only then will we be able choose the early pain and, with practice, allow it to be only a minor irritant.