IDC Directions09: Analyst perspectives on IT failure
Summary: While attending the Directions09 conference in Boston today, I explored why IT projects fail in conversations with two IDC analysts.
While attending the Directions09 conference in Boston today, I explored why IT projects fail in conversations with two IDC analysts.
During a discussion with Vice President for Services and Technology Research, Sébastien Ruest, we touched on key reasons why projects are late, over-budget, or don't achieve expected results. Sébastien commented:
There is still not enough governance. Projects fail because companies do not apply sufficient real-time governance to their implementations.
I agree that too many organizations allow projects to run without sufficient review and control. As a result, potentially minor disturbances eventually escalate into large, full-blown problems. In the heat of battle, I suppose many managers forget that preventive maintenance really does save time and money.
Sébastien also pointed out an overlooked implication of IT failure:
Failures erode confidence in the CIO, causing business stakeholders to reject the CIO's downstream plans. After failures occur, the CIO may face difficulty justifying new projects.
I also met separately with Melinda Ballou, 
Program Director for Application Life-cycle Management at IDC. Melinda emphasized that many projects fail when poor communication interferes with collaboration among project participant groups:
Although it's common wisdom, poor collaboration and communication between key business stakeholders and IT remains a serious issue. Also, keep in mind that redundant projects, where the organization discovers it is running duplicate projects unnecessarily, is another form of failure arising from lack of communication.
Melinda suggests that Agile development can be an excellent mechanism to improve collaboration, especially on software development projects.
My take. The big causes of failure remain governance, communication, and collaboration breakdowns. As with all people-related obstacles, these issues are difficult to control, let alone eradicate completely. In the end, failure improves when an organization becomes serious about encouraging IT and business stakeholders to work together more closely. As failure statistics demonstrate, that goal remains elusive for most organizations.
Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.
Talkback
Over governing it a problem too...
over-control by people who are clueless about
the reality of IT projects.
There is a general problem with IT. And, it's
the reason why IT workers are often considered
the most stressed of any other profession.
There is a poor consideration for what IT is,
and what it can provide. Too many are used to
the "Instant" in computers. When projects are
outlined, they are often gauged in that aspect,
and the expectations are often too high or
placed in the wrong context.
A good IT project manager and IT team can
provide a LOT. But, they can't provide unreal
expectations to people who do NOT understand
the outcome expected from the applied input.
RE: IDC Directions09: Analyst perspectives on IT failure
Most projects fail because the desired outcome is poorly defined and the organization and procedures to accomplish it are poorly understood. It is very difficult indeed to reliably achieve an acceptable solution to a problem that management has not agreed is a problem.
Management optimism bias regularly causes underallocation of time and resources; and, a lack of commitment to continue when projects inevitably fall behind schedule because some of the unplanned risks arise.
Cary King, Ph.D., J.D.
What's the solution?
IT Failure
for recent examples of IT failures in the federal
government to understand how these failures can be
mitigated in the future. Have you researched
government IT decision making and IT failures?
Please point me to your research or articles on
the topic.
Simply underestimation?
schedule overrun in projects is simply to estimate
correctly.
If you know the level of governance you are going to
apply (too little, too much) you should be able to
take that into account in the estimates. If you also
know how much effort its going to take to explicitly
track to the expected results then that should be in
the estimate too.
There is a simple relationship via Risk -> ownership -
> governance -> mitigation -> effort -> cost. So
knowing the risks of the project and attempting to
estimate effort and cost forces you through the path
of determining the level of governance, the effort for
communication, and the ownership of outcomes that is
the foundation for communication.
So we need to fix estimation first. We'll provide big
numbers at the beginning of the project and always hit
those numbers. Only then, because we know where our
effort is going, will be be able to work on reducing
the guaranteed absolute cost of IT projects.
Not sure I agree