Writing contracts is a key topic for the sales team getting involved in Agile projects. In the projects applying traditional methodology, companies had zeroed down on two popular models that are:
1. Fixed Price and
2. T & M (Time and Material)
While working on Fixed price model, software vendors would analyse the requirements upfront and commit to a price with the customer. Many a times, the customer fixes a price and the committed bidder gets the project.
off-mark than the actual calculated at the end. In order to mitigate these uncertain risks, companies participating in these contracts have to add a lot of unscientific buffer to accommodate them.
Projects applying Agile methodologies is supposed to have a flux associated with them. The scope could change any time and this needs to be accommodated in the contract and this is not easy. This is one of the reasons for Fixed price contracts not being popular in Agile projects. Even though there are several case studies of application on Agile projects but at the end of the day, the constraints imposed by Fixed Price model might actually destroy the agility.
Photo Courtesy: http://www.construx.com/Page.aspx?cid=1648
Time & Material(T & M) as the name implies is supposed to work well for Agile software development as it has no restriction on price or scope. The customer can keep paying as long as the value is getting delivered. However, my observation has been that this model works well in an established trustworthy environment.
Several experiments have been made in creating contracts specifically suited to Agile environments. Some of them include:
1. Phased Delivery
2. Capacity Based
3. Value Based
Phased Delivery contracts divides the entire project life cycle into multiple different phases. A goal is set for each phase and funds are released based on the delivery. The goal could be the number of user stories to be delivered in each phase providing additional quality related info.
Capacity based contracts would provide X number of people for the project and no scope related delivery constraints are signed.
I am also envisioning Value Based Delivery contract, and I am not sure if some one has experimented with this. I feel that, either a $ value or some unit could be assigned to Epics or to user stories theme. As and when this gets delivered, proportionate amount of fund could be released. Again, quality related matrices could be an additional parameter in the contract.
An Agile practitioner has put together a list of 10 styles on Agile contracts . check this link out for more details.
Summary
I strongly believe that Trust and Contract are inversely proportional to each other. That is, as long as we have less trust, we need more contracts.
Copyright protected 2011
No comments:
Post a Comment