Fixed price is an incredibly risky, particularly from a financial point of view, way to work. In
Examining BRUF I go into greater detail. On a similar vein, I recently posted
Comparing Budgeting and Estimating Techniques.
Having said this, the financial people in your organization (who should know better based on experience) will still insist on fixed price most of the time. Options that I've tried in the past:
1. Educate them on the foolishness of this. My arguments are captured in the essays above.
2. Break the project into chunks, and bid one chunk at a time (this almost always motivates a serial, non-agile approach though).
3. Suggest a low-rate T&M approach which covers my cost plus performance bonuses for delivering working softwaree.
4. Walk away. Stupid customers are bad customers.
- Scott
- Scott
<a href="http://www-306.ibm.com/software/rational/bios/ambler.html" target="_blank" rel="nofollow">Scott W. Ambler</a><br />Practice Leader Agile Development, IBM Rational<br /> <br />Now available: <a href="http://www.ambysoft.com/books/refactoringDatabases.html" target="_blank" rel="nofollow">Refactoring Databases: Evolutionary Database Design</a>