Unfortunately, that doesn&#x27;t change the fact that customers want estimates, and the more complex the project the more they need it for budgeting and scheduling purposes.<p>In the end, you have a few options for estimating:<p>1. Estimate the most optimistic scenario, knowing you&#x27;ll end up using change requests and extensions to deliver (one of the worst options, but if you&#x27;re responding to a proposal that&#x27;s what the opposition is assuredly going to be doing);<p>2. Propose an initial phase to nail down requirements and deliver a schedule using traditional estimation tools (an easier sell if you&#x27;re an internal team, tough if you&#x27;re a vendor);<p>3. Use experience with similar projects to estimate, and then refine your assumptions with the client, using change orders to account for unexpected problems (roughly accurate to the degree of imported ambiguity, but now you have to risk going to war to get your change orders signed off on);<p>4. Use a top-down estimation model such as function points-based estimation to get in the ballpark, and then add buffer (and pray you aren&#x27;t going to either lose money or blow the top off the client&#x27;s budget levels -- or both);<p>5. Delphi the problem and get a bunch of developers and PMs to estimate the effort, then refine from there (useful for sanity checks, not useful as a real estimation process, yet one of the more common ways small shops build their numbers).<p>As you say, you can&#x27;t make risk go away, you can only try to segregate it within your estimation. In my experience, clients really need stability in proposal numbers -- they&#x27;re often willing to accept a significant embedded risk buffer in a proposal if it means they can limit unexpected costs. Conversely, you should also have a rough idea going into a project of what functionality can be cut and when so you can go&#x2F;nogo those pieces when necessary.