When you buy something, you want to know exactly what you'll get and how much it will cost. It makes sense. But this doesn't work when you're buying software development. If only it did. Writing software is a creative process and developing software systems is a complex undertaking. If you think it's possible to identify a single date, somewhere off in the future, upon which you'll receive everything you've requested and for a fixed price, then you're setting yourself up for failure and disappointment.

To say how much something will cost, you need to know in great detail exactly what needs to be built so that your estimates for the work can be accurate. But you can't define everything you want, in detail and up front, and get it exactly right so there will be no changes in the future. And no estimate is ever accurate (it wouldn't be an estimate if it was).

Let's be honest here. You're unlikely to know exactly what you want because visualisation only goes so far. You'll probably only know what you want when you actually get to play with it. It's only when you experience using a fully functional user interface, with working code beneath it, will you appreciate its usability and decide if it works for you and meets your needs.

Now, maybe you can spend an inordinate amount of time eliciting requirements, analysing them and producing a specification, and possibly get close enough to what you really want. But you're still not going to eliminate uncertainty as the project progresses because when people read your specification they'll take away their own interpretation of what you want. If it were my money I'd want to spend it on working software that realises my needs incrementally and helps maintain my competitiveness and not on documentation.

A change management process is a good way to ensure your product is built to specification. And your vendor will support this because, since you've beaten him down on price and then fixed it, he'll want to make money on the change requests. This motivates you to cram even more requirements into the specification (even if you don't really need them) just to cover all the options and hopefully minimise any changes down the road and avoid further expense. It rarely works out that way though. Change is still inevitable. A change management process just makes it more difficult to make changes, and consequently you're even less likely to get what you really want. Ironically, the cost of change requests is often responsible for forcing a project over budget. This defeats the purpose of fixing the price in the first place.

You can fix dates (although it's not always necessary to do so). And there's always a budget. But when you fix scope too quality inevitably gets compromised. That's bad. Why would you compromise the quality of a corporate asset? You should never compromise on quality. If you acknowledge that you don't know exactly what you want, wouldn't it make more sense to vary the scope?

Don't base the contract with your vendor on conformance to a detailed requirements specification. If you do, you're saying all your good ideas happen at the start of a project and you're effectively betting all your money on a hole-in-one. Insist your vendor use an iterative approach to software development so that changes can be accommodated at any time during the project. And have the contract focus on the relationship with the vendor, not on the desired results of the relationship. By that I mean base the contract on incremental delivery of functionality and specify functional goals, not specific functionality. This allows you to evolve the details of the required functionality as the project progresses. Prioritise the functionality by business value and have the vendor work on it in that order. Work continuously with your vendor. Frequently inspect what's been built, provide feedback that steers their effort towards what you really want and and pay per iteration.

The Agile Manifesto says: Value customer collaboration over contract negotiation . Enter into and nurture a collaborative partnership with your vendor, which is built around common goals, and shares the risks and rewards.

Reference: The consequences of fixed-price IT projects by Scott Ambler.