Fire Control Project Overview - Essay Example

?Fire Control Project Overview The FiReControl Project was an initiative to develop a network consisting of 9(nine) purpose-built Regional Control Centers (RCCs) with the task to handle all emergency calls being made to FRSs with the use of just a single operating system which would replace the 46 existing fire control rooms( Great 2009, p. 29) This project arose from a report which the government commissioned having been raised by the management, engineering as well as development consultancy which was published in April 2000. The conclusion from the report was that maximum efficiency could be attained if the number of control rooms could be reduced from current 46 (as at that time) to only 9 regional control rooms. The objective of the project being to ensure community safety by providing strategic framework for the Fire and Rescue services (FRSs) as well as other agencies which would prevent and respond to emergencies as they arose. The benefits that would accrue from the project were increased resilience. In this case by using the resilient networked technology, staff in any RCC would be able to answer calls within any part of the country. Secondly, the project would integrate all services by use of new risk management tools which had the ability to deploy specialist equipments. This would necessitate introduction of a common call handling, process mobilization, technology and training which would guarantee consistency across various regions. The communication system would also be changed to be data based rather that voice which would be readily accessible through the MDTs. This would hence ensure greater fire and rescue services capabilities (Great 2010, p.30). Extent of Failure Originally, each FRS had its own local control room charged with the responsibility of handling its own emergencies. All the 46 control rooms were independent with each using different levels of technology, network capacities and also their own back-up arrangements. The challenge faced by the control rooms was the increased number of calls and levels that exceeded the local control room. This made the calls be transferred to a different FRS or police control room. By using the police control room, information would then be sent back to the local control room using telephone, radio or fax machine. Due to the fact that different control rooms employed different technology levels and variable quality, this made the transfer process difficult for the FRSs to effectively back each other up. This resulted to the local control rooms being flooded hence being hard to cope using the current technology to handle the high volume of calls which then resulted in long queues or even lost calls. This was another example of a Government IT project in which it was absorbing increasing resources but never achieving the objectives initially set. The essential checks and balances done at the early stages of the project were ineffective. This was due to the fact that approval of the project was done based on unrealistic cost estimates as well as under-appreciation of the IT complexity that was to be involved. This made the project be implemented in a hurry with poor management. The Communities and Local Government Select Committee after closely examining the project hope that the project should go live by mid-2011 if there is an agreement on a viable project plan. The realization of the above has been put on substantial risk as a result of the following. Reasons for failure Project Environment There are several issues that ultimately led to the downfall of the said project which if they had been handled before would have made the project a complete success and be completed on time. Failure by the Department to sufficiently incentivize Fire and Rescue Services The Fire and Rescue authorities were under no legal obligation to use the regional control centers once completed. Despite this, the department failed in its mandate by not communicating the benefits to be accrued by transferring to the regional structure. The Department charged with the Fire and Rescue Service at the commencement of the project failed to elicit why they supported the Fire Control. These greatly led to lack of support and they also made doubts to be raised regarding the projects ability to meet the Departments objectives. Project Definition Despite the early stages of the project having progressed rapidly, key stages of the process got out of sequence and the project got approval before the project plan and the business case could be finalized. Its only later after the project had been approved did a review by the Office of Government found out that the project was introducing new risks towards the delivery of it as well as escalating those already identified. The early assumptions by the Departments on the project a cost of ? 120 million proved over-optimistic yet the same amount was an underestimation of the projects cost. The same department overestimated the efficiencies that would be realized by the local Fire and Rescue Authorities by projecting 28% cost reduction of running the control rooms. Project planning and control Failure by Department to appreciate complexity of the project: The Department underestimated the project complexity by providing a system that satisfied the requirements of 46 autonomous FRSs. The procurement process for supply of the IT system took over two years to complete due to the nature of its complexity. They assumed the development would have been a straightforward with just the integration of the already customized components. Failure to adequately plan for the project as a whole The procurement of the regional control centers and the supporting IT system commenced even before completion of the business case. The procurement of the IT system took two years to complete. They prioritized procurement of the regional control centers over that of the IT system. Due to misalignment in delivery timetables, this made the first two regional control centers be delivered in June 2007; three months after the IT contract had been awarded and some 18 months before the equipment which they would house would be ready. Ineffective checks and balances This was another example of a Government IT project in which it was absorbing increasing resources but never achieving the objectives initially set. The essential checks and balances done at the early stages of the project were ineffective. This was due to the fact that approval of the project was done based on unrealistic cost estimates as well as under-appreciation of the IT complexity that was to be involved. This made the project be implemented in a hurry with poor management. The Communities and Local Government Select Committee after closely examining the project hope that the project should go live by mid-2011 if there is an agreement on a viable project plan. The realization of the above has been put on substantial risk as a result of the following. The initial agreement that was there with the IT contractor was ill-suited to the nature of the project and the consultation with the end-users was insufficient. Mishandling of major stakeholders and contractual partner Further, the relationship with the major stakeholders and contractual partners has been mishandled. This has been attributed by lack of openness, collaboration and explanation by the DCLG which has made many Fire and Rescue Authorities have profound reservations as to whether the new regional system will actually deliver a more efficient and safer service (Britain 2011). Similarly, the skyrocketing costs and the severe delays are likely to leave several Fire and Rescue Authorities managing their migration to a new system at a time which they should be preparing for high-profile safety concerns being presented by the Olympic Games in 2012. The Government has also been condemned by the Local Government Select Committee for its refusal to allow it the sight of independent management various reviews for the project even if it would be done in confidence. The conclusion of the committee is that the excessive cost to be incurred for abandoning the project (?8 million) is more than the cost that can be incurred to complete the entire project. The committee, Local Government Select Committee ,therefore agreed that the project can still proceed to completion so long as the following measures have been put in place. The Department in charge shall organize alternatives and also provide assurances that the project represents the best viable option for the future of Fire and Rescue services. In addition, the various shortcomings in the management of the project should be addressed fully. The Department in turn should do consultation fully with the FRS staff and the concerned professionals in defining the end-user requirements. last but not least, the department should provide assurance that the safety as well as the security of the Olympic games shall not be compromised by the final roll-out of the new Regional control Centers. The success of the said FiReControl project which cost the tax payers nearly half a million pounds ended up as a complete failure. Right from the beginning is when the problems befell the project. The management failed to award the contract for the implementation of the National IT system linking the control centers until three years later after the project had already begun. More so, the contract was itself poorly designed and the company that got the contract was inexperienced. This is one area the management should have been cautious on. Government’s failure to instill co-ordination The Government also failed to instill co-ordination between the Firelink and FiReControl. During the inception of the FiReControl project the Government was running the FiRelink project in procuring a new wide area radio communications systems for the FRSs in England, Scotland and Wales. Despite accepting the synergies between the projects and the achievement which the Firelink solution would have made to the FiReControl project, the Government did not integrate the two to achieve the efficiencies in terms of staff and consultancy costs. Failure to align the requirements resulted in silo working duplication as well as inefficiencies. Management failure Management failure was a main concern to delay the launching of the project which was rather done too quickly. This was rather driven by the wider objective of ensuring a better coordinated national response to the national disasters i.e. terrorist attacks, rail crashes or floods. Their desire to also encourage and embed a regional government in whole of England was not realized due to the departments’ failure to apply the basic project approval checks and balances. They made decisions long before the business case; project plans or procurement strategy had been fully developed and tested by the Fire Services. The responsibility of the management failed to be felt right from the beginning. The management was made up of over half being consultants who didn’t take part in the management roles. There was lack of clear clarity over the particular roles and responsibilities. The Department would also have awarded the contract to a more experienced IT company which had more direct experience in supply of emergency services. The given company that finally got the contract relied on sub-contractors. this finally made the contract be poorly designed and lacking the early milestones that would have given the Department powers to hold the contractor accountable for delays in project completion (Britain 2009). After the cancellation of the project, the management has proposed the following. The department has earmarked ?84.8 million to achieve the project’s initial objectives. The funds will further help in improving resilience, efficiency and interoperability within the FRSs. What is still not clear is whether the amount earmarked will provide value for money. To sum the above grievances which could have been avoided, the following was what would have ensured the project’s success. This includes better project governance, better stakeholder management and better third party contractor management. After careful examination of the above FiReControl project, a conclusion can be drawn on the factors that could have attributed to the projects failure and which are the same factors that contribute to a projects failure and success. Any computer project is deemed to fail whenever it fails to achieve these criteria for success. It’s only a few projects that are able to achieve all the above three criteria methods. Outlined below are some of the most vital factors that can be attributed to be the most important reasons for failure. Factors affecting Project environment Lack of User Involvement Exclusion of users during system development has contributed to mass project failure. This is because by users not feeling committed to the system, they in turn become hostile towards the system. For any project success the senior management needs to involve the users’ right from the start and henceforth throughout the system development until completion (Great 2009). Long or Unrealistic Time scales Most of the computer projects have long timescales while others have unrealistic timescales. The key recommendation is usually that projects timescales should be shortened which thus means that large projects ought to be split into separate projects. Although there are challenges attributed to this approach, the long-term benefits of doing so are worthy. The management instills more importance on fast delivery of the project thus making then set unrealistic timescales. This is done without considerations as to the volume of work to be accomplished so as achieve timely delivery. Poor or No Requirements Lacks of clear requirements from the users have made most projects fail entirely. This is because most of them have high level, vague and also unhelpful requirements. The developers by lacking precise requirements from the users, they end up building what they feel is required. Finally when the system is delivered to the final users of the system, they in turn reject it indicating it didn’t achieve their expectations and this is because they weren’t involved. What is recommended is to let the users know what they want from the system and be able to state the same precisely. The scope of a project is defined as the overall view of what they will finally deliver. This is the extent to which the project will encompass or the growth in the scale of the system during the lifecycle of the project. This has been seen as one of the main reason as to why many projects run over budget or be delivered late. It’s always advisable to set the given expectations correctly during the outset of the project and there be clear definition on what shall be contained in and out of the scope. There should not be assumption that the users understand the project document and so it should be ensured that they completely understand and agree with the scope (Britain 2011). No change control system Just the same way businesses change, the systems requirements are bound to change whilst the system is undergoing development. However, if there is no control as to the extent of system requirements change; this may cause the system end up being under-developed which has been attributed to the mass project failures. This is the reason as to why there’s greater emphasis on having projects with shorter time scale and being developed in phases so that the changes will have minimal effects on system development. The changes before being incorporated in the system must be evaluated on the effect they will have on the timescale, cost and risk of the project. Poor Testing Before a system has been offered to the users to perform acceptance testing, the developers have to complete their testing to finality. However, when users perform acceptance testing, most faults are never detected because of presence of poor requirements which are hard to test. Secondly, there is a poor or non planned test which means the system fails to be accurately checked. Thirdly, the users lack adequate training as to the main purpose of performing the tests. Lastly, there is never adequate time to perform the required tests on the project because many times the project is usually late. Team motivation Whenever a team is motivated, they will go an extra mile to ensure the projects remains on time and still on budget. Hence it’s important to keep the entire team motivated by ensuring they are involved in the entire projects development cycle and also by planning the frequent milestones which assists them feel they are making progress. Communication should be instilled so that the team is aware they are making positive progress not just when there is poor performance. Risk Management It’s usually hard for people to think about risks more so early on in a project. It’s recommended to maintain a risk log containing an action plan which helps to minimize each of the risks and finally publish it to all the interested parties to the project. It’s always good to be aware what action should be taken should the worst happen. Conclusion From the report, the following recommendations should be adopted to avoid project failure in future. First, proper planning before commencing the project, ensuring IT project have clear objectives, ensuring proper communication, involving user participation as well as appropriate planning, communication and technology skills. References Britain, G. et al. (2009) Communities and Local Government' s departmental annual report 2008: report, together with formal minutes, oral and written evidence Volume 238 of Paper (Great Britain. Parliament. (Session 2008-09). House of Commons); 238 [incorporating HC 1089-i-ii, session 2007-08]) Volume 2 of Report (Great Britain. Parliament. (Session 2008-09). House of Commons. Communities and Local Government Committee)) Second report of session 2008-09, Norwich: Stationery Office, p.1-35. Britain, G. et al. (2010) FiReControl Fifth Report of Session 2009-10 - Report, Together With Formal Minutes, Oral and Written Evidence, Norwich: Stationery Office, p.1-41. Britain, G. (2011) the failure of the FiReControl project: Department for Communities and Local Government Volume 1272 of HC (Series) (Great Britain. Parliament. House of Commons), Norwich: Stationery Office, p.22-41. Read More