Many companies like the idea of writing a contract that fixes scope and price because they think it lowers their risk. The mirage says that their financial obligation is fixed at the price of the deal. If they don't get satisfactory software, then it won't cost them.

In my independent days, I always advised clients to avoid this mirage, it works fine in theory - but practice bites a big chunk out of its strengths.

For a start focusing only on the cost is short-changing the financial issues. You get software written because it has a business value to you - one that's greater than the cost. Otherwise why do it? If the software isn't satisfactory the financial damage isn't just limited to the what you paid for it. There is also the opportunity cost because you didn't get the business value you were expecting. The cost is also higher than people think, it's not just the money paid to contracting company, it's also the cost of people's time on the project. I remember seeing one project that went badly belly-up - the costs there were large, while the client tried to sue the contracting company for the money they'd already paid I suspect only lawyers saw any benefit.

The other thing that ruins the pretty mirage is well-known by contracting companies. A fixed scope contract only is fixed is the contractor really understands the requirements. But such knowledge is so rare that you can win by banking on its absence. Such contracting companies deliberately low-bid the fixed price, with the explicit plan of making a profit on change requests. Indeed some firms actually incentivize their sales and account managers based on how many change requests a project receives.

These are the reasons why I think fixed scope and price contracts are bad for the customer. It's why we at ThoughtWorks avoid this model as much as we can. It is possible to do a FixedPrice contract in an agile manner, but it's not wise to fix the scope.