New research into IT project failures

New research into IT project failures

Summary: Computer Associates has released a study into the causes of IT project failures. Although full results have not been released publicly, I did obtain the detailed slides, some of which are presented below.


Computer Associates has released a study into the causes of IT project failures. Although full results have not been released publicly, I did obtain the detailed slides, some of which are presented below. From the press release:

New research from CA, conducted by independent research company Loudhouse of 100 IT Directors across the UK and Ireland, reveals that poor visibility of IT project status and a lack of management control over them is costing the UK over a quarter of a billion pounds each year. A third of all projects implemented each year end up over budget with the typical over-spend between 10% and 20% of the original budget. The survey also highlighted the increased complexity of IT projects, with a typical company running 29 projects at any one time and an average IT budget of between £1m and £5m.

The primary reasons for the budget over-spend is as a result of poor forecasting (50%), project scope increasing during implementation (39%) and issues of interdependencies and conflicts between multiple projects (36%). This isn’t helped by the lack of visibility and control that CIOs have over their project portfolios - 40% of IT directors don’t have complete visibility over the initiatives they are running, so cannot see when projects are threatening to run over budget.

As shown in the first slide below, the study describes questions IT managers can ask, to determine whether their project is in trouble. [For information on rescuing failed projects, see this blog posting.]

New research into IT project failures

The study suggests that 32% of IT projects go over-budget. In contrast, the 2006 Standish Group Chaos Report, states that 46% of application development projects are "challenged," meaning they fail to deliver results on-time, within budget, or in scope. Personally, I trust the Standish Group numbers, since that firm specializes in collecting and analyzing IT failure statistics.

New research into IT project failures

According to the next slide, projects go over-budget because the baseline scope was set incorrectly. Unfortunately, this simplistic analysis does not explain why the scoping was wrong in the first place.

New research into IT project failures

This next slide is scary: it suggests IT Directors don't know what's going inside their own organizations.

New research into IT project failures

The CA study provides current data around IT project failures. However, the conclusions and information could have been more useful with additional analysis, insight, and depth. Nonetheless, CA is to be applauded for sponsoring research into this important area.

Topic: CXO

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


