Education, English

Why Public Sector ICT Projects Fail

Most often, complex projects generally involve a high level of risk; they are part and parcel of substantial time and cost overruns, and most crucially, they may fail to provide the guaranteed benefits. Therefore, failed ICT projects in both private and public sectors infrequently end in litigation and are seldom subjected to full public examination. Even though there are valuable insights concentrated on investigating projects, the public sector is best suited to these observations. However, discussions of failed ICT projects almost inevitably approach the matter with a crucial element of scale and mirth-mongering. Thus, people hope to focus on the standards by which essential lessons can be learned from mistaken activities (Gole and Shinsky, 2013). Apparently, investigations into failed public-sector projects provide opportunities to learn from the experience of others, predict pitfalls and traps, and mindfully approach one’s own ICT project with added knowledge and insight into what the tasks ahead may be.

Indeed, when writing this study, I analyzed publicly available reports in which IT projects failed.

Common Causes of Public Sector ICT Failure

Therefore, the projects are based on IT projects involving the introduction of a new public ticketing system. In no specific order of prevalence or significance, the various factors of failure include:

– Insufficient contract performance and administration monitoring.
– Underestimation of project cost and complexity, which consequently tends to create overly optimistic milestones and expectations.
– Nonexistence or poorly constructed initial business cases.
– Unusually high-risk appetite, mostly involving untested solutions.
– Insufficient employees and expertise in both the vendor implementing the solution and the purchaser administering it.
– Poor governance and project management structures.
– Failure to fully consider the required solution by not involving the people required to use it.
– Poor project contracts involving various fundamental inadequacies and inflexibility for customers or poorly discussed variations.

The FireControl Project

Consequently, focusing on the FireControl project, which was undertaken by the Department for Communities and Local Government in England, it was established to rationalize fire coordination and rescue services (Gole and Shinsky, 2013). However, England encompasses 46 rescue and local fire authorities, each of which has access to a local control room used for handling emergency cases from the community and managing incidents. The FireControl project was, therefore, structured to help improve the various local arrangements by providing purpose-built, secure, networked facilities across England. Consequently, each rescue and fire authority would probably be used to back up others by accessing the same information and by being able to manage and deploy resources at local, regional, and national levels. By the end of 2010, having spent more than £245 million, the department chose to cancel the FireControl project after determining that it could not be delivered within the specified time frame and extended budget (impact, 2017).

Of the various issues that plagued the FireControl project, the most serious among them were the underestimation of the complexity of the solution design and unrealistic estimates of the project cost. However, in order to accommodate operational needs for both fire and rescue services, major components of the solution required significant modification. Indeed, the department delegated responsibility to the contractor rather than taking ownership of developing the ICT system required to achieve the necessary standardization. The project cost estimate was also seriously flawed and was based on unrealistic assumptions that omitted various costs associated with both local and regional implementation and equipment installation. The contract itself had an inflexible design that impeded resolution of issues and termination of the project at a very early stage. Ideally, the lack of proper milestones undermined the department’s ability to hold the vendor accountable for each stage of delivery.

Nevertheless, this is one of the most tragic cases that committees have experienced over many years. Ideally, FireControl was a visionary project with broad goals of improving national efficiency, resilience, and technology by replacing the control-room functions of the 46 local fire and rescue services. The project was flawed from the outset because the Department for Communities and Local Government tried, without adequate mandatory powers, to impose a single nationwide approach on locally accountable fire and rescue services that were reluctant to change how they operated. However, despite involving the services in an effort to convince them of the project’s merits, the department set them aside from discussions on the design of the regional control centers.

Therefore, the proposed IT solutions arising from these discussions would have left local facilities with probable long-term costs and outstanding liabilities to which they had not agreed. The department, however, launched the project too quickly, driven by its wider objective of ensuring a better and enhanced national response to disasters such as rail crashes, terror attacks, or floods. The department also aimed to motivate the embedding of local administration in Britain. However, it proceeded without using basic project approval checks and balances, making decisions before the business case, procurement plan, or project plans were fully developed and tested within the Fire Services. The outcomes were, therefore, hugely unrealistic cost predictions, naïve over-optimism about costs and savings, overconfidence in the desirability of the ICT solution, and inadequate mitigation and appreciation of the risks. The department therefore demonstrated weak judgment by approving the project and failed to provide suitable checks and tests.

The basic structure of project organization continued to be vague as the project moved forward. Hence, the new fire-control centers were structured and completed while there was a substantial delay in awarding the IT contract, leaving aside the need to develop the IT infrastructure. Consultants concluded that only half of the organization team was effectively managed. The project therefore continued under governance arrangements that lacked clarity about roles and responsibilities. There was a huge turnover in the senior managerial team, although no one was held accountable for the failure. The committee, however, suggested that this was too significant a failure of leadership for no individual to be held accountable for the disappointment and excess costs associated with the project.

However, the department awarded the ICT contract to a company without direct experience in providing the required services and relied heavily on subcontractors over whom the department had little visibility or control. The contract was, therefore, poorly designed and lacked proper milestones that could have assisted the department in holding the contractor accountable for delays in the project. This was made worse by the department’s weak approach to contract supervision and its failure to ensure that the contractor followed the agreed strategy.

