Why do some Prominent Public Sector IT Projects Fail? 5 Key Lessons Learned to Ensure Success

By Allan Watton on

Why do Public Sector IT Projects Fail? 5 Lessons to save your future projects

Sometimes, despite your best efforts and those of your vendor, IT project failure cannot be averted. Inevitable though this may be in some cases, often a project can be saved or steered away from failing to meet your expectations by following a few key lessons learnt from the experiences of others.

With the amount of media coverage dedicated to troubled public sector IT projects, it can often seem that this is a far more common occurrence than it actually is. Yes – some public sector IT projects fail, but then, in our own experience of hundreds of these projects, more fail in the private sector than the public sector. However, due to the fact that it’s rarely public money that’s at risk as a result, this attracts less coverage.

Understanding where other projects have gone wrong is critical to (a) mitigating the risk of future failures and (b) ensuring a fit for purpose solution going forward. Therefore, we have put together a number of lessons we have learned from problematic IT projects and condensed these into five key steps that can be taken to avoid finding yourself in a similar situation.

Public sector projects in the media

There are plenty of examples of high-profile public sector IT projects that have got into difficulties in recent years. In 2014 the media spotlight fell on American company Raytheon after the e-Borders project for the Home Office – to develop a system that could track passengers entering and departing the UK as part of a “joined-up, modernised, intelligence-led border control and security network” – reportedly failed to deliver on their expectations.

An independent report brought to light the fact that Raytheon had essentially built the system they had been asked to build, but the issue was that when the system had been ordered in 2007, no one on the client-side had realised that fundamental aspects of the system were going to be illegal under EU law. The report described the legal risks as “obvious”, yet, according to the report, these risks were not identified by Raytheon at the outset of the project.

Another high-profile project picked up by the media in 2014 came after the Government lost a legal battle with Fujitsu over a failed NHS IT system. The case was not heard in public, and the parties involved were even prevented from revealing where the hearings were to be held, so as to avoid “reputational damage”. Despite this attempt at secrecy, the eye-watering figures involved – with Fujitsu seeking £700m in compensation – became widely reported. The media linked the drawn-out obscurity of the Fujitsu contract with that of the Raytheon case, ultimately concluding that certain lessons had not been learnt.

Yet another widely reported case involved a Ministry of Justice back-office project that never materialised when the department realised that the Cabinet Office already had a system offering similar capability. Some lessons can be drawn from these three examples, but are they being learned and implemented?

5 vital lessons learned through experience

