We're all used to quoting and procuring waterfall development contracts, where a defined set of requirements is delivered for a defined price. Because the outcome is clearly set out at the start, it is relatively straightforward to estimate and validate the effort and cost. But how do you price when you don't know exactly what it is that you'll be delivering? This has become one of the biggest challenges around agile projects, and one that doesn't have a simple answer.
The flexible and changeable nature of agile means it doesn't lend itself well to fixed price, yet many procuring organisations still want the certainty of knowing what they'll get and how much they'll pay. This is closely linked to the fact that many organisations want the benefits of agile, without fully understanding what's needed to achieve them.
A prime example of where this went wrong last year is the UK government's Universal Credit programme, which attempted to use agile, but wasn't supported by the right structures, processes and contracts that would have helped make it a success.
The reality is that while agile has matured over the last decade, these processes, structures and contract types have lagged behind. Organisations that understand the requirements for successful agile projects will also understand that agile and fixed price contracts don't go well together, but until this sentiment is shared across an entire organisation, businesses bidding for agile contracts must be flexible in their pricing method. At the same time, all involved – in procurement and delivery – must understand the implications of each approach.
- We've also highlighted the best project management software
Time and materials
Time and materials (T&M) is ideally suited to agile projects, because it acknowledges the complexities of software development, in that you can't always easily foresee how much time something will take.
The drawback, from a procuring organisation's point of view, is that they, rather than the supplier, shoulder the overall risk in terms of budget, time, effort and scope. However, because agile projects deliver working software that provides real business value at the end of every iteration, the procuring organisation can halt a project at any time and still enjoy tangible benefits. And, of course, the procuring organisation has full control over which benefits these are, because it is their Product Owner who selects what is delivered in each iteration.
In this respect, agile is less risky than waterfall, where an aborted project (of which there have been numerous high-profile examples) may deliver no obvious benefit.
Having said this, the key challenge with T&M contracts remains that the procurer doesn't have a clear view of the costs being incurred by development. To overcome this, there are some alternatives to pure T&M that can be used in agile projects.
Time-boxed time and materials
Time-boxed time and materials, sometimes called 'fixed price, fixed effort', is compatible with agile insofar as it enables a project to evolve, while giving the procurer the peace of mind they require over cost control. What it doesn't necessarily provide, however, is a clear idea of the outcome that will be delivered in that fixed time period.
Fixed price
Agile projects can be delivered for a fixed price, thereby shifting the risk from the procurer onto the supplier. However, this approach, while it may appear attractive to procurement departments, will limit the benefits agile can deliver. For example, a fixed price contract is likely to specify requirements up front, which limits the scope for changes during development – one of the key factors that helps make agile a success.
Having said that, there are examples of successful compromise projects, where requirements have been specified up front, and the customer has paid a fixed price for a fixed set of requirements, alongside a pool of funds for additional features, which could be added or removed as the project evolved and business needs changed. The entire project is then delivered in a series of agile iterations.
Agile within a fixed price waterfall project
It's not unheard of to run parts of a nominally fixed price waterfall contract in an iterative, agile-esque way. This may bring certain benefits of agile development, such as test-driven development and continuous integration.
However, a fixed price/waterfall project is unlikely to offer very much scope for ongoing feedback, nor for iterative changes to the requirements along the way – the two things that are central to an agile project. Indeed, some would argue that this is not agile at all, but is merely borrowing some techniques that are used in agile.
Making a choice
Every pricing model has advantages and drawbacks, but the most important thing to consider is the outcome: which model will give the best chance of the project delivering the desired result? If organisations really want the benefits that agile can provide – notably that they ultimately get the system that genuinely addresses the underlying need, rather than the system they think they need at the start – then the best pricing model is time and materials.
If, for whatever reason, an organisation is required to deliver an agile project as part of a fixed price arrangement, this needn't be a deal-breaker, but it's important that both the provider and the procuring organisation understand and accept the limitations that a fixed price contract can place on agile.
Sue Purdin, Sales Director at IPL
