Are your contracts agile? If you are involved in contracting software development it is worth asking that question.
Agile development is a relatively new methodology for software development which has rapidly gained popularity. Much has been written on agile development in the technology media, however there is little mention at present in legal circles. Perhaps this is due to the subject being regarded as a technical issue best left to the IT crowd.
Lawyers involved in contracting for software development need to be aware of this now common methodology. This article outlines agile development and some of the contractual issues it raises.
Traditional software development
Software development has traditionally been viewed as a structured process, sometimes known as the “waterfall model”, where each phase of the project is clearly defined as part of a linear sequence. A typical project may be look like this:
- Phase 1: Requirements specification;
- Phase 2: Design;
- Phase 3: Programming;
- Phase 4: Testing and debugging;
- Phase 5: Deployment.
A project such as this, with discrete steps capable of clear definition and sequencing, is well suited to a structured contractual framework. Common elements of a contract supporting this model are:
- Comprehensive, detailed specifications;
- Formalised processes such as control groups and regulated variations;
- Segregation of responsibilities between the developer/vendor and the client;
- Strict timetables;
- Sign-off and handover processes.
While there are as many variants of software development contracts as there are projects, in this article a traditional software development contract is one taken to include the above as well as the usual commercial terms and exclusions.
Problems with traditional software development
As practitioners involved with IT and followers of IT media will doubtless be aware, software projects have historically failed at terrible rate. Way back in 1995, US consultancy The Standish Group conducted its inaugural “Chaos Report”, an annual study into development project failure. The first study reported that 31% of all development projects failed – that is, are cancelled and scrapped at some point – while only 16% were on-time and on-budget. The remainder are termed “challenged”, where the project is eventually completed, but is over-budget, over-cost or cut down from the original plan.
Through such studies and industry analysis, it soon became accepted that the “heavyweight” processes of traditional development are not always compatible with the highly dynamic modern business and technical environment. From a contractual viewpoint, the formalised specifications, processes and deadlines mandated for a project often conflict with the informal, complex and constantly evolving business requirements they seek to implement.
The problem as it relates to custom software development has even been judicially noted:
“[There] is a significant risk that a non-standard software product, ‘customised’ to meet the particular marketing, accounting or record-keeping needs of a substantial and relatively complex business … may not perform to the customer’s satisfaction”.
Watford Electronics Ltd v Sanderson CFL Ltd  EWCA Civ 137
Of particular importance is the challenge of obtaining detailed and complete specifications at the beginning of a project. This is known as Big Design Up Front, and the output of the design is often used to form the basis of a contract. In such cases, the success or failure of the project is dependent on the quality of the contracted specifications.
Unfortunately this has in many cases proved highly problematic. [For an early influential paper (1986) on the challenges of design see “A rational design process: how and why to fake it”]
While there are many causes of project failure and disputes, inadequate requirements are regularly cited as a leading cause. Key problems, simply stated, include:
- Difficulties in documenting complex abstract business processes;
- Inability to completely specify requirements at the beginning of a project;
- Requirements changing during the course of the project (particularly for long duration projects).
Part 2 of this post discusses how agile development aims to address these issues, and the challenges for contracting such projects.