The case is London Borough of Southwark v IBM UK [2011] EWHC 599 (TCC). Computerworld has a good write-up of the facts.

In short, Southwark Council embarked on an ambitious systems integration project to build a Master Data Management (MDM) system. Such projects have been fertile ground for legal disputes. The Court noted (in typically understated fashion):

In practice, it has been found by a number of the London boroughs which have introduced or tried to introduce MDM systems that they are complex.

In March 2006, the council’s IT dept drew up a Project Brief. The next month, the council met with IBM, which proposed a solution to meet the Project Brief that would cost between £1.5 million and £2 million. However, Southwark had a budget of only £500,000. As a result, it was agreed that a more limited solution would be carried out, to meet the council’s budgetary constraints.

During 2007 the project got underway and some progress was made, but problems soon ensued (as detailed in the judgment). In October 2007, a council staffer notified the first complaint against IBM, alleging that “the MDM ’solution’ procured from IBM is not fit for purpose”.

“Fitness for purpose” is a legally loaded term. In New Zealand, it is an implied condition of sale (via the Sale of Goods Act 1908) that goods known to be bought for a particular purpose must be fit for that purpose. This applies to business and consumer goods (and “goods” includes software). There is a similar provision in the Consumer Guarantees Act 1993, though importantly, that Act applies to services as well as goods, and (in the case of consumers) cannot be contracted out of.

It is interesting to see from the judgment that after significant problems emerged, the council simply blamed IBM for delivering software that was “not fit for purpose”, apparently without looking at whether it (the council) selected the right solution for its purpose. (The fact is, it compromised on its requirements from the outset in order to meet its budget.)

I have been involved in a number of major IT implementation disputes where this has happened, with remarkable similarity. Part of it, no doubt, is corporate CYA culture, but the bigger part of it was (once you reduce it all down) the simplistic mindset that “we paid you truck loads of money, and you’re the IT experts, so if anything’s gone wrong it must be your fault”. Given what actually happened in these projects, this is quite unbelievable.

IBM reasonably responded to the council as follows:

At the time of purchase [the council] chose not to take a total solution/system option due to the cost implications and decided to contract the individual software and services items separately. In addition, [the council] chose to project manage the MDM implementation with assistance from the IBM software services team … and to date the IBM services contract has had only approximately 50% utilisation.

In Court, the judge echoed IBM’s comment above, saying:

[IBM's software] does “what it says on the box”. An analogy is the potential car purchaser who might want an off-road vehicle but, having looked at the brochure for an on-road vehicle, says to the salesman “that’s what I want” and buys that vehicle. There will be no cause of action against the garage that the car is no good off the road. The salesman will reply, with justification: “you got exactly what you asked for”. That is essentially what has happened in [the council's] case.

In my judgement, [the council] got by way of [IBM] exactly what its then team knew that they were getting and what it decided that it wanted and needed within its budgetary constraints.

As a result, the council had its case against IBM thrown out, and was ordered to pay costs to IBM. Moreover, the judge awarded indemnity (full reimbursement) costs in favour of IBM because of the council’s failure to accept a reasonable “walk away” settlement offer before the trial, in circumstances when it should have seen that its case had serious defects.

In other words, the pre-trial evidence put forward by IBM should have made the council realise that neither IBM nor its software was to blame, but that the client had itself simply chosen a cut-down solution that was “unfit” for what it later said it wanted – a situation I have witnessed on a number of occasions (and all of which we successfully settled out-of-court on favourable terms, I might add).

By focusing on the technical weakness inherent within the job specification that the client has signed off on, and forcing variation to contracts as they work their way through, even though the supplier knew at the start that they could not meet timeframes and delivery targets, the multinational easily arm-wrestles the hapless customer to fund excess profitability. These projects follow the same pattern over and over again, they become five to six times over budget – a $20 million project can turn into a $120 million one. The supplier knows that walking away is not an option for these clients.

While Gareth addresses a broader issue, many of the problems he discusses arise from poor contacting. There are a number of problems endemic in IT project contracting:

• The project is simply contracted far too large.
• The contract relies on the often faulty assumption of Big Design Up Front.
• The contract is prepared as if it were a construction contract.
• The contract is only seen as “safe” if it nails down every last detail, and only allows changes through variations, which as Gareth says usually produce poor results.
• The contract imposes completely unrealistic and ineffective “project management and control procedures”, that are either never used or are simply “caught up” on from time-to-time.
• The contract is usually in conflict with the “agile intention” of the project (whether or not an agile methodology is actually going to be adopted).

I have written about some of these problems (and overcoming them) here: Contracting in an agile world (part 2 here). The solutions are not complicated, but when contracting is seen as a contest (which party can tie the other up the most?) the result can be a contract that’s more useful when the project actually fails, than facilitating the project’s success.

When the cost of IT failure in New Zealand is $5.4 billion a year, it pays to get the comparatively small matter of contracting right.

The emergence of agile development

Agile development emerged during the mid 1990’s and early 2000’s as a grass-roots reaction to the problems of traditional development experienced in many projects. There is no official definition but rather a set of principles, the most authoritative text being the Agile Manifesto.

Principles contained in the Agile Manifesto include:

