Software Project Fails - Research Paper Example

Software Crisis Software Crisis Software crisis has raised a steamy debate in the technology world for quite a long time. Most of the views presented in these arguments put huge budgets, delays in the production and the efficiency of the software in question. These arguments have raised questions as to whether this notion by experts really represent reality and weather it’s supported by research (Communications of the ACM, 2006). Software practice and projects as been seen as a hub for failure with the Standish report condemning the practice fully in their published version of the study, The Chaos Report. What is the real situation? Determining whether the opinions of those criticizing software projects are facts, I take a firsthand account of a software project that never saw the end of it. United Kingdom is one country that appreciates technology therefore making software crisis a norm in the region. NHS Connecting for health is part of the countries Department of health formed on 1st April 2005 replacing the then formed NHS Information Authority. The NHS Connecting for health had the task of the national programme for IT (NPfIT), an initiative by the government to move the National Health Service in England towards a centrally-mandated electronic care records for patients. It was also expected to connect 300,000 general practitioners to 300 hospitals, providing a safe and audited access to these records by authorized professionals. A project that would really boost the medical sector in England, the contracts for the NPfIT spine project was awarded in December 2003. NHS Connecting for Health ceased to exist on March 31, 2013 and software crisis was to blame. The cost of the project is estimated at £12.4 billion according to the national office of statistics; it begun in 2000 and was due for completion in 2010. The project was to; create the NHS Care Records Service, which handles the spine database and create the Choose and Book system that would allow patients book their appointments with Doctors via their PCs (personal computers). It was also tasked to come up with a national broadband IT network to upgrade the then used infrastructure and create an IT support for the Personnel including the Quality Management and Analysis System (QMAS). The programme divided England into five regions called Clusters southern, London, Eastern, North West, West Midlands and the North East. Every cluster had a local service provider and a company contracted to deliver the services. The project was the largest civilian IT project and it was decided to spread the workload so as avoid blames. It was a wise strategy since certain companies pulled off (Brian, 2012). In addition to the local service providers they set national service providers responsible for common services such as the choose and book system and parts of the NHS care records service. What were some of the challenges? The NPfIT faced numerous setbacks and critics who declared the program as flawed and unworkable. Delivering stable software on time within a provided budget was a hard task for the players in the project. The critics had lost confidence in NHS doctors. The financial burden was heaped on the service providers who had to deliver satisfactory work and meet milestones before payment from the NHS. iSoft a key supplier in the project suffered losses and almost closed down. At this point it was clear the project was failing. What led to this failure? Creating a system like the NPfT requires a prior awareness campaigns to educate the public of what to expect when it launches. Public funds that has been deployed in the project confirms beyond reasonable doubt that the NPfT fail is traceable back to its start. One can show sympathy to the players in the sector that are giving their all trying to save the collapsing project. The companies involved in the system to wasted a lot of resources and time all in the name of tenders that promised better days for the players and the country at large. Its however clear that lessons can be learnt from the NPfT project. Just like any other government project, politics played an important role in the fall of the NPfT. The government was unable to verify the quality of the tendering deals, clearly the government was unable to deliver the taxpayers money worth. The Management and ministerial ownership and Leadership, the Project Management team had no clear view of the interdependencies between the projects, the benefits and the criteria with which they judged the success. There were no clear governance arrangements to ensure sustainable alignment with the companies involved and the proposed commitments and announcements did not check for implications in the project. There was lack of effective engagement, it is important for the government to indentify the right stakeholders. Furthermore, they should’ve kept track of events and solved issues as they came up not waiting till the ship is sinking (Robert, 2006). This all would secure a common understanding between the stakeholders thus both achieving the requirements for the success of the project. All these and clear accountability would have been the key to the project’s success. Failure to adopt approved skills and approaches to project management and risk management also contributed a lot to the demise of the project. Being able to identify the major risks helps in the preparation of combating the latter, thus helping in allocation of sufficient funds and resource. All these are aspects of proper planning an any project that follows it to the latter becomes a major surprise Attention given to the project is equally important, given the project involved several players. The government should be able to answer the following questions: has the approach been tested that it will work well? Has sufficient time been built in to allow for planning applications in property and construction projects? Have enough viewpoints been built so that the project can be stopped if changing the circumstances means that the benefits are no longer valuable? Evaluation of proposals driven by initial price rather than long-term value for money especially when securing delivery of business benefits, this also is a key factor in securing productive projects (Munson, 1996). The evaluation should be based on all factors affecting the project and the proposed evaluation approach should allow balance of financial factors and maintenance costs. It should also take account of business critically and affordability thus a business driven proposal. As much as we wish that more people should have been involved in the project so as to moderate the monopoly in the project. The service providers too should have done proper surveys so as to avoid the risks that led to the failure of the project (Kuhn, 2004). The termination of the project shows how the whole project was a puppet show, the masters in the back failed to resolve it and therefore sorted to declaring it a failed system. If these short-comings were noted earlier maybe the whole system would be now UK’s biggest achievement. My view on software crisis has nothing to do with the development, as matter of fact our programmers are doing a great job. My problem is with the co players in implementations of these systems, they make the hard work of these computer gurus run to the drain. I advice the project implementers take the basis of teamwork and help kill this term Software crisis. The above-illustrated factors can help scrap out the term software crisis. The software crisis blame is one that can be easily avoided if each one of us in the sector plays their part well. To my knowledge developer platforms are designed to detect any form of failure before compiling software into an executable file. This clears programmers off the blame leaving only one statement, everyone should play their part. I think software crisis is mainly caused by the ways our governments or the concerned bodies implement these projects. A satisfied programmer will go out of his way to present a worthwhile work as opposed to one subjected to meager benefits. It’s also clear that the Standish report was biased. It left out all the social and political factors mounting all the blame to the programmers. As much as producing perfect software is a cumbersome process the sector boasts of bigger achievements than failure and the developers in the field are doing quite well. Software crisis is just a term by critics to make programmers look bad. And that can be viewed in the article taking into account the NPfT’s failure. Let’s all take responsibility and avoid further software malfunctions. References Robert L. (2006). Practical Programmer. Albany: communications of the ACM Kuhn, Richard. (2004). IEEE Transactions On Software Engineering. Albany: IEEE Computer Society 2012 Munson, J. (1996). Information and Software Technology. Albany: Cambridge University Press UK. Brian, Fitzgerald. (2012). Software Crisis 2.0, Albany: IEEE Computer Society 2012 Read More