Five reasons to kill IT projects
August 12, 2009, 11:31am PDT | Length: 00:05:24
According to IS Audit and Control Association, 43 percent of organizations recently killed an IT project. This episode of CIO Sanity Savers discusses the top five reasons projects were killed and the implications of each one.
Transcript
Jason Hiner: One survey of IT experts revealed that 43 percent of their organizations had recently killed an IT project. The study, conducted by the IS Audit and Control Association, an independent IT governance group, highlighted the top five reasons these organizations named for terminating projects before they were completed.
I'm Jason Hiner, and today on CIO Sanity Savers, I'll discuss those five reasons and look at the implications of each one.
Number 1: Business needs changed
30 percent of those whose organization recently killed an IT project said it was because business needs changed. Of course, 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, it's best to stop throwing good money after bad.
On the other hand, some organizations deliberately try to obscure their flawed project preparation and management by claiming business needs evolved. Obviously, that's unhealthy and a true sign of failure.
Number 2: Did not deliver as promised
23 percent of the killed projects were attributed to a failure to deliver as promised. 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 projects is less important than delivering real value. Failure is inevitable when managers don't clearly identify and deliver business value.
Number 3: Project was no longer a priority
According to 14 percent of those whose organizations recently killed a project, that project had ceased to be a priority. If the organization shifted direction without good reason, thus making the project superfluous, 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 obvious but it's worth a reminder -- canceling projects without a darn good reason is a definite sign of failure.
Number 4: Project exceeded the budget
13 percent of respondents who cited killed projects said the project was terminated because it ran over budget. On the surface, over-budget projects are the basic metric for failure. It's actually surprising that 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 may realize 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 it's tempting to use budget performance as a simple metric of success or failure, that approach can be overly simplistic and may ignore important nuances related to business value. Still, anytime a project goes over-budget, the team better be prepared with a detailed explanation.
Number 5: Project did not support the business strategy
Winding up the top five reasons for killing a project, 7 percent said the project didn't support the business strategy of the organization. This classic indicator of failure often suggests a project rooted in poor requirements analysis from the beginning. However, as with previous points, it's also possible that changing business needs made the original project goals obsolete.
Some of the questions in this survey were really too ambiguous to deliver straightforward conclusions. However, it did serve to highlight some of the significant issues related to project failure. In general, understanding whether a project is successful requires examining the business environment and context.
To dive deeper on this topic, see Michael Krigsman's article that this episode was based on.
I'm Jason Hiner and this has been an episode of CIO Sanity Savers. For more, go to sanity.techrepublic.com. And if you have your own sanity savings tips, e-mail them to us at sanity@techrepublic.com. If we use one of your tips on the show, we'll send you a TechRepublic coffee mug. Thanks for watching. See you next time.



