Can agile coexist with firm fixed price contracts?

People often ask or wonder if it is possible to perform firm, fixed-price contracts in an agile web development environment.  The answer is Yes, however people need to be educated about what this really means and what is really a firm, fixed-price contract.

Firm, fixed price simply means that there is an absolute budget ceiling for what can be spent. Firm, fixed-price and agile are not mutually exclusive.  They can totally coexist.  BUT, this means that for every firm or fixed project management factor, you must have a fluid or flexible project management variable.  If price if firm and fixed then scope, timeline, or quality must be fluid or flexible.

Why?

First of all, it is impossible to define every specification, predict every decision, and/or anticipate every obstacle or issue at the begining of a web development of software project.  As much as we think we have captured all of the requirements, it is guaranteed that during the life cycle of the project some new piece of information or issue will come up that was not previously discussed or discovered before and that will, in some way, impact hours, timeline, resources, costs, and/or effort.  This is a fact.

So, for the price to be firm and fixed, this means that the scope of work, timeline, and acceptance standard needs to be flexible … unless you have God-like insight and perfect knowledge of everything in advance.

Second, whatever requirements and information you think you know up front is guaranteed to change during the course of the project.

With agile, we embrace change.  Change is good.  The last thing we want to do is to deliver an obsolete product.  So, if we discover that the system needs to change to reflect evolving needs or changes in demand then change needs to happen.  But, the problem with a firm, fixed-price contract is that change costs money.  Could be that depending on when the change is discovered, you have to go back up and redo some things.  So, you might end up putting in more effort, redundant effort … which is inefficient and costly.

This is why scope or quality needs to be flexible because if you are working against a firm, fixed-price contract and scope changes which requires you to put in more hours or effort, then this will take away from the total hours or effort you had budgeted for the project.  That means less time for building functionality, quality assurance, and sweating the details.

Scope and/or acceptance standards needs to be reduced or relaxed (variable) if you are going to fix the price and change the scope during the project.