Project Failure Rates

90% of all IT projects fail! I’ve started questioning these IT project success rate numbers that project managers and sales teams quote me all the time.  Personally, i’m a fan of incremental change over Big Bang rollouts, and I will follow this up with a post on this soon, but I feel like the numbers that are being quoted like this are inflated, outdated and based on old approaches to waterfall project management and software rollouts.

If you look at the numbers from 2009 in a ZDNET article, the claim was then that 68 percent of IT projects fail.  This was mostly based on one specific study and survey so maybe not the best and most diverse dataset, but anecdotal evidence from my own experience was close.  I can remember hearing about roughly half of the projects in a given organization was failing. More often than not these were big bang deployments, in large organizations with understaffed and under funded IT departments that never really had a chance.  Failure depends on how you define it, but in most cases it was one of these three things; more than 25% over budget, more than 25% of allocated schedule late and the scope creep was so large it didn’t survive to its allotted full life-cycle, often times 5 years or more.  

Take for example a SharePoint rollout that was allotted a 1 million dollar project budget, 6 month roll out timeline and expected to survive 5 years before needing to be replaced.  A failure would mean either 1.25 million or more in actual expense, late by more than a month (7.5 months total) or did not survive past it launch date for 4 years or longer. Now, I always thought 5 years for any technology project was unrealistic if just consider Moore’s Law and the rate of change in technology in general that follows it, but throwing that out most projects are likely to fail in the other 2 areas and it’s usually not even come close.  Depending on the size of the organization, replacing a system that requires more than a handful of new people to change workflows and/or be retrained usually requires a double entry system or at least a slow  incremental roll out (time consuming), and legacy system maintenance has to continue during the double entry lifetime (expensive). You then have to take away time from developing or configuring the new system or add additional resources, more time or money.  

You can see where this is headed.  Yes you can plan for a certain amount of this in your budget, but in the end you are just paying more for something that is going to be either too complex for most of your tasks or underutilized.  It’s going to be over budget and overtime and likely to have a very short life-cycle because of the rollout frustration and budget and time will be cut, leaving you with a shell of the initial promise.

PMI has some newer data referenced here in the report, that states that these rates have changed and that organizations that have adopted a standardized Project Management process and PM Office, as well as focused on embracing agile methodologies and hiring technical leadership and management have flipped these numbers.  Starting in 2013 organizations were starting to see a much closer 50% failure rate, and trending better until 2017 when they flipped the metrics to measure Champion organizations, those with an 80% or more success rate (on time, on budget and meets original specs), and under-performers with 60% or fewer.  Of the organizations polled only 15% were in the 60% or fewer and even they were trending up. The key has been embracing agile, or at least incremental or iterative process and getting rid of big bang project rollouts.  



A concerted move away from one size meets all solutions and a cloud native and integrative approach has driven this forward even more and allowed for organizations to be successful when embracing inter-compatibility, agility and open source.   The next steps are coming in the form of Innersourcing and sharing of code bases, containerized and reusable application components and the new form of enterprise data architecture in centralized data apis and tools. For now check out our Open Source and Innersource PM Scope of Work.  It’s a simple template to get started building your next application with the Buildly framework and tools.  Standardizing on open and transparent tool sets and data API integration allows your team, your outsourcers, consultants and your cloud based products to interact and share data like never before, extending life-cycles and reducing costs across the board and making sure you meet and beat those deadlines and budgets as well.