IT Project Failure Rates: Facts and Reasons

The picture is indeed meant to startle — he doesn’t like the facts.  That is, failure rates on IT projects are unacceptably high, and the reason is primarily people-based.

Here are some facts:

  • According to an IBM study, only 40% of projects meet schedule, budget and quality goals.  Further, they found that the biggest barriers to success are people factors.
  • Geneca, a software development company, noted from its studies that ‘fuzzy business objectives, out-of-sync stakeholders and excessive rework mean that 75% of project participants lack confidence that their projects will succeed.’
  • As I’ve written before, McKinsey recently found that ‘while an increasing number of non-IT executives give IT a score of 61% for basic services like email and laptop support, only 26% rank IT high in the most vital area of proactively engaging with business leaders on new ideas or systems enhancements.’
  • The Portland Business Journal found similarly depressing statistics:  “Most analyses conclude that between 65 and 80% of IT projects fail to meet their objectives, and also run significantly late or cost far more than planned.”
  • One Canadian study actually stated: “Bad communications between parties are the cause of IT project failures in 57% of cases they studied.”
  • KPMG New Zealand found ‘…and incredible 70% of organizations have suffered at least one project failure in the prior 12 months and 50% of respondents indicated that their project failed to consistently achieve what they set out to achieve.’

Can you imagine hearing numbers like this for finance, HR, marketing or operations projects?  Despite the potential impact of IT projects on business competitiveness, their expense, their ‘opportunity’ cost and the sheer labor and time spent planning, these figures have not improved in well over a decade.  Why is that?

Some thoughts on where success lies:

First, team attributes.  Any large project involves many people.  Success or failure is generally based on the skills and effectiveness of the people involved, their ability to focus on the project, team dynamics and openness to change.  Failure to engage stakeholders is a classic mistake.

Second, team member focus.  IT projects often fail due to a lack of focus among team members.  Sometimes nobody on the team is exclusively focused on the project and everybody retains some level of responsibility for other projects, tasks, or jobs.  More frequently, IT resources are dedicated to the project, but the business users and sponsors try to fit project tasks around everyday jobs.  Under these circumstances, IT projects always go off track, normally very quickly, and normally necessitating massive rework, leading to budget and time overruns.

Third, dynamics between business and IT.  Active support, engagement and involvement of business users and executive sponsors is critical.  Only they know exactly what the requirements are, can tell whether the system is meeting those requirements, and can make key decisions. And only they can encourage adoption once the system is deployed.  Failure to establish a sponsor in the business is attached to most technology implementation failures.  (In fact, when change management was deemed effective, projects had a significantly better chance of meeting their objectives.)

 Fortunately, all is not lost.  Here are five steps to improving the ‘people-based’ factors affecting IT delivery:

  1. Solidify the technology/business relationship via governance
  2. Integrate technology intro strategic planning
  3. Set and share a simple, multi-year roadmap for overall business strategy
  4. Establish an open planning process
  5. Teach and promote communication and relationship skills

I believe if you view IT projects as not just ‘a technology problem’ and consider the people factors, your organization will increase its implementation success, create better relationships and maximize its ROI.

Enhanced by Zemanta