Experience tells us that while clear signs are being illuminated by the media and internal reports and investigations, there seems to be a gap between knowledge and implementation. Having turned around literally hundreds of ‘troubled’ major contract relationships and projects, we often find that the same or similar issues turn up time and again as the reason for their instability or failure. The following five are among the most important lessons for anyone responsible for a critical IT project to keep in mind.

  • Lesson #1: Have a knowledgeable ICF (Intelligent Client Function) team involved from the very start.

    The e-Borders contract seems to have been hindered by an absence of important technical information. It appears misunderstandings on the project were evident fairly early on. Quite whose responsibility these misunderstandings were is difficult to assess as we were not involved in this project, but questions have to be raised over the diligence and scoping processes undertaken by the provider, and to what extent it discharged its expert responsibilities. Whether the contractual arrangements were designed to drive ‘enabling behaviours’ between the parties as opposed to penal obligations in the event something went wrong, is another point that should warrant investigation if the right lessons are to be identified and implemented.

    The termination of this contract, and its accompanying financial and reputational costs, do underline the importance of building a well-resourced and highly-skilled Intelligent Client Function team. It’s a tiny insurance cost and in most cases, if structured correctly, provides a return on investment of between three to eight times.

  • Lesson #2: Share your learnings, both positive and negative, to improve the prospects of future projects and ensure past mistakes are not repeated.

    Despite expectations on them to the contrary, it is common for there to be a reluctance to lament failures with a full and open evaluation of what went wrong in the public sector; something that’s vital if past mistakes are to be learned from.

    Conservative party MP Richard Bacon has reportedly stressed that failed public sector IT projects are unique in that the involved parties are often unwilling to openly discuss problematic issues. He cites the admirable spirit of openness within air accident investigations, reportedly stating that when it comes to IT “we never learn from our mistakes, because there is a learning curve… when things go wrong with IT the response is to keep quiet”.

    Clarity and transparency is vitally important, to try to reduce the opportunity of miscommunication that reporters implied occurred between the Ministry of Justice and the Cabinet Office. Ultimately, a costly terminated contract can be far more damaging than opening a dialogue to discover how and why certain mistakes have been made.

  • Lesson #3: Take the necessary time to consider the intricacies of a system, and who is best suited for the contract. Don’t always rely upon the same old faces.

    One of the biggest charges the media levelled at the Labour Government regarding the failure of the Raytheon and Fujitsu contracts was their seemingly ‘rushed’ nature.

    Experts have argued that these contracts were destined to fail as they were signed ‘in an enormous hurry’. Tom Gash, the Director of research at The Institute for Government has noted a trend within public sector contracting which he has termed as “doing a big bang”. In fairness, the Government has been trying for a couple of years to avoid ‘big bang’ projects. New governance processes for the approvals of projects have been introduced which the Cabinet Office believes will significantly reduce future projects becoming misaligned to the business need.

    Prior to this new governance, however, a catalogue of expensive contractual failures all shared a tendency towards being announced as high-profile technical fixes, such as a BBC video archival system, or the aforementioned Ministry of Justice project, that don’t quite materialise due to the Government ‘announcing them all at once.’ Such announcements may look good politically, but hurrying through any large-scale IT contract increases the risk of damaging long-term repercussions. Again, the new governance processes should avoid this for the future.

    There is a general perception that in the past, these ‘big bang’ rushed contracts often tended to rely upon existing relationships, yet just because a company has been around for some time does not mean that they are the best match for a project. Most readers of these articles know that it is important to take the time to identify new, potentially more vibrant companies who can bring new talent to the table, and who might be better suited to achieving the outcomes you set for them.

  • Lesson #4: Understand that building a complex IT system isn’t akin to building a road or a school.

    The previously ‘rushed’ nature of many public sector IT projects alludes to an occasionally problematic general attitude towards IT by some senior executives. In our own experience, some senior executives tend to regard major IT projects as a ‘technical’ project, rather than as a business change initiative. This can lead to a lack of senior executive engagement which in turn, means a lack of resources and strategic thinking that these projects so desperately need; particularly during the ‘design’ phase and when roadblocks in progressing the project arise.

    Successful software development and IT projects are not the same as building a road, although some of the key principles are not dissimilar. An appreciation of the complexity of these systems, and making allowances for flexibility (breaking out the things a system should do and commissioning them one by one), can help to protect your project from the possibility of costly contract terminations. It is vital that mission-critical systems are indeed perceived as ‘critical’ by senior management in order to get the buy-in they need to succeed. This is outlined in greater detail in our ‘Problematic IT Project’ guide.

  • Lesson #5: Clear governance – an emphasis on understanding everyone’s roles and responsibilities throughout a project.

    The nature of large-scale public sector IT projects is that they tend to be complex and take quite some time to complete. This means that there is likely to be a certain amount of natural overseer ‘churn’ occurring between concept and implementation, where ministers and officials move on, which could risk the blurring of responsibility and, therefore, accountability should things start to go wrong. Again, involving an ICF team is crucial to avoid muddying the process and to maintain the trust you have built with a vendor. It is important that the Government breaks down programmes into projects that can be delivered before the officials responsible for them move on.

  • Conclusion

    Many public sector IT projects run smoothly and offer up their lessons for others to learn from, but some could benefit from their example. With some major IT projects running over budget or failing to achieve desired outcomes, it’s important to note that that a few key considerations and changes could make a significant difference to this outcome.

    According to industry statistics, a number of IT projects across the public and private spectrum today will have the propensity to fail, and similar lessons could well determine their prospects. Poor governance structures must continue to be addressed, it is important to take the proper care to not hurry contracts, to ensure that a knowledgeable ICF team has been consulted and maintains the authority to act in the best interests of the project, and for all stakeholders to appreciate the difficulties and complexities surrounding large-scale IT projects.

    To gain a greater understanding of these issues, and advice on how to maximise the chances of success for your project, download a free copy of our comprehensive 43-page eBook: 9 steps to save a mission critical IT project.

     

    Free Ebook Download: Problematic IT Project