IT Procurement - Too Messy to Sue

Following my previous post on IT procurement - Too Big to Fail, a new twist has emerged - projects that are too complicated or expensive to hand over to the lawyers.

An HR system for the Metropolitan Police is currently running late and over budget [TimesOnline 17 May 2010, The Register 17 May 2010, via @exmosis.]

	Original Plan	Current Plan
Cost	£38M	£48M
Annual Savings	£15M	£15M
Expected delivery	December 2009	Late 2010

Not only is the payback period now gone from 2.5 years to over three years, but the benefits will be delayed by nearly a year - so the true additional cost is not just the extra £10M in cost but nearly £15M in delayed benefits. The system was originally supposed to “generate significant efficiencies to release additional funds for front-line policing”, but on these figures that isn't going to happen until 2014 at the earliest.

Who is to blame for this? According to an anonymous source, “Lawyers have been consulted but the cost of litigation would be greater than the cost of trying to fix it.” Seems hardly any point having procurement contracts at all, if it's too expensive to enforce them.

Payback period is a pretty crude measure of ROI, but it is quite commonly used. Some organizations might have a policy that all projects should have a payback period less than three years. But that creates a temptation for budgets to be deliberately underestimated in order to conform with this policy, only to be reevaluated once the project was too far gone to cancel. That couldn't have happened here, could it?

IT Procurement - Too Big To Fail?

A judge has found in favour of BSkyB following a £700m legal battle with EDS (now part of HP) over a failed IT system (Computer Weekly 26 January 2010). One of the interesting features of this case is that it rested on the claim that the supplier had made "fraudulent misrepresentations" at the bidding stage. In other words, it wasn't about the small print of the procurement contract.

The judge ruled that if EDS had not made misrepresentations to Sky, then Sky would have engaged another company, PriceWaterhouseCoopers. I don't know whether HP/EDS would have any grounds for appeal if it turned out that PWC had also made misrepresentations at the bidding stage. @tonyrcollins tells me that EDS/HP has spent £35m on lawyers so it may have been considered but you never know.

EDS "misrepresentation" in BSkyB case - some comments by the judge - IT Projects Blog
Lessons from BSkyB case - CIO

---

Further examples

The London Borough of Southwark is taking legal action against IBM over a software solution it claims is not fit for purpose (Computing, 30 October 2009; Kable, 2 November 2009).

Sprint-Nextel versus IBM, Vertex Data Sciences versus Powergen (Outsourcing disputes, HG.org, 31 October 2006)

IBM versus the Philippines (The Inquirer, 8 June 2009)

See also my earlier post on the dispute between Centrica and Accenture - IT suppliers face architectural risk.

IT suppliers face architectural risk

@tonyrcollins reports on the implications for large IT contracts of the Centrica v Accenture dispute (Computer Weekly, 9 December 2009). The dispute concerns a "best-of-breed" replacement billing system for the entire British Gas business, which Centrica ordered from Accenture in 2002.


Centrica is invoking a clause in the contract that refers to "fundamental defects", and a lot of the legal activity has been trying to determine what this phrase actually means. Although Accenture argues that the various problems experienced with the system have been unconnected and therefore don't count as fundamental, the High Court has accepted Centrica's interpretation that the cumulative effect of these defects may indeed be regarded as fundamental.

 The article quotes Peter Clough, head of disputes at law firm Osborne Clarke:

"One of the important points to note about this case is that IT suppliers can be liable for claims for fundamental breach arising from the cumulative effect of a series of faults, each of which could look relatively minor in isolation. The majority of systems will of course be inter-linked so that a defect in part of the process could affect another part, snowballing into a more serious issue."

So this is about architecture and risk. From a risk management perspective, a critical responsibility of the architect is to make sure that a lot of small problems don't add up to a big problem.

And it is also about procurement and risk. If this judgement stands, it appears to shift certain kinds of risk from the customer to the supplier. Obviously one solution to this would be to redraft procurement contracts. But another solution may be that large IT suppliers may be required to engage much more proactively with the broader architectural context for the systems they are building.

So can we expect all the major IT suppliers to look at architecture and risk from a new perspective?