When a business wants a custom software deliverable, there's a basic decision to be made about how this software is sourced, or procured. Like a buy-vs.-lease decision when you go to the car dealership, the business has to decide first if they can and/or will develop the software with internal resources, and if not, they need to solicit bids and pick a vendor to do the work.
For many years, the only way to obtain software development expertise from outside your company was to contract that expertise on an hourly basis. In fact, this is still the bedrock upon which most "consulting" firms are based. It's not sexy, but it pays the bills. For customers, however, this can be an unrewarding experience because they still must provide most of the infrastructure of a software development shop, and in many cases, this just isn't feasible.
In order for consulting companies to meet this need, these firms began to sell "solutions." In a broad sense, this is simply an arrangement to bundle all the work for a deliverable and charge per software deliverable, rather than per hour.
Solutions, then, are sold either on a fixed-bid basis, or on a time-and-materials (T&M) basis. I'll forgo a full examination of either of these models here, because most people are familiar with these models. Suffice it to say that "fixed-bid" remains by far the sexier option, because it promises predictable budget-to-expense performance for the business, and predictable forecast-to-revenue performance for the solution provider - both of which make management look great.
In actual practice, however, fixed-bid projects don't always turn out to be quite that tidy. Requirements change, bids are supplemented by change controls, staff turns over, and any number of other minor catastrophes combine to make one or more parties in these transactions wish they'd done things very differently.
Over the last five years, then, any number of IT services companies have swung from 100% staff-aug work to take on a fair number of fixed-bid projects, and many have now started to swing back the other direction because of the pain they've experienced. Fixed-bid is still a sexy sell, but it's now recognized as a tough delivery.
Customers have also had a chance to experience this pain. When you fix the price of an IT deliverable, you're going to experience pain with each and every change you need to make. In many cases, this will even include changes that you don't perceive to be changes at all, merely because requirements weren't spelled out clearly enough in the beginning. Customers who aren't really good at analysis and requirements definition will very likely feel like they've be run through the wringer.
The bottom line for fixed-bid projects: Customers who understand what they want, and can specify this in writing, will do fine in a fixed-bid scenario. These customers are more likely to get the software they want, and their vendors are more likely to deliver this software with a minimum of drama. If a customer doesn't understand what they want, fixed-bid probably isn't the right answer. Instead, concentrate on prototyping or agile development to derive the right answer, but understand that the delivery schedule has to be subject to change as requirements become better understood.