• Customer satisfaction through early, continuous delivery of working software;
• Welcoming changing requirements, even late in development;
• Clients and developers working together throughout a project;
• Regarding working software as the primary measure of progress.

This requires a significant departure from the structured processes of traditional development. It allows developers and clients to adapt a project as it progresses. It allows software to be delivered and used continuously and problems corrected early and often. It encourages large projects to be broken into smaller projects, with functionality being added incrementally. It allows developers and clients to provide ongoing feedback and refinement as the system is developed. This dynamic can be invaluable in today’s business environment where businesses must be ready to adapt their business processes to meet market conditions and new technologies.

On the technical front, agile development encourages flexible system design through the use of software patterns, standards and best practices. Project management models have been created specifically for agile development and a range of sub-methodologies under the “agile” umbrella have emerged.

Agile development is not intended to replace traditional development but is an alternative methodology. Traditional development is still used on many projects and has many benefits. However, agile development has become increasingly popular, and by some estimates (see here and here) is now the predominant development methodology in use today.  It appears to be successful.  The Standish Group’s 2006 Chaos Report attributed the decreasing failure rate to 19% in part to agile development.  Other evidence supports this conclusion.

Contrasting traditional versus agile development

The following table contrasts key elements of traditional versus agile development.

These elements are discussed below.

Continuous delivery

It is common for software development contracts to define deliverables to be handed over at the end of a project. For example, the deliverables may be a functioning system meeting the contract specifications together with completed documentation and other supporting artefacts.

In contrast, agile development promotes continuous delivery throughout a project where incrementally updated versions of a system are delivered as they are available, with the objective being to enable the client to begin using the software as soon as possible, even if only for a subset of the final intended functionality. In this way, flaws in system design can be detected and remedied earlier than would be otherwise possible and feedback can be acted upon.

At this point, it is worth asking “why would anyone want to use an incomplete system?” The answer is, by breaking large projects into smaller projects, it can be possible for even a very complex system to be delivered incrementally. How each interim delivery should be used depends on the project, with options ranging from production use to basic testing, and go-live risk management provisions should always be in place. Ultimately the extent and manner in which continuous delivery is viable and sensible for a given project is a commercial decision.

In-project requirement changes

Every software development project needs some up-front requirements analysis. The extent and formality of the initial analysis phase will vary project by project. Traditional development relies on heavy up-front requirements analysis (Big Design Up Front) which is typically incorporated into a contractually binding specification. It is not intended that continuous or major changes be made to the specification during the project.

In contrast, agile development expects, and even welcomes, changing requirements during a project, even at a late stage. This is essential to agile development. It allows the project to develop and evolve incrementally and respond to changes in business processes that it seeks to implement.

This may appear contractually problematic, even dangerous, and indeed it would be if it were allowed to be uncontrolled. A sensible change process must always be defined, together with parameters to control project scope including technical direction, timelines and cost. There is no reason why agile development projects cannot utilise common contractual elements for controlling scope while still allowing the desired flexibility for regular requirement changes.

Collaboration

Collaboration in the sense of agile development means the process of ongoing, regular, formal and informal communication and co-operation between the client and the developer, even to the extent of working together on a daily basis throughout a project. This contrasts with the customer-vendor model of traditional development, where the developer works on a project off the specifications largely in isolation from the client and “hands over” the finished product at the end of the project.

While traditional development often utilises control groups, steering committees, scheduled reviews and the like as effective forms of client-developer collaboration, agile development seeks to go much further. Agile development advocates having representatives of the client and the developer working together constantly throughout the project. This raises potentially thorny legal issues such as representations, authorisations and estoppel. These are issues which must be considered both practically and legally in all software development projects and there is no reason why an agile development project cannot utilise the protections against these risks commonly found in traditional development contracts.

Again, the manner and extent of collaboration is a commercial decision for each project and the practicalities of this arrangement should be clearly defined at the start of a project.

Finally, in conclusion…

To lawyers, agile development may appear an unattractive or even counter-intuitive option when compared to a highly structured traditional development project. After all, how can a contract accommodate informal requirement changes, continuous delivery, close collaboration and other “agile” processes while still providing the clarity, safeguards and controls required in commercial dealings?

It must be remembered that it is the problematic rigidity of traditional development that agile development specifically seeks to avoid. This is not for the purpose of reducing liability of any party, but to reduce the risk of project failure. A heavyweight, rigid contract may provide greater advantages to a party in the event of litigation, but for some projects may actually increase the likelihood of litigation.

Whether or not to use agile development on any given project is ultimately a commercial decision. It is one that incurs a risk versus return trade-off like anything else and clients must be in a position to make an informed decision.

The key issue where agile development is desired is that the contract supports the necessary agile processes. Contracts used in agile development projects must be drafted to ensure that the agile processes are not curtailed by a contractual regime better suited to traditional development. This does not mean that contracts should be any less clear and precise than they otherwise might be, nor does it require the diminution of standard commercial safeguards and time and cost controls. But it does place a greater onus on the drafters of contracts to ensure that clients and developers can reap the benefits of agile development under a contract supportive of that methodology.

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;
• Deliverables;
• 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 [2001] 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.