[agentultra]

This is a great breakdown of your process. I've seen many quite like it and have also been asked to make these kinds of estimates myself on projects for many of the same reasons: someone made a promise to another person, signed a contract, planned a release date for something they just made up, etc.

What I find frustrating about the whole situation is that no matter what process you use for making these estimates you have a roughly 30-some-odd percent chance of being right. It almost never has anything to do with the process you used when it does go well. If it did estimating software projects would be trivial, wouldn't it? Everyone would use this process and we wouldn't have 60-some-odd-percent of large enterprise software projects going over time and budget.

In reality people have used this very process, I'm sure, and have been in the 60-some-odd-precent. People have been studying this phenomenon since before I was a nerdy kid hacking on my Amiga.

Having a roadmap or a plan to get from A to B is good. It will need to be readjusted as you explore the problem space and navigate the waters so to speak. But the only real guarantee we can make as engineers is that we'll make progress in my experience. I'm only giving really rough estimates in the beginning and those estimates improve as we get closer to our end goal. I only start talking about actual release dates when we get close to being finished and are mostly polishing out the rough corners and have already done a few iterations internally.

If someone makes a promise they can't keep or have no business making -- in my books -- that's their mistake and they've made it a problem for everyone else.

[AnimalMuppet]

Yeah. I'm a big fan of making the person who made the promise fix the mess. You dreamed up something and promised it to the customer? You get to go back to the customer and eat the crow. Maybe that will teach you not to do it next time.

Anything else is just enabling (or even rewarding) bad behavior. If you do, expect to get more of it.

Note well: I have never been a manager, especially not an upper-level manager over both sales and engineering. I don't know how well my recommendation will fly in the real world. (Hey, I guess that makes me the guy who just sold something without knowing if it can work...)

[RandomLensman]

Estimate is but one part. The other is planning for obstacles and changes, i.e. have escalation paths and responsibilities in place:

Clear procedures to remove impediments, decision makers in the loop to ok scope/feature changes, resourcing agreed upfront, user engagement for testing locked-down, senior leadership aligned and kept informed regularly. Someone running the administrative side of the project, keeping people on target, etc. (could be a double hat, of course).

Sounds all rather "menial", but high degrees of organization really make a difference in delivery on larger projects.