Contracting for Agile

I have spent a lot of time talking to clients about ICT projects proposed to be based on Agile principles and techniques. That usually means explaining how an Agile-based project involves a quite different type of contract from that which they may be used to.

In particular, clients often expect to retain many of the same contractual protections against project failure in an Agile world that they would have had in a more traditional project. That’s not the case.

Under an Agile methodology, a project is developed flexibly and iteratively, with lots of direct customer involvement, enabling quicker response to changing requirements.

Under most Agile approaches, customers pay for a certain level of resource commitment, not a fixed price for a complete project.

Agile suits in-house developments and projects where the customer is integrally involved in all stages. But I can think of at least three potentially sceptical stakeholders who a CIO would need to persuade that the benefits of Agile outweigh the drawbacks:

– First, a CFOwho wants to know up-front what the cost is. Under most Agile variants, you pay a given amount for a set amount of effort, but you don’t always get a guarantee of a specified outcome for a specific price – Second, a procurement officer who wants to compare offerings from bidders on a like-for-like basis before choosing the one that offers best overall value for money. Under Agile, you have a less clear specification of the full scope of outputs and no definitive price. So the selection is more weighted towards capability than value for money – Third, a General Counsel who wants an effective legal remedy if something doesn’t work. Under Agile, the customer becomes centrally involved and so apportioning blame is very hard. Agile contracts often don’t possess change control schedules and tend to have less clear contractual delivery obligations than many organisations are used to, so how do you enforce properly and recover loss if there’s a problem?

There is no reason to suggest that Agile project developments should be any less successful than traditional waterfall projects, but it’s hard to get away from the realisation that the contracts on which the projects are undertaken are very different.

Whether that suits you depends on how the CIO ranks planning for success compared to other business stakeholders’ need for certainty and protection against failure.

Alistair Maughan is a partner at Morrison & Foerster, an international law firm