Too often the software project estimates are driven by some external constraints, not much by the understanding of the effort or complexity. It's either some e

Too often the software project estimates are driven by some external constraints, not much by the understanding of the effort or complexity. It's either some existing deadline or reporting/sales cycle, some budget caps, like in grant proposals, or some promises already made by/to 'important people', or some fear of 'small people' to underdeliver etc. The estimation would all be fine if all involved people shared the same goal and responsibility. I find it practical to split the desired outcome which needs an estimate into two variants: 1) the most desired/promised/advertized and 2) an at-least viable variant. If noone can see the second variant, its viability and the effort it needs, then some details or skill force are clearly missing. If the second variant is estimatable, then the estimate could be used as a basis in dealing with the external constraints. If the devs are saying that in a given timeframe they can see a prototype done at least and you're fine with that, then no one should be damned if that pans out just to be the case. So it has to be clear from the beginning if it's at all acceptable to put such variant/prototype into production.