"It is evident that the way in which government procures ICT is not designed to support agile delivery of digital services that meet user needs" - Report of the ICT Procurement Taskforce, Digital Transformation Agency, 2017
If Australian Government agencies are going to procure ICT services by taking an agile and user-centred approach - a requirement under the Digital Service Standard - a fundamental rethink of contract terms and conditions to properly reflect and support the delivery of agile projects is required.
Most standard ICT procurement contracts for software and application development set out what is to be delivered (including functional and non-functional requirements of the system), when it is to be delivered and for how much, as well as risk allocation provisions in the event something goes wrong. This certainty is intended to minimise risk and reflects the obligation under the Commonwealth resource management framework that agencies should use public resources in an efficient, effective, economic and ethical manner.
However, agile methodologies have adaptability and flexibility at their core. A contract for the delivery of services on the basis of an agile methodology - under which a solution will evolve throughout the process to meet the customer's requirements - must therefore be different to a standard ICT design and development agreement.
What is "agile" and how is it different to other delivery methods?
Most traditional delivery models for ICT development projects follow a similar sequence of distinct phases, from detailed planning, to design, development, testing and integration, and finally deployment of a fully functioning and finished product.
In the Commonwealth context, this structured approach is typically followed and contracts with vendors have been designed to support the delivery of projects following this methodology. This is also reflected in detailed statements of works which follow a sequential approach to delivery, supported by contractual remedies, if the vendor fails to deliver according to such a plan.
However, when an agency's specific system requirements are not absolutely certain, or are likely to evolve over time, locking these down in a statement of work is more likely to result in the delivery of a solution that does not ultimately meet all of the agency's needs. It may also result in the agency paying for features that it does not require. In many cases, such projects will be delivered late and over-budget, as contract variation processes are deployed to try to capture the agency's changing requirements over time.
In response to the challenges of building software that meets customer needs, in 2001 a group of software developers published the Manifesto for Agile Software Development setting out four main values:
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
Underpinning the Agile Manifesto are 12 principles, including:
- customer satisfaction is best achieved through early and continuous delivery of useful software;
- working software is the primary measure of progress and should be delivered frequently;
- changing requirements, even late in development, is welcomed; and
- business people and developers must work together.
While the Agile Manifesto was developed to apply to software development, the underlying principles have been applied in a wide range of contexts, including the delivery of other business-critical ICT transformation projects through to policy development.
A project delivered using an agile methodology (for example, Scrum, Kanban and Extreme Programming (XP)) therefore stresses collaboration, adaptation and flexibility, and iterative and incremental development and reviews. Each model encourages short and frequent cycles or iterations, which results in the delivery of a viable product following each iteration. Planning, design, development, testing and integration, and deployment activities will all be carried out simultaneously, focussing on the current iteration. As a result, problems can be identified early and on a relatively smaller scale, and can therefore be resolved quickly.
Key characteristics of a contract for an agile project
In the Commonwealth context, existing ICT contract templates do not tend to include adequate provisions to reflect the different nature of agile projects. A fundamental re-think is therefore required to effectively support the delivery of agile projects, from how agency requirements are reflected in the contract through to appropriate protections and risk allocation provisions.
Instead of setting out detailed specifications, pricing and timeframes for delivery, and provisions for when things go wrong, the main objective of a contract for the delivery of a project using agile methodology is to structure the relationship between the customer and the vendor. As the contract is for the delivery of an outcome, rather than a thing, the contract will need to set out how the project is to be governed and delivered and the responsibilities of both parties in working towards that outcome.
Additionally, rather than focussing solely on risk allocation provisions and contractual remedies if a project fails, an agile development contract focusses on the rules of engagement to ensure problem and failure resolution in real time.
It is critical to ensure that your contract terms align with an agile methodology for delivery. In our experience, contracts for the delivery of projects using an agile methodology are often subject to disputes because the underlying contract with the vendor reflects a traditional waterfall approach to delivery, where issues tend to arise near to the end of a project when it has already, in effect, failed. Such contracts often do not include the necessary governance processes to promote ongoing visibility and the ability to resolve issues as they arise.
Legal terms and conditions
To ensure that the parties understand the expectations of the relationship in an agile context, a contract should include specific provisions and clear requirements relating to:
- key roles and personnel including the roles and responsibilities of key agency personnel (such as a product owner), development teams, and agile "coaches" (such as "scrum masters" in Scrum terminology);
- key processes and governance requirements including for the development process (for example, sprints), various meetings to support the process, testing requirements and timeframes; and
- key documentation and tools including the project objectives and target outcomes, development items (such as a product backlog), tracking tools, and management information to support decision making.
While the specific provisions and terminology will vary depending on the specific agile methodology used, establishing the processes and expectations around these three key areas is critical in drafting an appropriate contract to support the effective implementation of a project based on an agile delivery methodology.
In addition to agile-specific provisions, a contract for delivery of a project using an agile methodology may also require reconsideration of and changes to standard clauses, including with respect to:
- warranties;
- intellectual property rights;
- liability;
- termination;
- dispute resolution; and
- change control processes.
Commercial terms
There are a number of different pricing models for the delivery of agile projects. Commercial terms need to be structured in a way that appropriately rewards the vendor for its efforts, while ensuring protections are in place for the agency.
Agency and vendor approaches to pricing an agile project are likely to be very different. While agencies will naturally want the certainty that comes with a fixed price, this can erode the benefits of an agile delivery model by parties seeking to mitigate their risk by setting out rigid specifications and payment and change processes.
Vendors, on the other hand, are likely to want time and materials pricing to reflect the inherently uncertain scope of a project delivered using an agile methodology. However, a pure time and materials engagement creates disincentives for the vendor to develop realistic estimates and then to adhere to them.
Hybrid models, where elements of a project with a firm scope or requirements are delivered under a fixed price model and other parts are delivered based on time and materials (but subject to either a per iteration or overall cap) are also commonly adopted. Ultimately, the success of any pricing model, for both agencies and vendors, will depend on skilled delivery teams who can accurately estimate the effort required for delivery of a project using an iterative approach and are committed to continuously monitoring performance.
Hybrid delivery models
For hybrid project delivery (for example where a firm statement of functional and non-functional requirements is set out in the contract, but delivery by the vendor will be on the basis of agile methodology), existing ICT contract templates will also require changes. Agencies should ensure particular care is taken in such situations to ensure that appropriate terms and protections apply to different parts of the project.
Tips for success
When designed well and managed and implemented effectively, contracts for the delivery of projects using an agile methodology can be effective in ensuring value for money outcomes for Australian Government agencies in their procurements of software and application design and development projects. Success will depend on:
- vendor experience in delivering projects using agile project methodologies;
- skilled and committed agency delivery teams who continuously monitor vendor performance; and
- early engagement with legal counsel and other internal and external stakeholders who have familiarity with contracts for the delivery of agile projects.
If you are considering procuring ICT services by taking an agile and user-centred approach, please don't hesitate to contact us. At Clayton Utz, we have advised a number of Australian Government agencies and clients in the private sector on contracts for the delivery of software and application development services using agile methodologies.