You’re the CIO in a company. You identify that you need some software for a particular business reason. What do you do? Well, you could try and get it written in-house (either by your own developers, or by a group of contractors working under one of your IT project managers), or you could farm it out to a software consultancy company. Your internal IT staff are swamped, so you decide to go outside. You’re worried about expenses, so you push for a fixed price contract that’s also fixed in scope and time: here’s the spec, here’s $X thousand, see you in Y months. Is this really the best strategy for getting the best software?
You’re the CEO in a software consultancy, and you use agile methodologies throughout the development process since it means that you produce better software and thereby increase your reputation. You get approached to write an application. The fixed price/fixed scope contract comes with what looks to be a comprehensive spec, a check for $X thousand, and Y months to complete it. You accept. Is this really the best deal for your company and for the customer?
My personal viewpoint these days tells me to answer no to both questions. In an agile development process, you never plan too far ahead. There’s no way you can understand a comprehensive spec well enough to be able to bid on a fixed scope/time/price contract because the spec is never comprehensive enough. Never. It’s a fool’s errand to think any one will be able to spec a system out to the last dotted i and crossed t. Requirements always change. New ones arrive, old ones get morphed into something else or get dropped. The customer’s business or environment change constantly, and so would requirements for software for that business or environment. Instead you view a spec as being a road-map showing where you want to be with the full awareness that the path may change as you proceed.
Having a fixed price contract (which generally also means fixed in scope and time as well as price) is a recipe for a disaster. The customer will get software that doesn’t suit his changing expectations. And, make no mistake, he will change his expectations: either the business will change, or interim versions of the software will trigger unforeseen but attractive possibilities that doing A instead of B will be better. Every change he wants will be a negotiation battle to decide whether it’s in the spec or is extra to the spec and therefore needs extra payment or requires that another piece of the spec be dropped. This will be even worse if the spec were ambiguous, or leaks like a sieve, or not fully developed.
Note that fixed price contracts that are not fixed in scope (or necessarily time) have more of a chance of succeeding, providing that the customer agrees to some of the tenets of agile methodologies such as regular contact with the development team and the ability to provide timely feedback.
The essential strategy for these fixed price/flexible scope contracts is different: here’s $X thousand and you have Y months, now how can we work together to ensure that the best software is written with compelling enough features by the end of that time? In essence, by working together, issues, expectations and requirement changes are dealt with earlier and it will be possible to produce better software (that is, providing more value to the business) for the time and budget.
On the other hand, if some intractable problem does occur, the customer can either change the overall scope of the project, or make the (admittedly) hard decision to cancel the project, and do it earlier.
But, and here I reiterate, fixed price/flexible scope contracts will require the customer to participate, and participate regularly and often. Timely feedback on incremental revisions means that the project as a whole can be better guided. Regular contact with the evolving software implementation gives the customer confidence that the project is on track, or, confirmation that the consultants are hopelessly bad and should be ditched.
So, all in all, I believe that fixed price contracts that are also fixed in scope and time are never the best deal for either the customer or the developers. The customer wants the software that will provide the best value for the business, but won’t get it because he’s fixed the scope. The developer wants to provide good software that is well tested, but can’t because the original spec is deficient in some way and requirements-creep has not been taken into account. Removing the requirement for fixed scope does enable customer and developer to produce the best software for a fixed price contract, but it will require greater interaction between the players.