IT Project Implementation Failures: Overview

Before an IT project can begin, the acquisition process must be successful. Once the implementation process beings, however; many things can start to go wrong because there are many factors and people involved that may not work together. Although the acquisition process is very stressful and important too, the implementation of planning a project and choosing the right team to do the job is not always as easy as it sounds.

As hard as it may be to effectively navigate through these potential failures, project failures such as the ones illustrated in the case study, Memorial Health System CPOE Implementation, can be evaded. At the beginning of the implementation process, Fred Dryer and Joe Roberts agreed and established a plan to get the CPOE system effectively enough for the staff and other employees to use. Stakeholders did not agree with Dryer and Roberts that this system would be meaningful and eventually disagreed with them.

This must be a common problem with the implementation process, because it is very difficult to get so many people to work together cohesively. The organization undergoing the IT process must be a cohesive unit in believing in the project as well as being on the same page about what needs to happen. Since the stakeholders have too much power in the process, Roberts and Dryer left the project. The other project failure demonstrates the difficulty of choosing the right team members and management personnel to effectively run the project.

The interim CIO, Melvin Sparks, was, to put it mildly, the wrong person for the job. He illustrated many of the project failures. He was unable to effectively communicate with his staff, made decisions that negatively affected the project and ultimately committed a huge mistake by changing the scope of the project during the implementation process. The project manager in the case study was yelled at to give good news or no news at all to Sparks. Not only is it completely inappropriate for CIO to yell at staff, but communication is integral in the implementation process, whether it is good news or bad.

Changing the scope of the project during the implementation process creates chaos. A good acquisition process will create an environment where large deviations from the initial project scope are not accepted. Another vital problem in the case study was the lack of testing done on the system. Testing assures the team of the functionality as well as the problems that may arise from the system, and gives time to fix it. Sparks created no confidence in the team and showed none in the initial project. Conclusion:

The case study’s project failures could have probably been avoided. The main job of the implementation team, besides implementing the project, should be to create a strong team with strong management and staff. Without this backbone, the process is doomed from the start. There are steps and procedures that can be implemented in order to avoid these types of failures in the future. I would recommend cross-training between management to insure everyone knows what steps to take in order to have a successful IT project.