It’s no surprise to anyone that software project managers dislike firm fixed price contracts. As many others have noted, firm fixed price contracts are typically accompanied by an expectation of fixed scope by the customer as well. In a world where estimates are notoriously uncertain to begin with, if there is no room to move on scope, the software team is “boxed in”, producing code that tends to veer dangerously away from the best value and quality.
In other words, instead of focusing on the work that produces the greatest return on investment for the customer, the team ends up focusing their efforts on functionality that either:
- Rigidly conforms with requirements that
should have been de-prioritized in importance in favor of other new, emerging requirements now that the business domain and solution space are more clear, or
- Producing large amounts of paperwork or process so that changes in scope are cleared against a fixed budget constraint.
Given this, it’s pretty clear that firm-fixed price contracts end up deforming the whole purpose of convening a group of software experts: to deliver the maximum amount of value throughout the life of the engagement.
As a project manager, I enjoy my role a lot less on firm fixed price contracts. In a sense, I become more of a “traffic cop” – merely “green-or-red” lighting requirements instead of making value decisions for the customer; or even worse, being put in near-constant negotiation situations with customers as requirements change (as they inevitably do).
In summary – help your software team help you – go time and materials – go Agile.