By Alan Cane
Published in the Financial Times, November 20th 2007
Computer projects fail regularly: a frighteningly large percentage are either late, over budget, do not work or do not deliver what the customer wants.
The gory details are rarely publicised, however. Both supplier and supplied have too much at stake in terms of reputation and customer confidence to want to wash their dirty linen in public.
However, the court action currently running in London’s technology and construction court between British Sky Broadcasting (BSkyB), the claimant, and Electronic Data Systems (EDS), the defendant, is manna from heaven for students of information technology management. If this case doesn’t end up as a classic business school case study, I’ll take out a subscription to BSkyB.
Briefly, BSkyB is suing EDS for £709m in damages, claiming it made a “deliberate, cynical and dishonest” sales pitch for a multimillion pound contract to build a customer call centre. EDS intends to defend its position vigorously and the case is expected to run for months.
I have no intention of venturing an opinion on who is in the right: that is for the court to decide. But there is no doubt that the project as originally envisaged never worked and the final result is still unsatisfactory.
The introductory statements to the court made by both parties provide copybook examples of the adversarial positions taken by each side when a project goes wrong.
Briefly, in the summer of 2000 BSkyB needed a new call centre complete with a state-of-the-art customer relationship management system, in part to reduce “churn” among its customers. Bidders for the project were EDS, PwC and the then Arthur Andersen, now Accenture.
EDS was chosen on the recommendation of BSkyB’s chief operating officer, but against the advice of BSkyB’s chief technical officer. It started work on the project on a time and materials basis with a baseline budget of £47.6m and a time scale of 18 months. By March the next year, the project had failed.
BSkyB blames EDS, whose performance under the prime contract it alleges was “disastrous”.
EDS sees things differently: “The negotiations were difficult from the start because Sky, by its own analysis, did not know what it wanted but was determined to arrange things in such a way that it paid as little as possible for whatever it was. The result was a contract under which EDS was to work on a time and materials basis to deliver a system, the specifications for which were yet to be formulated.”
The project was redesigned and new deadlines agreed, which were not met. BSkyB then took over the role of systems integrator. Finally, in December 2005, the system built by BSkyB went live at a cost of £262.3m but without all the bells and whistles the broadcaster had hoped for. So it became a prototypical example of its kind: well over time, extravagantly over budget and functionally deficient.
The unanswered question, however, is why do big software projects of this kind continue to come to grief? Are lessons never learned?
As Michael Gentle points out in a new book*: ”Either a goblin has cast a spell on a whole profession – or that profession is doing something fundamentally wrong.” He thinks the approach IT companies and departments have taken to designing and building systems is flawed.
“For IT,” he writes, “building systems was initially modelled on the construction industry, with the IT department the equivalent of a contractor who is supposed to deliver systems on schedule, within budget and to spec.”
But, he goes on to argue, building software is not like building houses and the analogy cannot hold. He suggests it is impossible to define an IT project in terms of contractual budgets and schedules – so in his terms, BSkyB and EDS with their £50m-budget and 18-month timescale were on a loser from the start.
He writes: “Though long a dream in IT, it is not yet possible – and probably never will be because of human behaviour and the fact that each company is different – to have standard process components with standard costs which can be used to produce a quote and delivery date.”
He proposes a different model, which takes account of the unavoidable uncertainties in the software development process. Establishing a partnership between client and vendor – rather than the traditional customer/contractor relationship – where the risks and rewards of the project are shared, should lead to a more realistic cost and timescale scenario.
Mr Gentle’s proposals are not wholly new: more a clever synthesis of enlightened IT project management thinking over the past few years.
He pays due respect to methodologies such as CMMi, CoBIT, ITIL, Prince 2, while pointing out that, despite their virtues, they are inevitably associated with the construction model of software development.
Essentially, what he is arguing for are workable results rather than strict compliance with any development processes. Is he right? The list of failed projects suggests that he is at least on the right track.
Knocking down software development rules built up over 50 years may be difficult but, without change, the entertaining but essentially destructive spectacle of companies knocking spots off each other in the courts will continue.
* IT SUCCESS! Towards a new model for information technology, by Michael Gentle (John Wiley & Sons, £19.99/$35.00)