There is an interesting approach from the German IT service provider Adesso AG and the Ruhr Institute for Software Technology on how to balance project risks between service providers and their customers within a new contracting model, which is a combination of fixed price and Time & Material approaches. I want to give a brief overview of the work they published.

The problem with contracts within (agile) software development
Projects typically overrun time and budget constraints, missing requirements and quality expectations. These problems mostly arise from insufficient communication between business and technology experts or users and developers. Additionally, customers initially have a rather coarse grained idea of the system they need, but controversially they have to negotiate a fixed price contract or a budget ceiling to control the costs for project, because the purchasing department forces them to do that. This cost estimation can be done best by a service provider based on a complete specification of the system to be build. However, such a complete specification is neither economical (it requires considerable effort on both sides) nor is it helpful (nobody in the world can express all requirements in sufficiently complete and consistent detail up front).
In practice, service providers trying to make a best guess of the price and to balance the expected effort with the price the customer is willing to pay. Additionally, a service provider is sometimes forced to under-bid competing providers, since some customers have only one criterion: the price. This usually results in a too low amount, and the service providers will struggle for sure with the low bid. Many of them became therefore experts in the then following inevitable game of overly expensive change requests (and gone is all the cost control for the customer…). Neither constellation is helpful for a lasting customer relationship.

Fixed price or time & material aren’t the solution, too!
Agile software development replaces voluminous specifications by short iteration and (end-user-) feedback cycles, which makes it virtually impossible to set a fixed price upfront. The scope of the project generally emerges gradually during the project, so the actual effort is not foreseeable. In case of an agile software projects, a fixed-price contract exposes the service provider to the complete project risk. A pure time and material (T&M) contract is on the other side a high risk for the customer, since the service provider can now blow up development effort and neglect quality on the customer’s expense. Since fixed-price and T&M are not satisfactory for both parties, it is desirable to find a contracting model that has a built-in risk limitation mechanism for the service provider and a built-in cost limitation mechanism for the customer.

A fair pricing model?
The adVANTAGE model combines elements of fixed-price and T&M contracting models. It strives to provide some idea of the overall project scope (in terms of requirements, time and budget) as you know it from fixed-price projects. Also, the customer pays the complete effort to the service provider as you know it from T&M projects. The commercial principles behind this are risk distribution and efficiency incentives for both parties for the whole project duration. In the following sections we’ll see how these commercial aspects tie in with the sprints and deliverables of an agile process model.

Step 1: Collect and estimate. To get an initial overview of the project scope, we collect all the customers requirements before the first iteration, typically “must-haves” as well as nice-to-haves, business goals and business ideas with a coarse, non-technical description on the business level. The service provider then estimates the required effort for each requirement. Due to its coarse nature, these estimations have some level of uncertainty. This uncertainty is not expected higher than the uncertainty of a “normal” estimation of a fixed-price bid. Nothing really new here, but in contrast to traditional contracting models, the total of all estimations is not used to calculate a fixed price, but rather serves as a plausible point of orientation for the upcoming steps.

Step 2: Prioritize, plan and implement. Based on the estimate and the customers internal budget ceiling, the customer can now prioritize, eliminate or add requirements. In doing so, he transparently balances the importance of each requirement with his available budget and the time frame. Based on the prioritization, the customer and the service provider can now agree on the contents of the first sprint. At the beginning of a sprint, its requirements are refined together by the service provider and the customer into more detailed specifications. For the subsequent step of inspection and billing it is necessary, that all requirements are thoroughly integrated and tested (= production ready software, automated deployment).

Step 3: Inspect and pay. Now it’s getting interesting! The adVANTAGE model ties the billing very closely to the sprint. Depending on whether all user stories were satisfactory implemented or completed, we’ll have different billing scenarios:

• Underspend sprints are really good for the customer, because only the actual effort will be billed. There’s no additional gain for the service provider of being cheaper then expected.
• In overspend sprints the customer will be billed with the extra effort by a considerably reduced rate that penalizes the service provider. This is fair for both sides, because the customer is only billed for the actual effort and the service provider still gets paid for his extra effort.
• Incomplete/unaccepted requirements can be moved to the next sprint, where the required extra effort will be penalized like described above.

Step 4: Plan the next sprint or terminate. After each sprint, the customer has the option to start the next sprint, where he can re-prioritize all requirements as well as add or remove new requirements to keep the focus on the overall project goal and constraints. Change requests are treated as new requirements. The customer can also terminate the project, when he feels it has reached the required functionality and/or its budget limits. Since every sprint results in a running system, this exit strategy is risk-free for the customer.

Conclusion
Although Trifork is not currently using the adVANTAGE model, it does contain a lot of benefits for both the customer and service provider;

• The model provides what an agile project needs: a fixed scope during sprints and the ability to change the scope of the next sprints. With a fixed price approach this cannot happen without the more/less work discussion;
• No additional fixed price margin is added to the price, which potentially ends up with the customer paying too much;
• The IT service provider is given a fair incentive to deliver the promised result in a timely manner;
• Running out of budget in a fixed price project will always imply cutback on other means, mostly quality. Since the estimations are done on detailed requirements, the risk of cutting corners on quality is much less.

From a customer perspective, it makes sense to give it a try, when you ended up several times in the cheapest-wins-but-they-have-bled-you-dry-with-change-request loop and ask service providers to go for the adVANTAGE model. This kind of project cost control seems to be better than the traditional one. What do you think?