As a result, of the project cancellation, the department reserved £84.8 million to achieve the original project’s objectives of efficiency, advanced flexibility, and interoperability. These methods, therefore, relied on voluntary cooperation among individual services and raised concerns that the department would not be able to ensure clear responsibility for responding to a large-scale event or demonstrate that the £84.8 million delivered value for money. The response to significant incidents was, therefore, a major concern that needed to be discussed within a national framework in subsequent years and subjected to review as progress was made (society, 2015).

Management and Governance Failures

However, the FireControl project failed partly due to inadequate involvement from the managerial team.

During the entire process, management was somehow mixed up, and some individuals never understood the management structure properly. Because of this, the technical team took over and made the major decisions. This gave the technical team the freedom to make its own suggestions and pursue objectives that were sometimes contradictory to the main objective of the project setup (News, 2011).

Improper Planning

Technicians were often the first people to act, which is why they tended to jump into things and get started immediately. Multiple explanations for this attitude were absent, and as a result, improper and inadequate planning before the project contributed to its failure. The project proceeded without a clear understanding of its scope and expected outcomes. Due to unclear targets and mismanagement, the team acted haphazardly. This was reflected in poor performance, inefficient resource utilization, uneven workloads for the team, incorrect cost estimates, inaccurate time estimates, inaccessibility of responses at critical times, and confusion regarding responsibilities and roles.

Technology Selection

Most often, wise selection of technology helps to prevent a project’s technical failure. However, in this case, not everything was appropriate, as the technology selected was based mainly on what was trendy and favored by management. This could lead to wrong interpretation due to incompatibility between the programs to be used and the actual implementation of the project. Hence, the project failed partly because of hindrances created by various disagreements concerning the primary objective.

Failure in Managing Scope Creep

To deliver the required outputs, there is an adequate need to maintain focus. In this case, the department engaged in some contradictions, making everything difficult to understand and preventing the project from running smoothly. Therefore, it did not meet the requirements needed to implement the ICT functionality efficiently (society, 2015). Consequently, the project never ran according to the agreed FireControl production plan, marking a significant failure. The ideas were inadequately established, and room for improvement was not properly administered when discussing completion of the project. The results profoundly marked the downfall of the FireControl project in its mission to convince the respective stakeholders.

Poor Communication

Communication plays a significant role in establishing a good network for all relevant stakeholders. But in the case of the FireControl project, team members had inadequate and unreliable communication. The leadership was supposed to be the key controller by ensuring that all members of the team communicated effectively. However, some challenges were experienced, resulting in common mistakes that were never rectified efficiently and thus leading to a loss of motivation needed for the project. Lack of communication led to the sidelining of junior resources, hence undermining the overall project.

Overly Optimistic Project Schedule

The managerial team was highly spirited and therefore had high expectations. On the ground, however, this was not the case. When it came to implementation, the task was too difficult for junior staff to follow the structured pathways for the FireControl center services and controls. The project schedule, therefore, was massive compared with the time frame in which it was structured, creating immense pressure from above on the team and resulting in resentment among team members responsible for implementation. The team members tried to put in more effort, but some technical challenges hindered the process.

The FireControl project, therefore, needed, firstly, local expertise. By this, the department should have looked for personnel with adequate skills as required by the project. Recruitment and training would, therefore, have been greater objectives designed to enhance expertise and develop workers who were willing and able to support the organization. However, the availability and development of these skills would have provided project managers with greater opportunities to build loyalty in return (News, 2011). Ideally, a small investment of time and training could add value and success beyond the direct project itself.

Secondly, flexibility was essential, as some preparations were critical to the development of the project. Hence, the team was supposed to have stable patience, a good sense of humor, and flexibility as keys to calming situations that led to contradictions. By observing such aspects, the project could have been successful and efficient in running the FireControl project for the Department for Communities and Local Government in England.

References

Gole, T. and Shinsky, G. (2013). Learning from failed ICT projects | Lexology. [online] Lexology.com. Available at: https://www.lexology.com/library/detail.aspx?g=cca9ae3a-2fa7-4550-9445-39bc32a4c3ff [Accessed 13 Mar. 2018].
News, B. (2011). Failed 999 projects ‘wasted £469m’. [online] BBC News. Available at: https://www.bbc.com/news/uk-14974552 [Accessed 13 Mar. 2018].
Society, c. (2015). The failure of the FiReControl project – National Audit Office (NAO). [online] National Audit Office. Available at: https://www.nao.org.uk/report/the-failure-of-the-firecontrol-project/ [Accessed 13 Mar. 2018].

Editorial Staff Image

Academic Master Education Team is a group of academic editors and subject specialists responsible for producing structured, research-backed essays across multiple disciplines. Each article is developed following Academic Master’s Editorial Policy and supported by credible academic references. The team ensures clarity, citation accuracy, and adherence to ethical academic writing standards

Content reviewed under Academic Master Editorial Policy.

SEARCH

WHY US?
Calculator 1

Calculate Your Order




Standard price

$310

SAVE ON YOUR FIRST ORDER!

$263.5

YOU MAY ALSO LIKE