Sunday, September 13, 2009

Adapting Agile for Fixed-Price Contracts

Agile development methodology is growing quickly in today’s software world due to features like:
·         Flexibility on the part of the software vendor to implement client’s changing requirements during the development phase.
·         Continuous intermediate releases (sprints) allowing the customer to get a look ’n feel of the end-product/service early in the development cycle.
·         Customer collaboration to generate feedback on intermediate releases and use it positively.
·         Increased usability of delivered end-product/service.

But who should absorb the cost of change if the product or service is being developed under a fixed-price contract? Implementing Agile in fixed-price contracts can be a tricky if the customer demands changes to originally signed-off requirements as per the statement-of-work, but is not willing to pay for them.  It’s highly unlikely that the software vendor would bear the increased cost, and thus lose on its profit-margin. This, in-turn, almost always affects the end-product, decreasing its user-friendliness, maintainability and overall product-life.

One option that allows Agile to be used in fixed-price projects is to factor in a buffer into the total cost of development at the beginning. What this means is that the software vendor provides the customer the cost of developing the project as per the original requirements, and then adds a buffer, let’s call it Agile Cost Buffer, for any changes/additions that the customer may suggest during the development phase. The software vendor not only declares the Agile Cost Buffer in the contract with the customer, but also clarifies the amount worth of work (perhaps in person-days) that this buffer would cover. 
E.g. Customer C1 wants to develop a product with a set of original requirements;
Software Vendor S1 studies the requirements and based on its analysis comes up with a total effort estimate of P1 person-days and development cost of $T1;
S1 has determined that the Agile Cost Buffer should be b% and they can deliver w% more work of the originally estimated effort.
In the contract between C1 and S1, the original development cost should then be mentioned as $T1, and the total development cost including Agile Cost Buffer should be mentioned as $T1 + b%. This additional cost would cover all existing requirements plus any changes/additions worth w% of P1 person-days.
If the entire Agile Cost Buffer is not used, provision can be made in the contract to adjust it in the final payment to the vendor.
This will not only safeguard the margins of the software vendor, but will also protect the customer from the exorbitant rates that some vendors charge for change requests. Above all, it will fulfil the primary principles on which Agile is based, which are increased customer satisfaction and increased usability of the delivered software.