
Determine what you are going to measure against. This is a significant challenge. Find a piece of the project that everyone can agree is well defined and can be estimated to (ideally) about half of a day in development time. By establishing this baseline, it becomes easier to estimate the other work against this baseline. This will also allow the team to quickly re-estimate the work once the development starts and the team has worked through a portion of the project.
Sometimes I find the conflict stems from, as you mentioned, the battle of mindsets. As engineers we’re taught, in our formal education and from many mentors, that there’s an optimization imperative and that nearly all optimization is good. What doesn’t seem to get much focus in engineering is the simple concept of opportunity costs and the basic economics of business. Time and again this seems to pit engineering principles against business time pressures — which is strange, because ultimately we want the same thing: a stable, reliable, fast system that customers want to use and are willing to pay for.