3 ms·

I think you’ve forgotten how this goes already. “What’s your estimate? No, that won’t work.” Don’t ever start that bullshit conversation with people. You’ve n

I think you’ve forgotten how this goes already. “What’s your estimate? No, that won’t work.” Don’t ever start that bullshit conversation with people. You’ve now signaled that they can’t trust you and now any “information” they give you will now be untrustworthy because you’re untrustworthy and turnabout is fair play. If you’re trying to control ROI and manpower, you tell us what date ranges work for the org and we figure out what we can fit in that time. And if you don’t get any nice to haves in that initial estimate you might as well pull the plug now because everyone knows that scope will have to be shed to hit the date. And that we try to pretend anything different is happening is part of that illusion of control thing GP mentioned. If we can’t build a thing by whenever then it’s time to rethink the project. A different approach, possibly involving buying part of the solution instead of building the whole thing. Or we do some other project first that will teach us how to do this project better.

superfrank 2y ago
> "What’s your estimate? No, that won’t work" That's a different problem though. The issue isn't that estimating the project is useless, it's that you work with people who don't respect the estimate and think it's a negotiation. I get that you're saying that in that situation the only winning move it to not play, but that issue you're identifying isn't actually an issue with the estimate itself. > If you’re trying to control ROI and manpower, you tell us what date ranges work for the org and we figure out what we can fit in that time I get what you're saying and it's a valid suggestion, but personally, I find it better to work the other way. Engineer estimates a best case scenario with all the bells and whistles and then it becomes a discussion with stakeholders as to what can be cut to fit the timeline. The reason I think that is better is because most of the time features that an engineer priorities may not align with what stakeholders priorities or there maybe tradeoffs a stakeholder is willing to make once they see estimates. For example A stakeholder may say, I really want it to do X, so the engineer comes back and says X will take 2 months to build and that's that, but if the stakeholder has the full project estimate in front of them, they might go, I really wanted X, but it looks like we can do A, B, and C in the same amount of time as X and those three things combined would be more impactful than X, so let's do that instead. Again, you're suggestion is totally valid and I'm sure many people do it that way, but I've gotten better results the other way.

superfrank 2y ago

> "What’s your estimate? No, that won’t work" That's a different problem though. The issue isn't that estimating the project is useless, it's that you work with people who don't respect the estimate and think it's a negotiation. I get that you're saying that in that situation the only winning move it to not play, but that issue you're identifying isn't actually an issue with the estimate itself. > If you’re trying to control ROI and manpower, you tell us what date ranges work for the org and we figure out what we can fit in that time I get what you're saying and it's a valid suggestion, but personally, I find it better to work the other way. Engineer estimates a best case scenario with all the bells and whistles and then it becomes a discussion with stakeholders as to what can be cut to fit the timeline. The reason I think that is better is because most of the time features that an engineer priorities may not align with what stakeholders priorities or there maybe tradeoffs a stakeholder is willing to make once they see estimates. For example A stakeholder may say, I really want it to do X, so the engineer comes back and says X will take 2 months to build and that's that, but if the stakeholder has the full project estimate in front of them, they might go, I really wanted X, but it looks like we can do A, B, and C in the same amount of time as X and those three things combined would be more impactful than X, so let's do that instead. Again, you're suggestion is totally valid and I'm sure many people do it that way, but I've gotten better results the other way.