I am aware of organizational constraints and the requests for "accurate" estimates. That approach seems to be grandfathered into many organizations. We can only challenge it, one step at a time. But perhaps next time you are being asked to estimate a project, listen first to your intuition and capture that estimate. Keep the "guesstimate" at least for your own records and compare the it to the actual outcome.
Consider guess-timating a range for example low, high, and most likely and try to narrow it as much as you feel comfortable. A range is a clear signal to everybody that it is really an estimate. Try a slowed-down version of the Wide-Band-Delphi method with every participant guesstimating on the project-level— slowed-down in the sense that team members can take more time to estimate with their intuition and perhaps even sleep over it. Explain that the exercise should not be rationalized and that no participant will be asked to justify his results. No other estimation method other than the gut-feeling is required. Then you can either compare the result with yours, or derive median values.
Once your project is completed, compare the actual results with the original guesstimate and document the differences. If you can demonstrate after, say, five projects that your method is getting better and better over time, you will have an easier time backing-up future estimates. But most important in these early project stages, you will get to an estimate quickly and move on.
 Bas Kast "Wie der Bauch beim Denken hilft - Die Kraft der Intuition"
 Malcolm Gladwell "Blink - The power of thinking without thinking"
 Wikipedia (09/27/07) - http://en.wikipedia.org/wiki/Wideband_delphi
About the Author
Jochen (Joe) Krebs, http://www.jochenkrebs.com, is a active member in the agile alliance and the agile project leadership network where he spearheads the local chapter in NYC. As a certified Scrum Master and co-author of the Rational Unified Process - Reference and Certification Guide, he publishes articles with a focus on project management and requirements engineering. In his current role, Joe is responsible for successful adoption of agile development practices in a large investment bank in New York City.