For many years the standard software development contract has been prepared on the basis of a waterfall development methodology. However, many development projects are now delivered under an agile methodology, which is fundamentally different in a number of respects. This article focuses on one of the key differences: the extent to which the customer’s requirements are fixed or flexible. The difference in this area alone can call for quite different approaches in the contract.
Waterfall projects: fixed requirements
When preparing contracts for waterfall projects lawyers tend to focus on locking down the “iron triangle” of scope, price and timetable. In this respect, the customer’s requirements play a critical role in determining the scope and key features of the contract. For example, the obligation to meet the agreed requirements forms the baseline for the acceptance tests and feeds into the warranties, timetable and payment milestones. Given the integral role of the requirements, they are usually fixed at the start of the project and are not permitted to change other than through a formal change control process.
Agile projects: flexible requirements
Contrast this with the treatment of requirements in an agile project, where the software is developed in short iterations. Rather than locking down the requirements at the start, the requirements are expected to evolve as the customer reviews the software after each iteration. The customer can learn from what has been delivered, make mid-course corrections and prioritise on its most important requirements. The agile approach also enables the customer to focus on what can be achieved in collaboration with the supplier, within the context of any agreed constraints (which can include a high level vision, timeframes and dollars).
A waterfall based contract will rarely be a good fit for the evolving requirements in an agile project, and may instead provide fertile ground for disputes.
However, not everything in an agile project is flexible. The requirements are often locked down for each iteration and sometimes the flexibility is more around how a requirement is delivered as opposed to what the requirement is. Also, as the measure of progress in an agile project is tested working software, the supplier can be required to ensure that each software release meets agreed quality requirements and other criteria. This provides some certainty around the quality of the software and what will happen on an iteration by iteration basis.
Agile contracts
A waterfall based contract will rarely be a good fit for the evolving requirements in an agile project, and may instead provide fertile ground for disputes. An agile contract needs to clearly cater for what is flexible and what is not, and the implications for areas such as testing, warranties, change management, fault resolution and pricing. Also, as the benefits of the methodology are closely tied to following the methodology, it is worth considering the extent to which the contract should capture key process requirements, roles, events and documents along with the general rules for making decisions.
However, be careful to tease out with the supplier as to exactly how it does agile. There can be a lot of variability in agile approaches, and it is not unusual to see a hybrid approach that has both waterfall and agile related features.
Your next software development contract
A software development contract should be designed to work with the development methodology for the project. Consider asking the following the next time a development contract hits your desk:
1. What is the development methodology?
2. What does this mean for the scope?
3. What is fixed? What is flexible?
4. What does this mean for the timetable and pricing model?
5. Where is the above reflected in the contract?
Asking these types of questions will help flush out whether the contract is a good fit. Indeed, if the wrong contract has been proposed it may signal a major gap between the expectations of the customer and the commercial model of the developer. This tends to end badly. Far better to surface these issues at the contracting stage and get a framework in place that reflects the reality of the project.
Stuart van Rij is a consultant at Wigley & Company, a law firm specialising in ICT. Reach him at stuart.vanrij@wigleylaw.com
Join the CIO New Zealand group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.