“Failure is simply the opportunity to begin again, this time more intelligently.”

Henry Ford

Complex ICT projects regularly involve high degrees of risk, are frequently subject to substantial cost and time overruns and, importantly, often fail to deliver promised benefits.  Failed ICT projects in the private sector, particularly in Australia, rarely end in litigation and are rarely subject to public scrutiny. Failed public sector projects, on the other hand, are sometimes subject to auditor-general or similar types of investigations, which provide valuable insights into what went wrong.

Articles about failed IT projects almost inevitably seem to approach the subject with an element of mirth and scare-mongering.  We hope to avoid doing so with this article, but rather to focus on the principle that the most important lessons are often learned from mistakes.  Investigations into failed public sector projects provides a rare opportunity to learn from the experience of others, to foresee the likely traps and pitfalls, and hopefully to approach your own complex ICT projects with a better knowledge and insight of what may lie ahead.

In preparing this article, we analysed publicly available reports into 17 failed ICT projects in the public sector, largely in Australia but also in the UK and the US.   These reports, based on ICT projects as varied as implementing a new public transport ticketing system to implementing a new patient administration system, demonstrate that there are a number of consistent reasons why such projects fail.    In no particular order of seriousness or prevalence, the most common factors for such failure are:

  • failing to fully consider the solution required by not engaging the people who will actually use the solution;
  • underestimation of the complexity and cost of the project and, consequently, overly optimistic expectations and milestones;
  • poorly constructed or non-existent initial business cases;
  • inadequate staff expertise from both the vendor in implementing the solution, and the purchaser in managing the solution;
  • an unusually high appetite for risk, often involving an untested solution;
  • poor contract design, namely a number of fundamental inadequacies and limited customer flexibility, and/or poorly negotiated variations;
  • poor vendor selection, often the least experienced and lowest cost vendor;
  • poor project management and governance structures; and
  • inadequate contract administration and performance monitoring

The following case studies provide some salient examples of how these factors have caused large-scale ICT projects to fail and the lessons a customer can learn in order to avoid the same outcome.

Case study 1: myki

myki involved the Victorian Transport Ticketing Authority (TTA) replacing Melbourne’s existing ticketing system with a smartcard system which enabled passengers to “touch on and off” all trams, trains and buses throughout the metropolitan transport grid.  Initial total cost estimates of $741.9 million were revised upwards, with the project expected to be at least $350 million over budget and some four years behind schedule.1

According to the Ombudsman’s report, the project suffered from serious issues from the beginning as the assembled TTA members lacked sufficient skills to deal with a significant ICT project and had no detailed knowledge of the transport ticketing environment.  This in turn led to selection of a high risk unproven “open architecture” solution2 by an untested vendor.  The project also suffered from unnecessary contract complexities as the TTA and the selected vendor negotiated an outcomes based contract which included all documentation exchanged between the parties throughout the tender process.  According to the Ombudsman, this meant the contract lacked specificity and caused misunderstandings about the precedence of documents.  In turn, there was often confusion whether some functional requirements were within or outside the scope of contractual arrangements.3

Case study 2: Link - Victoria Police

In 2005 the Victoria Police commenced the Link project, which aimed to replace the existing 13 year old system used to record crime incidents and personal information within Victoria Police’s database.  In 2011, owing to a number of serious failings which hampered the project, Link was suspended until 2014-2015 and its cost estimates increased by $127.7 million.4

In a similar manner to Myki, Link got off on the wrong foot as its initial business case was pitched at meeting government funding allocations and therefore failed to adequately identify the overall cost of the project as well as the number and complexity of interfaces required by the new system.5  A key shortcoming was Victoria Police’s failure to appoint a single experienced project manager.  Instead, project management responsibilities were split between 2 people – one of whom had never managed a large, complex ICT-enabled project before.6  This in turn led to a number of early warning signs of cost blowouts being missed – for example cost concerns were raised and ignored in both 2006 and 2008 notwithstanding that the Link budget was half that of a similar solution used by Queensland Police.7

Link was further hampered by the project team insisting on a “like-for-like” replacement of the 13 year old system, rather than acquiring a new system which addressed the current and future needs of the police who would use it.  The Auditor General noted that the “like-for-like” strategy was problematic as it resulted in the excessive customisation of the commercial off-the-shelf product which in turn eroded its inherent benefits and further increased its costs.8

