A survey found that 43% of organizations had recently killed an IT project. The top 5 reasons for terminating projects were: 1) Business needs changed (30%), 2) Did not deliver as promised (23%), 3) Project was no longer a priority (14%), 4) Project exceeded budget (13%), and 5) Project did not support business strategy (7%). While these reasons indicate failed projects, some terminations could be justified if the business environment or requirements changed legitimately. Determining a project's success requires examining its full context and delivered business value.

1. 2/29/2016 5 Reasons to Kill IT Projects - IT-Toolkits.org
http://it-toolkits.org/blog/?p=382 1/2
5 Reasons to Kill IT Projects - IT-Toolkits.org
A survey of IT experts revealed 43 percent of their organisations had recently killed an IT project. The
study, conducted by ISACA, an independent IT governance group, highlighted the top 5 reasons
these organisations named for terminating projects prior to completion.
Here’s the list, with my commentary on each issue:
1. Business Needs Changed: 30%
There are many conditions and situations where a business legitimately changes its requirements
after starting a project. If the project no longer provides meaningful value, then it’s best to stop
throwing good money after bad.
On the other hand, some organisations deliberately obscure a flawed project requirements process
by claiming business needs evolved. Obviously, that’s unhealthy and a true sign of failure.
2. Did Not Deliver as Promised: 23%
This is a typical expectation setting problem: promise anything to get funding and worry about the
consequences later. Shortsighted managers don’t realise that funding is less important than
delivering substantive value. Failure is inevitable when managers don’t clearly identify and deliver
business value.
In some cases, the project really did provide value, which the organisation did not recognise due to
communication problems. I recently blogged about one CIO seeking a publicist, presumably to
address this issue:
Many organisations take a CIO for granted when his IT department consistently delivers the goods
without fanfare and attention; sadly, this human failing is all too common. In that case, PR might be
a great idea, especially if the CIO isn’t a great communicator. Of course, the CIO should improve
his communication skills, but that’s another story.

2. 2/29/2016 5 Reasons to Kill IT Projects - IT-Toolkits.org
http://it-toolkits.org/blog/?p=382 2/2
3. Project Was No Longer a Priority: 14%
If the organisation shifted direction without good reason, thus making the project superfluous, then
flawed strategic planning was the culprit. However, if business requirements changed for a good
reason, as suggested in point one, there’s not necessarily a problem.
In general, and this is an obvious point, cancelling projects without a darn good reason is a definite
sign of failure.
4. Project Exceeded the Budget: 13%
On the surface, over-budget projects are the basic metric for failure. I’m actually surprised this
number isn’t higher, because unanticipated cost is always such a clear red flag.
At the same time, some projects run over-budget due to intelligent scope increases that provide
additional value. For example, while automating two departments, the project team realises it can add
a third department for only marginal increases in cost. In such cases, going forward is probably the
right decision despite the higher spend.
Although tempting to use budget performance as simple metric of success or failure, that approach
can be overly simplistic and ignore important nuances related to business value. Nonetheless,
anytime a project goes over-budget the team must offer a detailed explanation.
5. Project Did Not Support the Business Strategy: 7%
This classic indicator of failure often suggests a project rooted in poor requirements analysis.
However, as with previous points, it’s also possible changing business needs made the original project
goals obsolete.
The survey is most interesting to highlight significant issues related to project failure. However, some
of the questions are too ambiguous to provide straightforward conclusions. In general, understanding
whether a project is successful requires examining the business environment and context.
You may also like