IDC Directions09: Analyst perspectives on IT failure

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.

SHARE:

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.

Topics: CXO, Collaboration, Enterprise Software, Software

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

6 comments
Log in or register to join the discussion
  • Over governing it a problem too...

    Far too often, more than lack of control, is
    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.
    Narg
  • RE: IDC Directions09: Analyst perspectives on IT failure

    My research on the subject has led me to believe that the two greatest causes of failure are management optimism bias and poorly defined outcomes.

    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.
    kingmail53@...
    • What's the solution?

      I would not disagree on your points, however, what's the solution to these problems? I'd enjoy seeing your research, if you would like to share it.
      mkrigsman@...
    • IT Failure

      I'm researching IT decision making. I'm looking
      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.
      jboutte
  • Simply underestimation?

    I think the first step to solve the problem with
    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.

    md032
    • Not sure I agree

      On one level, your points make sense, but dig deeper and what does "fix estimation" really mean? I think these organizations with failing projects already doing their best job to estimate correctly. Since that isn't working, it means something else is wrong. Any thoughts on why estimating is done so poorly?
      mkrigsman@...