In our last article ‘4 Lessons from successful IT megaprojects’,we reviewed a number of the country’s largest and most renowned recent IT megaproject success stories in the context of what each could teach us from their struggles and accomplishments. This article is from the other side of the coin – a look at the valuable lessons we can learn from megaprojects that failed to achieve their objectives.
Unfortunately, there are quite a few of these to choose from, but while those we have chosen may not have achieved the outcomes expected of them, they can at least offer us guidance that could protect countless future projects from treading similar ill-fated paths.
Surrey Police – Challenges with the £15m crime and case logging and tracking system
In 2009, the Surrey Integrated Reporting Enterprise Network (SIREN) was commissioned, then just four years later it was discontinued because, in the words of Surrey PCC Kevin Hurley, it no longer was the “best long-term option for the force and the public”. In this time just under £15m had been spent on training, hardware and software, staff costs and consultancy, and yet very little is reported to be left to show for all this investment. While other forces had acceptable systems that could have been adapted to suit the needs of Surrey Police (as implied by ‘Termination of the SIREN ICT project: Q&A’ on the Surrey Police’s own website) they chose to develop one for themselves. It was an ambitious project, and on occasion, such grand plans can offer big rewards. Unfortunately, that was not to be the case here, as auditors Grant Thornton later reported it “was beyond the in-house capabilities and experience” of Surrey Police.
Lesson #1: Due diligence is king
At the inception of any project it is of vital importance that you carry out as thorough a process of due diligence as is possible, for without the information you gather at this stage you cannot hope to determine the viability of your project and the best course to its successful conclusion. Fundamental to this due diligence process is assessing any existing solutions and whether they can be adapted to meet your needs. This should, however, not be a one-off process. Periodically throughout the project it would make a great deal of sense to review current outcome expectations against existing solutions, so that if at any point it is discovered that the latter may be a better fit and the project should be ended, any further investment of funds can be minimised.
FiReControl – £469m spent over seven years without planned outcomes being achieved
The concept of economising through replacing 46 fire service control centres with nine new facilities was noble enough, but after seven years this project had eaten its way through its £469m budget and none of the new facilities were opened. Unfortunately, they continued to cost the taxpayer years after the scheme had been discontinued as ill-considered lease agreements still required the payment of rent.
In a ministerial statement Brandon Lewis said: “FiReControl was a poorly conceived and badly delivered top-down programme of the last administration to create regional fire control rooms. It was terminated after running repeatedly over-budget and behind schedule, and to avoid further taxpayers’ money being wasted.” He went on to quote the resulting NAO report which noted: “The department rushed the start of the project, failing to follow proper procedures. Ineffective checks and balances during initiation and early stages meant the department committed itself to the project on the basis of broad-brush and inaccurate estimates of costs and benefits and an unrealistic delivery timetable, and agreed an inadequate contract with its IT supplier. The department under-appreciated the project’s complexity, and then mismanaged the IT contractor’s performance and delivery.” And this is the essence of our next lesson.
Lesson #2: Have a clear metrics-driven business case for every project
A well-considered and quantified outcome expectation for your project will support you in identifying whether it is achieving its stated goals. And clear KPIs, created and sense checked by all stakeholders, are the only way you will be able to know where you currently stand within your project schedule as you progress. A metrics-driven business case will help you to develop a forward-looking view of the project through its various milestones so that strategic partners and other impacted parties can review this plan and recommend any adaptations required to optimise outcomes.
Rural Payments Agency (RPA) – a farm subsidies IT system which fell significantly short of end user needs.
In seeking to create a new IT system that would make it easier for British farmers to receive the 100,000 plus subsidies they were due from the Common Agricultural Policy and, in doing so, minimise the risk of the UK’s exposure for late payment fines, the RPA – an agency of Defra – created a system that seemed unfit for purpose. Technical problems, numerous relaunches and changes of direction finally produced the Rural Payment System which, according to the National Audit Office (NAO), was all too often inaccessible by farmers because of their poor signal locations and the system’s high bandwidth demands.
The NAO report into the situation said Defra had “failed to prevent counterproductive behaviours by senior leaders” and highlighted what it said were “deep rifts between programme leaders at many stages of the programme’s history”.
Lesson #3: Consult all interested parties to ensure what you think they want is
actually what they need
The reported mismatch between a cumbersome new system and the low signal rural location of its users appears to be a fundamental issue and is a clear example of our third lesson: to thoroughly consult all interested parties. Consultation with all those who could contribute vital on-the-ground insights, such as the end users of a new IT system, will provide important information for the development team, including the answer to the question ‘are we building what we think they need or what they actually need?’. Early consultation and open communication lines to all stakeholders throughout the build and implementation of your new IT system is a vital part of best practice due diligence.
Universal Credit – a condensed welfare programme that suffered from delays, overspends and technical failures.
When you want a clearer picture of each individual’s right to welfare in the UK you’ll need the many disparate systems that tell you about their financial position all talking to one another. Universal Credit was the project to combine the workings of 30 welfare programmes, covering six existing benefits, into a single overarching system. However, a few years later it was reported that £40.1m of the funds invested into the system were to be written off with a further £90m of software likely to be written down over the next five years. The delays, overspend and technical failures were, among other things, blamed on culture, with the NAO reporting a “Good news culture and fortress mentality identified through third-party reviews”, meaning a belief that issues were not being addressed as they should have been. The NAO did praise those in charge of the project for their handling of issues that arose, but also suggested that they should have had more insight into what could go wrong in the first place.
Lesson #4: Create the right environment for success
The clarity of your overall view (or lack thereof) on any project will help or hinder your ability to steer it on a course to success. If your team are not pulling in the same direction, if individuals or teams are allowed to follow personal agendas, if fear or pride ensures that information does not flow upstream as it should, then your project may encounter difficulties, with project members unaware of emerging challenges. Create a culture of trust and mutual respect throughout your in-house teams and strategic partners. You want to know when things go right, as well as where things are going wrong. One way to improve your overarching view is to create a well-resourced and skilled intelligent client function (ICF) team from the outset. Their role is to understand the needs of the project and the individuals involved in making it happen, to be your early warning system should things run into trouble, and to offer a future-thinking view based on empirical evidence that could mitigate risks that are yet to reveal themselves.
A final word on failed IT megaprojects
IT megaprojects involve many people and organisations, all with their part to play in the success or failure of your venture with them. Insight, clarity, and inclusionary processes are all important to mitigate risk. While the SIREN, FiReControl, RPS and Universal Credit projects may not have achieved their initial goals, they can offer up some vital lessons that we can all implement in our projects to assure they have a greater chance of achieving their objectives.