Log in or register to join the discussion
  • I bet...

    The 11% of IT directors that said that they do not have complete visibility into all the IT initiatives are the ones with the best visibility.

    The wise know what they do not know...
    Erik Engbrecht
  • Study brought to you buy

    Someone selling IT project management oversight or bundled solutions.

    Why IT projects fail:

    - Management listens to hot software sales rep who deliberately goes around IT department because she knows they'll dump on the bloated, over-priced POS package she's vamping for.

    - Management deciding they need software that does X instead of focusing on business processes. Goes along with the above but doesn't always involve a cute rep. It usually starts with someone finding something cool on the internet.

    - Users don't know what they want until you show them what they asked for. That's why scope creep happens. They see the display and realize that wasn't what they had in mind. The reason I'm a big fan of prototyping.

    - Management or users asking for unreasonable features...can it wash my car too? And consultants lacking the stones to say no or advise them of the trade-offs.

    IT projects will go off the reservation any time you lose focus of the business processes and start focusing on the technology.
  • Computer Associates?

    How can CA be trusted with any information? They basically buy smaller successful businesses and systematically destroy them and the products.

    It's ironic...but Computer Associates has a huge track record of failed projects themselves. Perhaps they are not in the best position to be offering studies or advice to other companies.

    Also, project fail because middle management is not performing their jobs correctly. The admins just they can't really be blamed. The Executives just want the company to function better than it did they can't really be to blame. The blame mostly falls on middle-managment and their inability to negotiate and communicate between the two other groups. That's their job...and most middle managers are either incompetent or are ignored for their position. Most middle managers also tend to micro-manage everything and simply don't understand their role in a company.
    • Wow

      So many generalizations. Are you sure about everything you assert? Even if some of the assertions you make are true - such as the high failure rate of projects at CA - that's not necessarily a bad thing as pitfalls are there to be avoided. Mistakes help with experience and that makes for better planning. Regarding the generalization that upper management and technical staff appear to have nothing to do with the process - you may want to respectfully re-examine the notion of accountability - some of the better teams that operate are not a collection of lemmings or blind and indifferent leaders.
      • Thanks for making this point

        When I read the comment, over-generalizations came into my mind as well. While high-level, general assertions can be interesting and useful, at some point you need more detail. Otherwise, the generalizations fade into uselessness.
  • Failed projects

    So, nothing new. Users are asking for more than IT *think* they need (I concur with another poster, protyping is key).

    IT really want to be working on the new, who can blame them, it's more exciting. Problem is, projects don't get finished and there's always something new. Only the Great guys get to work on "new" stuff so are moved off of projects *way* too soon.

    Remember the good ol' days when users requests would take months/years? Nothing has changed eh?

    The longer a project, the greater the risk. Quick, small agile projects win every time. Agile integration around Agile Prototyping is what my company OpenSpan focus on, wouldn't it be nice if all projects could work that way?
  • Project fails or Project Planning Fails?

    Beging over budget or having scope creep are many times more related to problems of trying to figure out the requirements and implementation architecture rather than doing executing the project.

    The issue is: you almost never know ahead of time what you really need to do until you start doing it.

    Too many times budgets are SWAGs that get cast into concrete.

    The final budget (and go-ahead) should only be set AFTER part of the project with the goal of figuring out what the **real** project is - which means prototyping the technology, which also can help with users trying to figure out what they want.
    • Absolutely!

      The real issue here, and I identified this in the post, is why the scoping estimates were wrong at the start. Poor planning means poor results.
      • Successfull proj mgt

        The word "estimates" is just that - an estimate based on what is known at the time. At the start of a project uncertainty is high so the estimate could be, say, +75% (over estimated because you close the project early or de-scope) or -100% (under estimated because of high unknowns). Senior mgt need to understand what THEY are asking for. The PM role is to expose assumptions/risk/uncertainty and to use the change mgt process to track, and get sen mgt approvals, for ALL variations.
        While the final outcome may look quite different to the starting "estimate" and "expected project deliverable", if all changes have been approved, then the project (and the proj mgt) IS successfull.
        Project closure needs to include a full review of the estimating process, and documentation and communication of "lessons learnt" - often not done adequately.
        The only time you know if the estimated cost is correct if after ALL bills are paid.
  • RE: New research into IT project failures

    There a several reasons for these failures: it's almost impossible to define an acceptable final product at the beginning of a project; it's almost impossible to define the final budget and timeline at the beginning of a project; and, most important, the majority of the people involed are middling hacks who really don't have a sufficient level of the right skills needed to do the project.
  • Project Success

    I have pulled a few projects out of the dumper. More than one has been the miscommunication of the end user, management and the development team. I strongly favor prototyping and the team's involvement in understanding current processes.

    You have to understand the business principles underlying the need. Start slow, choose appropriate people, get agreement and understanding, only pile on resources when project actually supports them. Finish slow and keep key people involved start to finish.
  • RE: New research into IT project failures

    I think the statistics quoted - 32% of projects over budget (the limited scope of the CA study) vs. the 46% of projects over budget OR re-scoped OR delayed (the expanded scope of the Standish Group) - are consistent, and they are probably both close to correct. Projects that come in within budget, but with fewer features that originally required or delivered late can't be called successes, but these would not have been included in the CA study. Just my read of the sitch.
  • managers fault

    the project manager is supposed to be the go between. either he or upper managment decided not to spend enough time in the design phase of the project or one or both used unrealistic figures and or time frames.
  • Programmers (including myself) are optomists!

    Computer programmers are inherently optomistic in their outlook, and tend to underestimate the time it will take to do a given task (unless it is an extremely simple one).

    Providing estimates of how long something will take is the part of the job I hate the most: large time estimates will just cause people to assume a level of incompetence, and most people want their projects to cost as little as possible, so they go with the low bid, and the programmer ends up eating the difference between what he optomistically hoped he'd be able to do the project in, timewise, and what he actually manages to pull off in the end.

    As the example restaurant menu states in "The Mythical Man-Month", "good cooking takes time".
  • RE: New research into IT project failures

    Thanks for focusing on this - we need more data and lessons learned. You might add more consideration of the org readiness issues - I've seen so many projects falter because of poor stakeholder engagement, communications and end-user prep.
  • 2 CIO Mistakes

    CIO's make two mistakes regularly.

    First, they pronounce that systems must migrate to a new paradigm without researching if all of the systems would benefit from the shift.

    Second, they announce the "go-live" date before they do the analysis that will determine the project scope.
    • Fact-free planning

      Andy Shimberg calls your second point fact-free planning. Read about it here:
  • Thank you ...

    Thank you for your comment. I was as overwhelmed the amount of hot air balloon generalizations as you were.
    Niels Jessen, Denamrk