Software Crisis
For a long time, the computing problem has ignited intense discussion in the technology community. The majority of the viewpoints raised in these critiques cast doubt on large budgets, development delays, and software quality. 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?
In order to determine if those that criticize software projects are right, I use a firsthand account of a software project that never got finished. Since the United Kingdom values technology, software crises have become ubiquitous in the area. NHS Connecting for Health is a division of the country’s Department of Health, which was formed on April 1, 2005 to replace the NHS Information Authority. The national programme for IT (NPfIT), a government effort to shift the National Health Service in England toward nationally mandated electronic treatment documents for patients, was allocated to NHS Connecting for Health.
It was also intended to associate 300,000 general practitioners with 300 hospitals, allowing authorized clinicians to view these documents in a secure and audited manner. The contracts for the NPfIT spine project were won in December 2003, and it was a project that would really improve the medical sector in England. The tech crisis was to blame with NHS Connecting for Health’s demise on March 31, 2013. According to the national office of statistics, the project’s expense is expected to be £12.4 billion; it started in 2000 and was planned to be finished in 2010.
The aim of the project was to develop the NHS Care Records Service, which manages the spine database, as well as the Choose and Book method, which allows patients to arrange appointments with doctors via their machines (personal computers). It was also given the mission of developing a nationwide broadband IT network in order to update the existing networks and provide IT support for personnel, including the Quality Management and Analysis System (QMAS).
Clusters southern, London, Eastern, North West, West Midlands, and the North East were the five areas separated by the initiative. Per cluster had a local service provider as well as a firm that was hired to offer the services. The project was the biggest civilian IT project ever conducted, and it was agreed to delegate the workload to prevent assigning responsibility. It was a smart move, since certain businesses were able to pull it off (Brian, 2012). They delegated national service providers to common programs such as the choose and book system and portions of the NHS care records service, in addition to local service providers. What were some of the difficulties you faced?
The NPfIT has had several failures, with opponents declaring the software to be faulty and unworkable. The players in the project had a difficult time delivering reliable apps on time and under the budget they were given. The people had lost trust in NHS physicians, according to the opponents. The financial pressure was placed on service providers, who were required to perform adequate work and reach certain deadlines before receiving reimbursement from the NHS. iSoft, a key project provider, incurred setbacks and was on the verge of going out of business. The project was obviously struggling at this stage. What went wrong that caused this failure?
Developing a technology like the NPfT necessitates previous public relations efforts to inform the public of what to anticipate before it goes live. The usage of public funding in the project shows without a shadow of a doubt that the NPfT failure can be tracked all the way back to the beginning. You can sympathize with the players in the industry who are doing all they can to save the sinking project. All in the name of tenders that offered better days for the players and the nation as a whole, the firms participating in the scheme lost a lot of money and time. However, it is obvious that the NPfT project will teach us everything.
Politics, like every other government effort, played a major part in the NPfT’s downfall. The government was unable to test the consistency of the tendering offers, indicating that it was unable to provide value for money to the taxpayers. Management and ministerial ownership and leadership, as well as the Project Management committee, have no good understanding of the interdependencies between the programs, the incentives, and the performance requirements. There were no consistent accountability mechanisms in place to maintain long-term cooperation with the companies concerned, and the planned commitments and announcements were made without regard to the project’s consequences.
Since there was a lack of constructive participation, the government could identify the appropriate stakeholders. Furthermore, instead of waiting until the ship was sunk, they should have maintained note of incidents and resolved problems when they arose (Robert, 2006). This will ensure that all partners have a shared understanding, ensuring that the project’s specifications are met. The project’s progress may have hinged on both of these factors, as well as strict transparency.
The project’s failure was largely due to a failure to implement accepted project management and risk management skills and approaches. The capacity to recognise major threats assists in the planning for fighting them, as well as the distribution of appropriate funds and services. Both of these are facets of good preparation, and any project that approaches it leads to a big surprise.
Given that the project included many players, the amount of attention paid to it is equally significant. The government should be willing to give responses to the following: Is the strategy been thoroughly reviewed to ensure that it would work? Is there enough time built in for planning processes in real estate and building projects? Are adequate points of view been developed so that the project may be terminated if the incentives are no longer valuable due to evolving circumstances?
Evaluation of plans based on initial price rather than long-term value for money is a key factor in securing profitable ventures, particularly when securing delivery of market benefits (Munson, 1996). The assessment should take into account all project-related considerations, and the recommended evaluation method should provide for a combination between financial and maintenance costs. It should also recognize the value of industry and affordability, rendering it a business-driven plan.
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
