Companies need to move away from using fixed price contracts where their expectation is, for a fixed price, they can have everything they ask for delivered on a specified day in the future. How did it get this way?

Managing software development using a defined process is an illusion. Developing software is inherently unpredictable. First, the term 'stable requirements' is an oxymoron. Requirements will change. Recognise it and embrace the inevitability of change. If you spend six months working on requirements in order to stabilise them, you're wasting your time. By the time you finish the requirements the business priorities will have changed, or the competitive landscape will have moved, or the targetted users now want something else. Second, estimating how long it will take to write a piece of software is difficult because it's a creative activity and not an exact science. It also depends on people who, contrary to popular belief in the industry, are not automatons or plug-compatible-programming-units .

To manage software development effectively you need to use an empirical process that frequently inspects and adapts, rather than a defined process that attempts to predict. There's always a budget so fix the price of the project. Fix the time too, but agree that scope can be varied to protect the release dates. But this approach doesn't provide a guarantee that all the required functionality will be delivered. Correct! But this is true for a defined process too. If you thought otherwise you were living an illusion. Essentially, an empirical approach uses a feature buffer and prioritising the work in order of business value guarantees that some business value will be delivered by the release date, rather than see the entire release slip.

The project should be initiated against a high-level roadmap that identifies very approximate content that could be delivered by agreed release dates, with more specific content for each iteration being planned just-in-time. At the close of each iteration, a review is conducted for the customer to accept or reject the functionality delivered by the iteration. At this point, the customer should consciously decide whether to continue with the project or not. Too often the decision to terminate the project is ignored because people are afraid and do not want to acknowledge the smell of the dead fish of failure .

Too many traditional fixed price (fixed time, fixed scope) contracts fail to deliver and their failure isn't evident until the release slips. If a project is destined to fail you need to smell and acknowledge the distinctive odour from the dead fish of failure as soon possible. The best way to sniff out the smell is to make everything visible, inspect and adapt frequently, and use iterative and incremental development to deliver working software rapidly and regularly.