We've battled hard with internal managers and the customer to get some sanity in estimation. It's taken 3 years. The chrun and banter for estimation all comes back to mitigation to the vendor and the customer, for both delivery risk and financial risk.
We start with a ballpark guess which we're happy to be wrong, but it gives a rough order of magnitude. If the ballpark is too high the work dies there. Then we do T&M consulting to construct a solution design, which also comes with an estimate (+/- 30%). During the T&M we happily accept variations to scope, as this is why it is T&M. After the Est is accepted we do a tech design, and then provide the quote as Fixed price.
I'd love a fully T&M engagement, but many customers consider full T&M too open to abuse by dodgy vendors. Such is life in software development.
At any point before accepting the quote the customer can pause and only pay the T&M for the design phase or ballpark phase to date. They only pay for the time we've spent, which limits their exposure and our risk. Customer likes it because they know in advance how big work will be, and we like getting paid for work and having expectations managed. If they accept the fix price quote, we work, and handle scope changes as changes; and we have a design spec and a tech spec to handle what is in or out of scope. There are very few arguments about scope these days.
Our contingency in the estimate and quote is a very small percentage of the overall Dev and Test effort, but it almost always covers the little things we might have missed, which means no stress when we need a little extra funding to cover the gap.
A key part for estimation for us is a work breakdown to at least x days or x weeks for each sub-part. If you don't know that then you're really not ready to construct an estimate and you need more thrashing out of the scope of work.
Do the MBA types like it? I'm one, so well, yes. Devs seem to like it too.