Five reasons to kill IT projects
Wednesday, December 17, 2008 11:11 AM
A survey of IT experts revealed 43 percent of their organizations had recently killed an IT project.
The study, conducted by ISACA, an independent IT governance group, highlighted the top five reasons these organizations named for terminating projects prior to completion.
Here's the list, with my commentary on each issue:
1. Business needs changed: 30 percent
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 organizations 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 percent
This is a typical expectation-setting problem: promise anything to get funding and worry about the consequences later. Shortsighted managers don't realize 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 organization did not recognize due to communication problems. I have blogged about one CIO seeking a publicist, presumably to address this issue:
Many organizations 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.
3. Project was no longer a priority: 14 percent
If the organization 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, canceling projects without a darn good reason is a definite sign of failure.
4. Project exceeded the budget: 13 percent
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 realizes 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 percent
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.
Note: 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.
Michael Krigsman is CEO of Asuret, a software and consulting company dedicated to reducing software implementation failures. He also serves as CEO of Cambridge Publications, which specializes in developing tools and processes for software implementations and related business practice automation projects. Michael contributes to the IT Project Failures blog at ZDNet Asia's sister site, ZDNet.
There are currently no comments for this post.