An IT department’s most critical point of failure lies in its inability to cancel a dead-end project. Canceling a project can be a great move, but it is uncommon. (When was the last time you canceled an IT project?) All too often, IT departments waste significant time and money on a fruitless effort.
Let’s explore the major reasons why an IT project reaches an impasse. Knowing the reasons will help find an effective, yet low-risk path to fail fast and move forward.
The 5 Reasons IT Projects Fail
Generally speaking, a project fails for one (or more) of the following reasons:
| Root Cause | Details | Example |
|---|---|---|
| Poor Idea | Just because your competitors are doing it, Gartner published a new magic quadrant, or the benefits seem intuitive, it doesn’t mean you must initiate a project. | A distribution company is eager to reduce its highest operational cost: shipping. The IT team launches a shipping systems overhaul. Soon it becomes evident to the project team that the required effort is enormous, and the benefits will be limited. The level of effort no longer justifies the benefits. |
| Poor Adaptability | In a vacuum the project makes great sense, but changes in business processes, strategy or technology make it significantly less desirable. | An enterprise funds a BI effort aimed at providing top management with operational and strategic dashboards. In the meantime many of the source systems are replaced. IT ends up having to go back to square one with the BI effort. |
| Poor Strategic Fit | Even with a tangible ROI, it is easy for a non-strategic project to lose momentum because strategic initiatives are always prioritized over it. | A media enterprise stands to gain significant savings with an upgrade to its infrastructure. An upgrade is funded, but resources are absorbed by a business initiative to expand content delivery outlets. The latter supports a core strategic objective and will always trump projects based purely on cost savings. |
| Poor Planning | This is the most common reason projects fail. Project teams are doomed when the allocated budget, time, resources, and methodology are not viable for achieving the benefits listed in the business case. | A global manufacturer creates a model of an ERP system to roll out to all locations worldwide. The model is sturdy and works well for a number of distribution centers. The first manufacturing facility deployment shows that there are significant issues. Prototyping was not planned for, so when user acceptance testing results in heavy scope changes, the project team is forced to redesign the solution from the ground up. |
| Poor Execution | Everyone was excited at the kickoff meeting, but the loss of sponsor or stakeholder support, poor change management, lack of risk management, or the omission of key steps have ground the project to a halt. | A company initiates an application upgrade. The team assumes the upgrade will not affect daily operations, so they fail to document the current business process. During user acceptance testing it becomes obvious the new release will not work with the existing business process. |
Tweet: 5 Reasons #ITProjects Fail | @mpapov
#failfast #projectmanagement https://ctt.ec/Je7fd+
Canceling a Project Isn’t the Same as Blaming Someone
We have all seen many of the above conditions, but we rarely share our suspicions that a project is doomed to fail. The reason is that too many companies today take a defensive approach to project failure, searching simply for someone to blame.
Rarely are these failures the result of one individual’s wrongdoing or lack of judgement. Project failure is more typically caused by a lack of alignment among individuals or groups who are all pushing very hard in different directions.
A more effective approach to IT project failure is to proactively and objectively assess its chances of success—without pointing fingers. Because this may take a culture shift, consider the following suggestions for proactively assessing your project.
Clear Signs an IT Project Needs to Fail Fast
If you are a project sponsor, manager, stakeholder, or contributor, you can usually tell when a project is going nowhere fast. To stop the bleeding, it’s best to communicate to other stakeholders with clear evidence that the odds are stacked against success.
The following symptoms clearly predict that an IT project will fail:
- It’s been a while since an executive attended the project’s weekly status or steering committee meetings or, worse yet, there are no regular status meetings.
- The individuals who will be using new technology have not seen it, or are not thrilled with it.
- Project participants are sidetracked by other priorities resulting in delays.
- No one is tracking open issues and risks.
- Issues that have been presented to senior or top management have not been resolved in a timely manner.
- The timeline has had setbacks, but the approach has not been adjusted. Instead project stakeholders continue to repeat the same actions, expecting to get different results.
- Change order costs are of the same order of magnitude as the original budget.
- The team displays poor team moral or lack of task ownership.
Tweet: 8 symptoms of a failing IT Project | #FailFast
@mpapov #Abraic https://ctt.ec/fq6sS+
If two or more of the above symptoms are present, the project is approaching a dead-end. At this point the team should move into one of two modes: project cancellation or project rescue.
In most organizations, the project lingers on until it delivers something for the sake of a checkmark, gets overridden by the next generation project, or an unfit solution is forced upon the business—leading to a real disaster.
Embrace the Failure to Move Forward
Mistakes always present learning opportunities. If the goals of the original IT project are still valid, it may be worth moving forward—but something needs to change.
In many cases though the first step toward success is to stop an effort that leads nowhere and free up the resources to proceed with new priorities and new project frameworks.
It’s time to cancel that dead-end project! Yes you can (and probably should more often).
