[setr]

My rule of thumb is that if you give me an honest estimate, then it’s my job to make it work. Negotiate scope, change implementation, move resources, increase cost, whatever. But I need estimates that at least reasonably correspond to reality in order to make my case successfully.

The biggest issue I have is developers making business decisions without realizing it or without saying it — saying no to something because it would take too long or be too expensive, without first asking how much time/cost can be consumed

The same occurs with estimating — they’ll give a risky estimate instead of a safe one, because they’ll unilaterally decide the stable one is unacceptable; and not bother mentioning this with their estimate, or knowing what the rest of the timelines look like.

The other half of the problem is that people tend to only want to give one number (and people typically ask for a single number), but what you really want for project planning is the median +- margin of error timelines. The 1x,2x,3x rule is just a hack to work around that unwillingness.

[mason55]

Yeah, from the product management side this is the way to approach it. Make priorities clear and make it clear whether the important part is the date or some set of features.

If the date is what's important then start the conversation with "here's the date, can we get this all done by then? If not then what can we get done? If we can't do it all, here's the stuff that I think is important." And make sure to allow some time for people to think about things and give an honest estimate.

If the features are what's important then don't even put a real estimate on it because then that just turns into features + date which never works well. SWAG it by weeks or months and refine as you get further along.

It's basically a law that we always want t do more than we have time for, so it's important for the decision maker to be clear about which parts really matter.

[chii]

> the decision maker to be clear about which parts really matter

which is good and all, but the reason software projects have such a high failure rate is _because_ these decision makers aren't clear about which part really matter! And not to blame them solely, because it's a hard problem to know.

[jbverschoor]

100% agree. They aren’t clear because they don’t know. They might not be able to think in abstracts, or simply don’t have their priorities straight.

The same would happen with ANY other type of project.. marketing, home renovation, building an aircraft, or even baking a cake

[setr]

> And make sure to allow some time for people to think about things and give an honest estimate.

I like to tell people to give an estimate for when they can provide an estimate.. and estimate for that, if needed :)

Eventually someone knows something

[lazyasciiart]

The biggest issue I've seen is developers making business decisions knowingly, but without saying it to the business people. I was on a team that literally sat around saying "if we tell them it will take 18 months to do this then they'll just cancel it, but we want to do it, so let's say 6 months and then we'll just be late but they never cancel stuff in progress". I quit that team for many reasons, but they got started under that 6 month estimate and four years later the project is still going.

[b0bby]

My favorite PM to work with never wanted any estimates to be optimistic. Things had to be within reason, but he preferred very conservative to very lean. Once the numbers for a given proposal had been collected, it was his job (and anybody else from the team who went into the pricing/costing delegation) to go back and forth with segment management:

"We can't win with these numbers. Are you trying to lose this business for us?"

"Nope. I'm letting you know what we believe is necessary to finish the work on schedule. We can be more aggressive in some areas and, if so, we'll add items to our risk register."

"You need to hit XYZ target or we're not even going to send a bid."

"Roger."

<Team decides whether it is possible>

The internal cost debate usually ends up with a good budget and the PM/team have an "I told you so" card in their back pocket in case the team can't meet the delegated EBIT. It isn't perfect but this friction (PM sticking up for his team and management pushing for competitive numbers) is better than nothing. I imagine it is similar at most engineering shops.

edit: The fun part is that everybody knows its a game. PM wants as much cushion as possible, management wants great profit at a low price, and the team wants to keep getting work so as to stay employed. Sometimes the costing/pricing stuff goes a little over the top and the infamous "death spiral" gets tossed out by management. Always a hoot.