Why Is It So Difficult to Eliminate Failing Projects?

The success rate for IT project is very low, for every organization managing multiple projects, there are inevitably some projects that should be discontinued and the resources need to be re-allocated to higher value purposes. However, that rarely happens in many organizations for a myriad of reasons. Instead of concentrating resources to complete major projects quickly, team members worked inefficiently on several projects at once - often long after their purpose no longer existed. Why is it so difficult to kill failing projects?

Emotion: It takes quite a sharp mind to foresee that a project is doomed to failure; and it also takes strong willpower to detach oneself from the project and allow it to discontinue. This is obviously the case when a person has to make the decision about their own project, not decisions coming from up top. As both individuals and teams tend to treat projects as either their baby, or an extension of themselves, so they will either push a failing project along because of a strong emotional attachment to it, or they see the failure of their project as their own personal inadequacy. Furthermore, an organization’s attitude towards failure determines the personal risk to individuals who say "I was wrong." If the personal consequences of (probably) wasting organization resources are more attractive than the personal consequences of admitting you were wrong, then the failing projects won’t get killed smoothly.

Design criteria: A well defined project brief or design criteria at the onset is one of the most valuable tools for a team to reference throughout development process. Businesses often see 'creep' in the parameters of a project, in an attempt to keep it from failing. Or certain disciplines look to add value by including additional features or opportunities, beyond the original scope. This is where the project design criteria is crucial, for a project can either be killed or redefined - often innovation comes from the failure of an alternate task.

Communication: A kick-off meeting that includes teams members from all intended disciplines is also critical, not only allowing everyone to understand the project intent and their roles or responsibilities through a gated process, but also offering a broader collection of disciplines with the ability to recognize if a project is not reaching the intended goal. In redesigning the process, it is good to have a kick-off meeting to the start of every new product development. In this meeting, one of the standard work tasks of the team was to define a set of kill conditions. Many of these were generic across projects and some were specific to a given project. Teams were then empowered to proceed through a stage - gate process informing management at the gates rather than asking permission (proceed until halt). The team was also empowered to eliminate the project if the termination conditions were reached. This empowerment led to shorter lead-time in the development process and an earlier end to projects that needed to be stopped. Terminating a project was now viewed as an appropriate action rather than a failure. 

Checklist or constant monitoring: At intervals appropriate to the project (milestones, time intervals, etc.) you would have a checklist of these conditions to run through. Or it was more the case of constant monitoring and when a condition was met, the project was killed regardless of the stage. The second approach seems more flexible, but more difficult to manage. This process was admittedly on a smaller scale than an enterprise wide initiative, but a similar up front definition of success and kill conditions could help an organization bring an appropriate early end to failing projects.

Guidelines over rules. The pipeline is crowded with failing projects that continued to absorb resources and clutter the pipeline. In the end, you need to build a process that enables smart people to behave intelligently. Set guidelines, not rigid rules for continuous evaluation, Another key is that at the end of a project, you have a post mortem as part of the standard work. The purpose is to review how effectively the process works and what the team would change for the next project. In the case of a "killed" project, the process review centers on: could you have done something differently early on that would have facilitated success over kill? Could you have made the kill decision sooner?, Can you change the project selection criteria so that this project would not have been selected?

Either initiating business/IT initiatives or eliminating projects takes strategic view and tacit methodology, it should not be based on gut feeling only. Set the guideline to follow through; both think fast and slow, and  well define the proper process in order to manage the project portfolio at the most effective and efficient way.