Major IT projects are similar to the old adage about advertising: more than half of the expenditure is going to be wasted. Unfortunately, it is impossible to predict where the sinkholes will be.
Serious research internationally suggests that a staggering four out of five major IT projects will not deliver what was expected or required. In other words, just about one in five delivers solutions to a happy organisation.
Semantics play a part. In every case we would need a definition of the ‘failure’ or ‘expectations’ or ‘objectives’ to make a judgement. You have to be fair: lots of projects, large and small, run into snags and delays, run over budget, cause disruption, tension and rows. Then the stuff slips into place, the system works and does most of what it set out to do and perhaps other things that were added along the way and everybody moves on.
But then there are the other ones: slippage from the first deadline, endless briefings and discussions and revisions, escalating costs, people working all hours and so on. The results of all this effort may just about be deemed acceptable but may also be put on hold or abandoned altogether.
This type of project is often followed by a new team of consultants or experts coming in to examine what went wrong — or prepare evidence for the court case. Rob Thomsett, an Australian expert in what he terms ‘project pathology’, says, with weary cynicism, that there is one clear and easy test for a failing project in your organisation: try to stop it. “If a project is failing, a request to stop the project for planning sessions and timeouts will be met with the clearest indicator of a fatal disease: “We can’t stop the project for planning, we have a deadline to meet!'”
Taking a high-level view, there are only three criteria for a successful IT project: The system works as required; it is delivered on time; and it is on or under budget. Very few projects achieve all three, yet if the No. 1 objective is met — ie it works — failure in keeping to timescale or budget may be in fact acceptable in normal business management terms.
Dublin IT consultant Conor McWade of System Dynamics reckons that every single major organisation in Ireland has had at least one IT project disaster, including the big financial institutions and the government sector.
“Big organisations tend to go for the big consultancy outfits in the tacit belief that they will take the lead — refine the brief, draw up the spec and so on — which is a bit of a blank cheque and no guarantee of project success,” he explains. But he is sure at the same time that the fundamental reasons for project failure almost always go back to the client rather than stemming from the technology itself.
Underperformance by the consultant/contractor can happen, but the original choice then comes into question. “Often they do not really know what they want, there is no clarity on the scope of the project and little control of any iterations of change along the way — and they don’t anticipate the people issues and the effect of process and organisational change,” McWade continues.
None of the issues is new, but what has been emerging in larger organisations worldwide is a new functional area of programme management, since development and change is now a constant in business and half a dozen major projects on the go at any one time is not unusual.
“Taking a structured and standard approach to projects has many merits,” says Nial Connor of KPMG Business Advisory Services, “not least that knowledge and experience is built up within the organisation. Such programme offices can supervise and control from above but they are also a great support and resource for project managers who are sometimes having to struggle for co-operation, resources or whatever — or simply encounter project snags that could not have been anticipated.”
He notes wryly that 81pc of respondents to KPMG’s 2002 survey chose ‘home-grown methodology’ as best matching what their organisations had been doing: “I suspect that may translate as ‘no real project management method at all’,” he adds.
What has to be clear to anyone who reads up even lightly on the failures of IT projects and the experience of others is that there are no guarantees of success and complete success is rare. On the other hand, appreciating what can go wrong — or experiencing it directly — is still our all too human learning method and about the only way to get it to go right.
Phrases such as ‘the ill-fated ILCUtech’ project — better known as ISIS — are likely to recur in the business and IT history of this country for a long time, since an expenditure of €34.28m in under three years with no tangible return whatsoever is spectacular by any standards.
Most of the members of the Irish League of Credit Unions (ILCU) invested in the ISIS project, a grand design to revitalise the credit union movement for a new generation, link several hundred sites and enable local credit unions to offer ATM services to their members.
The vehicle was ILCUtech, a company specially set up for the project. The largest share of the money went to OSI, a firm of consultants from the UK which had been chosen — no one at this stage seems clear why — to design and lead the project. Now called Xansa, it is quoted on the London Stock Exchange and enjoys successful relations with a number of banking clients including Barclays and ABN Amro.
The €16.5m OSI bill was followed by over €11m to Sanchez, the US software firm whose retail banking software was chosen on OSI’s recommendation. Sanchez has a range of successful implementations on both sides of the Atlantic including, curiously, a specific product for credit unions that was not the software chosen for ILCU. But it had never worked with OSI previously.
Cara was the main Irish contractor — or rather was poised to be. It was to look after the implementation across the country and manage the data centre and support and help desk function. When the project died the data centre was up and running before the rollout really got under way.
Cara was paid also, but left with the potential problem of 26 staff recruited specifically for the project. In 1999, however, we still had an IT skills shortage so they were speedily absorbed by other projects. It has been common knowledge since the collapse that many ILCU leaders wished to sue OSI but that idea appears to have been abandoned since the league’s AGM last month.
The ILCU has new leadership and senior management since the ISIS debacle that politely declined to discuss the subject for this article with phrases such as ‘drawing a line under it’ and ‘closure’. Understandable, perhaps, because the league is a movement with many dedicated volunteer officers and trustees and the ISIS fiasco has left wounds and pain.
Unfortunately, in the consensus view of the IT people who were associated with it and the industry community who watched it carefully in this tiny market, it is that very nature of the ILCU that contributed most to the failure of the project. It is also going to be the reference for discussion of project failure in every business school, media article and pub debate for the foreseeable future.
Caught in the crosshairs of hindsight, some of the elements that contributed to the doom of ISIS seem all too clear. It was actually on a massive scale and much more than a linking system between the individual credit union offices. It involved standardisation of systems and completely new business processes and was going to be the instrument of delivery for a whole new vision and set of objectives for the credit union movement in Ireland. For example, the principal motivation for having ATMs was to attract younger members, working by day and drawing cash from the hole in the wall at evenings and weekends.
Credit unions could begin to offer credible competition to the banks and building societies. At the time, and presumably to this day, there were about 30 different systems in use in individual unions. There is a tier of larger ones with perhaps 15-30 users on a network and a number of locations, but at the lower end there are totally volunteer unions with evening opening hours and perhaps a single PC. Not more than a handful of unions has an IT person on staff and the IT manager role falls to each general manager, along with everything else, or to a slightly more experienced staffer.
So when ISIS came along it seems as if a set of aims and aspirations was entrusted to consultants to turn into an action plan. There was no technical leader on the ILCU side and sponsorship of the project was diluted through committee. They were effectively relying on the consultants to lead the way because it was perceived as an IT project.
OSI in turn was, naturally enough, professionally competent on the technical side of things but its team is generally believed not to have grasped the nature of the credit union business in this country and to have taken its ambitious brief very literally.
So there really was no single person, structure or methodology to mediate between the vision and business objectives of the credit unions and the technology design and delivery. Despite regular group meetings and lots of paperwork, they really do not seem to have understood each other at all. On the other hand, an overall budget of €50m was agreed for ISIS at an early stage, so everyone knew the scale of what they were getting into. The €34m represents what had been collected or guaranteed from subscribing unions when the halt was called, because at that stage the overall cost estimate had risen to €86m.
The Garda Siochána PULSE project has come in for a fair amount of public flak, notably from the representatives of the rank and file and some decidedly non-technical commentators. But in many ways it is a victim of its own branding: Police Using Leading Systems Effectively may be a little contrived but PULSE is an easy tag for the public to remember and for headline and platform comment.
The trouble is, so little is known of the scale of what is involved that it is popularly taken to be a single system that seems to have taken ages to roll out and is criticised by working gardaí. In fact, PULSE is a multi-year programme of reform and change, re-engineering of a vast range of activities and processes and the development of an IT and communications infrastructure to enable it all to happen. In that context, the snappy acronym that was clearly intended to sell it actually trivialises it.
PULSE has run from an internal garda future planning process that began formally in 1992 to the effective completion of 17 different software and process applications in 2001. That was all designed and built on time at a cumulative €61m — over budget by about 50pc but through a time of spiralling IT skills costs.
Accenture (Andersen Consulting) grossed €26m in fees, but at times there were nearly 200 consultants and sub-contractors working on the set of projects. What has been happening for the last 18 months and will continue well into next year is the staged rollout and training.
Garda information and communications technology is under the direction of Chief Superintendent Eddie Cussen, who acknowledges readily that there have been operational teething problems: “One specific commercial piece of software just did not perform as required — it did not scale up effectively. This had to do with database searching, which is, of course, fundamental to most of our applications. Sometimes it is necessary to look for inexact matches — fuzzy logic — and where that came into some of the high-volume search routines it was unsatisfactorily slow.” Now that it has been replaced, Cussen insists that there are no bandwidth problems and no shortage of PCs in the 190 stations on the network.
As so often with major projects, the final loop is the individual users. There are 12,000 gardaí in the force to whom a total of 15 days’ training has to be delivered while the daily work goes on permanently. Although there is a common interface for the applications and all gardaí in recent years have had Windows/keyboard skills training, there are still 17 different applications with which they have to familiarise themselves. Because data collection and cross-referencing is now integral to every aspect of the system — and each member does his/her own inputting — every incident report involves background searches for similar occurrences/locations/people and so on. It has an immediate investigative element, as opposed to simple report form filling for later analysis, that is a new way of working for most gardaí. It seems fair to infer that the ongoing challenge is cultural change management, not the technology.
Bye bye budget: the costs of three high-profile Irish IT projects
* The ISIS project by the Irish League of Credit Unions is the undoubted star of failed Irish IT projects firmament with a final total of €34.28m down the drain
* The garda PULSE programme is operational and broadly on schedule but overran its budget by 50pc (more than €20m)
* The Irish Blood Transfusion Service budgeted €4.26m for a new integrated IT system for completion in 1999, which attracted scrutiny and a special report from the Comptroller and Auditor General last year. Final cost was €9.15m, or 115pc overrun, but the system is now fully operational and is expected to have repaid its costs in just over two years
* The Iarnród Éireann Mini-CTC signalling system project was budgeted at €17.7m in 1997. Derailed by the laying of optical fibre along the track to fulfil its contract with Esat, the replacement project now under way has an estimated total cost of €44.4m, or 150pc escalation
Blame it on what?
Common reasons for project failure from the KPMG global programme management survey 2002:
Lack of sponsor involvement
Poor scope management
Poor planning
Over-ambitious commitment to deliver in restricted timescale
Resource contention
Poor communications between IT and the business
Misalignment with strategy
Quality of code delivered by software vendor
Poor change management, compliance with process and lack of understanding
“We know it all”
