Buyer beware… of getting what you ask for

A recent UK technology case gives a good example of “buyer beware” and “you get what you pay for” in technology procurement.

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).

Contracting for success or failure?

Gareth Morgan has written an interesting article (a follow up to this one) discussing the “systemic failure to be more successful in using IT to capture material productivity improvements”:

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.

Contracting in an agile world, part 2

For part 1 of this post, click here

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.

Continue reading

Contracting in an agile world, part 1

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.

Continue reading