A lot of attention is currently being given to “Agile” contracting in IT procurement circles. In this  article we take a look at what this means in practical terms, consider some of the benefits and  pitfalls and discuss the implications of Agile IT contracting for insurers.

In traditional IT contracting, the scope of the solution, price and the parties’ remedies if things  go wrong are closely defined from the outset. In particular, readers will be familiar with the  detailed lists of milestones, performance criteria and acceptance tests contained in most sizable  IT contracts. 

By contrast, the philosophy of Agile contracting is that the parties agree on a “vision” from the  outset but the precise scope of the project is left to be developed iteratively by collaboration  between the supplier and vendor as the project progresses. Essentially traditional contracts  seek to agree the “what” and “how” of the contract from the outset whilst an Agile contract  agrees the “what” but leaves the “how” to the parties. 

By focusing on a collaborative, rather than procedural, approach the aim is to encourage a more  flexible and innovative approach to software development.  

What is wrong with the traditional model?

The principle objection to the traditional contract model is that, in particularly complex projects  or one which require a lot of development work, it is often difficult to predict, and therefore  prescribed, the precise way in which the solution will be delivered at the outset. Furthermore,  trying to prescribe the solution in too much detail may hamper the parties’ ability to alter the  scope as the project progresses and they obtain a clearer understanding of factors such as the  technical difficulties of the project and customer requirements.   

To a lawyer (or insurer) the lack of certainty entailed in the Agile model may sound like a recipe  for disaster. However, in reality the certainty that the traditional model appears to offer may  turn out to be spurious in practice. The agile potentially avoids a number of key causes of  disputes, such as:

  • Inappropriate definition of scope: the parties realise that the precise solution envisaged at  the outset turns out not to be achievable or does not in fact address customer requirements
  • Scope creep/change in specification: the customer obtains a better understanding of its  requirements mid-project, requests changes or additional work and there are disputes about  what is within scope and/or the cost of additional works
  • Missing functionality/falls short of client expectations: the solution delivered does not  meet the client’s (sometimes unarticulated) functionality or quality requirements.

Agile contracts potentially avoid these problems because they are solution focused and avoid  unhelpfully prescriptive contractual language. The Agile approach also allows both parties  to obtain a better understanding of client requirements as the project progresses and the  client accordingly obtains a better understanding of the cost and work involved in delivering  particular functionality. 

Agile software contracts

However, Agile IT contracts present a number of challenges:

  • The Agile model is reliant on a high degree of customer involvement and collaboration. It is  therefore unsuitable for customers who will not be able to invest significant amounts of  resource in the project or who lack appropriate in-house expertise. The arrangement can  also rapidly become unworkable if an initial relationship of trust and confidence breaks down
  • Agile contracts are typically agreed on a time and materials basis. Accordingly, the risk that  a project will fail and/or go over budget rests entirely with the client. Although fixed fee  contracts or time and materials contracts subject to an overall cap do exist they are not  common and create a heightened risk of disputes regarding the nature and adequacy of  the solution
  • Because Agile contracts require the customers to make a substantial investment in an IT solution before they clearly know what the finished product will look like, there remains a potential for disputes where the solution does not fit the businesses expectations (even if the in house project team have “brought in” to the solution)
  • Whilst the Agile model may work well for innovative projects between sophisticated vendors and customers, it is unsuitable for situations where there is an inequality of expertise between the parties or for standardised implementations (where the cost and work involved is relatively predictable and a high degree of development work is not required).

Due to the inherent uncertainty of the Agile mode a number of “hybrid” solutions have emerged such as:

  • Specifying the expected solution in some detail but without addressing how that is to be delivered
  • Breaking delivery of the solution into sections which must be met before the contract can proceedr
  • Providing for periodic (monthly or quarterly) inspection windows where the customer will be given an opportunity to review progress to date and determine whether it wished to proceed with the contract.

Insurance issues

Agile IT contracts create a number of challenges for the insurers of IT service providers:

  • The extent to which Agile contracts increase risk remains to be seen. However, at the underwriting stage it is clearly important to understand whether the insured enters into  Agile contracts, their contracting philosophy and the clients they would consider entering to such arrangements with. It may be advisable to require specific disclosure of Agile contracts above a material size
  • Difficulties may also arise in ascertaining whether a dispute arising from an Agile IT contract falls within policy language designed with traditional contracts in mind. For example, liabilities arising from agile contracts may not fall within the policy’s coverage for contractual liabilities and/or definition of a wrongful act
  • It is not clear that existing policies would (or should) respond to claims arising from customers choosing to walk away from an Agile IT contract or other “no fault” contractual termination scenarios. Of course this may be an area where there are additional opportunities for underwriters who are confident they can properly evaluate the scope of this “walk away” risk.