Agile methodology is now extensively used in Information and Communication Technology (ICT) projects involving a design or development component.

It comprises terminology and processes that are different from those used in a traditional contract, which are based on pre-defined specifications, acceptance testing and milestones.

Agile methodology is used to create a working relationship between customer and vendor to more deeply define or design a solution, and then to develop the solution in components (referred to as iterations or user stories). The traditional approach is familiar territory for lawyers. However, we need to embrace new approaches to ICT contracting.

Agile methodology offers significant benefits for customers in its approach to collaborative problem solving and quick wins. Where a customer objective for an ICT solution cannot be translated into workable specifications, or where a customer wants the market to offer ideas to meet its objectives, agile methodology offers a way of working together to investigate those objectives. But use of agile methodology can also create uncontrolled uncertainty. This is because the methodology (which was developed by a vendor group) is based on ongoing change and flexibility, without certainty of timing or cost.

There are ways to insert some controls into agile methodology without removing all the benefits of agility, and customers now need to proactively take this approach in their procurement strategies.

Most current ICT contracting procurement documents do not contemplate the use of agile methodology. It is often proposed by tenderers, and without proper consideration, it may be incorporated in a contract in a manner that overrides and removes most of the standard customer controls and protections. Standard RFT documents do not work for agile methodology, because they do not mitigate the specific uncertainty risks this methodology can pose, if not properly managed.

Agile methodology involves:

• working to a product vision, rather than detailed functional requirements
• allocating resources to work in a sprint, to achieve a release, which incorporates some functionality from the product vision
• the customer assuming responsibility for work outputs
• leaving functionality not yet developed in the product backlog
• unanticipated changes occurring during a sprint
• paying for resources and time, rather than accepted solutions.

All of this means uncertainty for customers – there is no certainty that all requirements will be met, that any specific timeframe will be met or that any budget constraints will be met. However there are ways of superimposing some controls, without losing the benefits of agility.

Proactive solutions you can utilise in procurement documents that are likely to involve a design or development phase include:

• Draft the RFT and Statement of Requirement to actively contemplate agile methodology, so that your requirements are expressed as items of functionality that can become the Product Vision for a methodology sprint (include controls on what must be achieved)
• Include in your evaluation methodology consideration of whether tenderers can achieve the outcomes you need using the methodology (ie do they understand the requirement? Or are they proposing they work that out once they get the job?)
• Incorporate your preferred methodology, with provisions that utilise controls for key issues of concern to customers (these are new forms of contract mechanisms and protections)
• Include ‘get out of gaol’ protections for early failures (so you don’t have messy divorces and unexpected costs)
• Prepare your performance management framework to measure the success of the methodology as well as the outcome of the process (these are different sorts of service levels and performance standards)
• Design your pricing approach to reflect iterative development and not major solution milestones (you can price for agile without relying on time and materials)
• Design your contract management approach to reflect this methodology (so you don’t stray towards unplanned uncertainty).