Case study 3: FiReControl

The FiReControl project, managed by the Department of Communities and Local Government (Department) in England, aimed to streamline the coordination of fire and rescue services.  England has 46 local fire and rescue authorities, each of which has access to a local control room which is used to handle emergency calls from the public and manages incidents.  The FiReControl project was designed to improve these local arrangements by providing purpose built secure facilities networked across England so that each fire and rescue authority could be used to back up others by having access to the same information and by having the ability to manage and deploy resources on a local, regional and national level.9  In December 2010, after having spent £245 million, the Department decided to cancel the FiReControl project as it could not be delivered within an acceptable timeframe for an acceptable extended budget.10

A number of issues plagued the FiReControl project, chief among them an underestimation of complexity in designing the solution and unrealistic estimates of project costs.  For example, in order to accommodate the operational needs of fire and rescue services, key components of the solution required significant modification.  However, the Department delegated much responsibility to the contractor instead of taking ownership in developing the IT system necessary to achieve the required standardisation.11  Project cost estimates were similarly flawed, being based on unrealistic assumptions which involved omitting the costs of meeting local and regional implementation and of equipment installation.12  The contract itself was also inflexibly designed whereby the contract impeded the resolution of issues and the termination of the project at an earlier stage.  For instance, a lack of interim milestones undermined the Department’s ability to hold the vendor to account for delivery of the solution.13

Case study 4: Western Australia Department of Health's replacement Patient Administration System

Since 2000 the Western Australia Department of Health (“Health”) has attempted to replace its two Patient Administration Systems (“PAS”) with a single integrated state-wide solution.  A PAS is an electronic system that records and provides access to personal information about patients such as their name, address and medical history.  Accordingly, an effective PAS is one of the most critical parts in a public health system as it can directly impact patient care.  A replacement single PAS was initially planned by 2009 at an estimated cost of $52 million.14  This has since been revised to $115.4 million with the new PAS unlikely to be operational in metropolitan areas until at least 2014 and 2018 in regional areas.15

According to the Auditor General, Health’s governance arrangements were unstable and poorly defined as it was still identifying its business needs despite having agreed on a replacement solution.16  The contractual arrangements behind the PAS were also inflexible and exposed the State to increased risk.  For example, Health:

  • contracted out of standard clauses without documenting its reasons;17
  • failed to test the market before obtaining a licence for a new PAS in 2009; and
  • as of October 2010, did not have any formal contract in place for PAS support and maintenance or its new licence.18

Further, Health inadequately monitored contract delivery and performance as its managers did not have the requisite IT expertise or sufficient access to the contracts they were implementing.  Some contracts lacked performance criteria however, where there were criteria, Health did not sufficiently monitor performance against them.19

Contractual mechanisms to help mitigate these risks

In a previous paper on successful ICT projects, available here, we noted that a strong focus on implementing simple, repeatable steps in a procurement process can help improve the chances of successful project delivery, regardless of project size.  The same is largely true of the lessons learnt from the failed IT projects we reviewed, including such simple things as ensuring:

  • the contract has in built flexibility mechanisms such as interim milestones, contract review points and appropriate termination mechanisms;
  • governance structures are clearly defined, and importantly that the governance structure in the contract reflects the intended project practice (quite often it fails to do so);
  • cost and time estimates are based on realistic assumptions;
  • contract performance is diligently monitored; and
  • personnel and external advisers involved in planning, negotiating and implementing the solution have appropriate expertise.

In addition, depending on the project it might be worth considering putting in place alternative mechanisms to assist in rectifying a failing IT project, including ensuring:

  • there are strong knowledge-management obligations, to assist in knowledge transfer to your organisation or another vendor;
  • termination for convenience rights are exercisable in part, so that components of the project can be brought back in-house or given to another vendor, accompanied by sufficient pricing transparency and flexibility to enable this to occur;
  • including an option to licence software source code;
  • the vendor can be required to deploy additional global personnel (deep subject matter experts) to the project if it becomes troubled;
  • staged step-in rights allow you to take escalating actions, such as appointing your own manager to shadow or oversee the vendor’s work;
  • you have the right to second vendor personnel into your organisation; and
  • any non-solicitation provisions cease to apply if the project becomes troubled.

If you would like to read more, a summary of the 17 failed ICT projects we reviewed is available here.