In the last article we introduced a range of legal barriers that operate to prevent or dissuade parties contracting for the use of Agile. One of the biggest concerns for customers is the apparent lack of control over costs - unfortunately, lawyers tend to "sell" time and materials as the only suitable pricing model for Agile contracts. Even in a mature Agile environment, commercial models can and should be more sophisticated than this. This article looks at alternative models that provide price certainty whilst maintaining a degree of flexibility, something which is particularly useful for customers when they first adopt the use of Agile.

Fixed price

The opposite end of the spectrum is for the parties to agree a fixed price, preferred by customers' because of cost certainty. Time, cost and scope are the elements that form one of the iron triangles in Agile; fixing one or more nodal points reduces flexibility and undermines the core principles, though it is frequently quality, trapped between the elements, that suffers most. Clearly, therefore, it will be desirable for a project to use a commercial model that avoids these extremes.

A preliminary step is to understand the basis on which the parties assess value. Customers are interested in business value generated by the project and the extent to which it will generate business efficiencies, improve a process or create a market advantage. Suppliers will consider the cost of development, including fixed and variable overheads, and look to recover those costs and make a margin on top.

When does pricing start?

The parties will also need to consider the point at which price is being negotiated. Typically this will be done before any work has commenced and the parties are still negotiating the contract terms. Unfortunately, this is also the period of greatest uncertainty and there is inevitable concern about the accuracy of any estimates. Traditionally, suppliers deal with this by adding a margin of error to deal with the risk and may also include a number of assumptions which, if not met, allows the supplier to revisit costs. It should be clear that this is inefficient for both parties.

Agile projects encourage flexibility, including the ability for customers to bring the project to an early close once its requirements have been satisfied (also known as the "definition of done", which is the topic for another article). It must be correct that the customer should not be obliged to pay for unnecessary services, but the supplier’s risk is the failure to recover its unamortised costs when the contract ends.

Unit-based pricing v target costing

A solution to the value issue is the use a system of unit-based pricing, for example, ascribing a fixed price for each story, function or feature point, or a price per iteration. The essence of this approach is that there is a lower risk of estimating the value of each unit, but the customer risk remains in the number of units required to deliver the desired outcome. The customers' risk is overcome to some extent by the ability to terminate easily and the frequency of delivery.


Alternatively, the parties might prefer to agree a model that allows the supplier to set a target cost for the project. Such models allow flexibility by recognising that the final price is variable depending on the unknown complexities of the project. The model can be developed further by including a mechanism to share the risk that costs may exceed the target or in the reward where the final costs are lower. Mechanisms that apportion the value of reduced or increased costs can also be used to provide an incentive for the supplier to exceed delivery expectations through its impact on the supplier's profitability margin.

Where the project approach and complexity permit it is possible for the parties to agree the use of a number of pricing tools to create a sophisticated commercial model that addresses the issues already described. Such "mixed economy" approaches look to identify the most suitable charging method for each phase of the project, and recognises the commercial imperatives of both parties when entering into the arrangement. They may also take into account the consequences of early termination for the supplier, including the supplier’s need to recover a reasonable proportion of its fixed cost before the customer is allowed to terminate at the end of an iteration.

Agile is inherently collaborative in its approach, with risk, responsibility and effort shared between the parties. There is an anticipation that the parties will trust each other, but it is on the subject of price where this is most difficult to establish, particularly for customers that are taking their first tentative steps into Agile contracting. Intelligent use of commercial models can help develop that trust and encourage the repeated use of Agile.

Stewart James, partner at Ashfords LLP. Image credit: Ashfords