A look at 25 Years of Software Projects. What can we learn?
History of Success and Failure
25 years ago just 16.2% of all MIS projects were completed on time and within budget according to something appropriately called the CHAOS report by the Standish Group. 52.7% were late and over budget, and 31.1% were outright cancelled. The top two reasons then were lack of user input/involvement and incomplete requirements. What has changed over 25 years?
Standish recently reported an improvement from 16.2% to 29% success rate. Certain projects were as high as 62%. I’ll get to that later.
Despite this improvement, that’s awfully low!
Success and failure rates in other industries?
Let’s look at the Home Redecorating/Remodeling industry with kitchen and bathroom projects. A 2013 study found that Redecorating projects were over budget 35% of the time, and Remodeling projects were over budget 53% of the time (1). That’s not very good either.
Why did Projects fail then vs. now?
Getting back to software projects, have the reasons for failure changed?
A 2015 Wrike Report looked at the use of a methodology and found those that did had more success, 38% vs. 31%. Those that USED a methodology were still 72% behind schedule, 29% didn’t meet scope, 32% didn’t meet quality requirements, 40% didn’t meet expected benefits and the numbers are even worse for projects that did NOT use a methodology.
A 2017 report by the Project Management Institute (PMI) found that having an “actively engaged executive sponsor is the top driver of projects meeting their original goals and business intent”. You may have noticed that Executive Sponsorship was not in the top two 25 years ago. But it did come in the next set of reasons. I suspect that the expectation is no longer that a project must have complete requirements before a project starts because it’s not possible with the pace of change and Agile is a methodology which fortunately addresses that. What about executive sponsorship for project success?
Irina Abramson, co-founder of Speed & Function, knows that it’s important for executives to better understand software development. He says to look at the differences of scientific research versus construction. “Software engineering is more like scientific research and less like construction (although it’s not as chaotic as science). Imagine you have to take a new drug to the market: you can spend millions and only get research papers as the outcome. One more analogy: A software project in its early stage is like an iceberg where you see the tip above the water and the underwater shape/size can’t be predicted.”
Speed & Function has developed a project management process which has been the key to successful projects for their clients. It covers five main areas:
- Project execution based on experience releasing over 200 software projects
- Agile methodology which emphasizes direct communications between client and delivery team, extensive collaboration and transparency.
- Aggressive Risk Management keeps issues from derailing the project. Extensive scope negotiation allows hitting budgets while making changes to adapt to market realities that change and are better-understood every day.
- A Dedicated QA team that is ⅓ of the team, does early QA testing, automates it to run throughout the project cycle
- A Team of Experts continually learning with shared expertise of new technologies
I’m curious to see whether readers feel that their success rates confirm these numbers. I will talk in a future post about whether failing projects can be rescued.
Related Material
1995 – Standish Group Report CHAOS Report
2005 – Harvard Kennedy School Top 10 Reasons Why Systems Projects Fail
2015 – Wrike Complete Collection of Project Management Statistics 2015
2015 – InfoQ Excerpts from the 2015 CHAOS Report
2016 – Forbes Are These The 7 Real Reasons Why Tech Projects Fail?
2017 – Project Management Institute Pulse of the Profession
(1) Many projects had no budget so the percentages were adjusted after removing respondents who had no budget and only look at projects with a budget.