Comments

  1. Excellent blog and timely references to validate my research related to why it projects fail. In this blog you state
    “One Canadian study actually stated: “Bad communications between parties are the cause of IT project failures in 57% of cases they studied.”
    Would it be possible to provide me the link to this source. I am based in Canada and having a localized authoritive would valuable to our research.
    Thank you, Wayne

    • Frank Faeth says:

      Hello Wayne,

      Thank you for your kind comments and for reading my blog. We should certainly speak as I’d like to learn more about why IT projects fail.

      Unfortunately, of all the stats I found, the one for the Canadian figures had this entry next to it on the web: [Untitled 2008 Canadian study].

      I am sorry I could not be more helpful to you.

      Feel free to call if you’d like to discuss any of this further. My cell number is 203-521-9972.

      Regards,
      Frank

  2. It is an excellent article, must read for everyone having a role in IT project – be it end user, business manager, developer…

    Project is unlikely to be success, if stack holders are not actively participating in the project. The issues are not resolved on time – resulting in to cost and schedule overruns. Large organization with deep pockets may still manage to control but small and mid-size organizations bleed.

    • Frank Faeth says:

      Hello — thank you for reading my blog and commenting. Your point about requiring stakeholder involvement is right on target.

      Regards,
      Frank

  3. This is an excellent blog and relating to my research.. I would be grateful if you can give a proper citation for all the statistic that you posted here..

    • Frank Faeth says:

      Maria,

      I am sorry to say that I no longer have those citations. Foolishly, I threw out some papers I meant to keep. I would be very interested in seeing your research when you feel the time is right. By the way, the blog you read is the most often-read blog I’ve ever written. It’s #1 on the list of what people read on my site.

      My apologies for not being able to be more helpful.

      Regards,
      Frank

  4. Howdy! I could have sworn I’ve been to this blog before but after reading through some of the post I realized it’s new to me.
    Anyhow, I’m definitely glad I found it and I’ll be bookmarking and
    checking back frequently!

  5. Kanchan Papal says:

    Really nice blog.Very simple and to the point. I liked the first and second point. Skills and focus are very important. I have seen in the past when i focus on my project or any task – it really turns into success. Also promoting relationship and communication skills point is really nice. can you please share in detail on “five steps to improving the ‘people-based’ factors affecting IT delivery.”

    • Frank Faeth says:

      Thank you. For further info, you would need to engage my services. Feel free to write me to discuss.

      Regards,
      Frank

  6. What’s up, I would like to subscribe for this weblog to obtain most up-to-date updates, so where can i do it please assist.

  7. Asterion says:

    Wow. Still doing this by surveys. Has anyone thought of the raw data embedded in open source sites like source forge. It may seem a bit twisted but the general feeling is open source is good but there is likely more than a 40% failure rate in open source. The propensity to use open source as THE model, and tout “Agile” as The Silver Bullet, appears not to have help project failure rates. Please explain.

    • Frank Faeth says:

      Hi,

      Good point re open source — I was not aware of that. If you have data on that, I would like to see it. As for Agile, it’s very hard to get right and few institutions have the determination to stick to it and/or create the right environments where it can be successful. You not only have to change the way technologists work; you also need to have the right business owners working with you. A very hard task.

      Regards,
      Frank

  8. Can I suggest a related resource? Why Projects Fail is an in-depth book containing suggestions and recommendations regarding failed projects, case studies and analysis.

  9. Did you use any research paper for this article of yours? If you did then please do use them in reference.

    • Frank Faeth says:

      Hello Syed,

      Thank you for reading my blog. To answer your question, the only references I have are in the blog itself. It was written such a long time ago, I no longer have specifics.

      If I can be of help to you, please feel free to contact me just to talk or discuss ways of working together.

      Regards,
      Frank

      • Hi Mr. Frank,

        I am doing Thesis on ‘Failure of large scale software projects their causes and propose solution’, for the thesis I am also advised to collect information about software projects especially large scale software projects which ended as failure, either in developing phase or after implantation failed to meet client’s expectations, Through surveys and through reading, I have collected few issues which contributes in the failure of IT projects, there are two ways to measure a particular reason of failure 1-Quantitatively 2-Qaualitatively, e.g.: Some projects failed due to Bad Project Management, Quantitatively we can say that, ‘6 projects failed due to project management’.

        So it’s easy to measure quantitatively, but what do you think is the way to measure them qualitatively, what can be the unit or measuring criteria to do it?

        I’ll be a kind favor from you, if you guide me in this.

        Regards.

        • Frank Faeth says:

          Hello Syed,

          Sounds like a truly interesting and worthwhile thesis — businesses could use your guidance. With respect to ‘qualitative’ measures, here are the few I would consider: 1) User satisfaction with the functionality and implementation of the software; 2) From a user’s perspective, did the software meet their expectations?; 3) Have the user identify the unexpected benefits of the software (e.g., improved customer service, better products, enhanced response time, better information); and 4) Did the software implementation align the goals of the business organization with the company’s strategy?

          Best of luck,
          Frank

  10. Great website you have here but I was curious if you knew of any user discussion forums that cover the same topics
    discussed here? I’d really love to be a part
    of community where I can get feed-back from other knowledgeable people that share the same interest.

    If you have any recommendations, please let me know.
    Thanks!

  11. Hi,
    I have more then 30 years of IT experience, worked in many IT center as project leader, when you see project that is main a problem to solve…, and any project take time ans phases with level of decisions.
    if you do not govern your project with transparency and lesson than your project failure.
    My team been working to develop a smart software to in crease IT center efficiency to help manager making a successful project.

  12. Hi frank, I am doing a paper on the critical factors for IT Project failure rate and success rate both large scale and small scale (less than 1million $). This blog was a very useful, however would like to know about the current stats.. has there been any further improvement. As it been steadily increasing from about 16% in 1994 , 35% in 2007 to about 40% in 2013.

    • Frank Faeth says:

      Hello,

      Unfortunately, I haven’t seen current statistics. Wish I had them for you. The numbers you site are quite startling — I was hoping for improvement. You might want to try IBM’s CIO Center of Excellence, as they have good data. MIT also has a center for analyzing technology projects, and they could be of help to you as well.

      Best of luck. I’d enjoy learning what you found.

      Regards,
      Frank

Trackbacks

  1. […] the article titled “IT Project Failure Rates: Facts and Reasons”, located here (https://faethcoaching.com/it-project-failure-rates-facts-and-reasons/ ). Next, propose three (3) […]

Speak Your Mind

*