Unveiling the Root Causes of Software Project Failure: Insights from Data Analysis
In the first article in this series, we introduced the sorry state of enterprise IT project success. Some two-thirds of IT projects end in partial or complete failure. Only one in 200 projects is completed on time and within budget, delivering measurable benefits. And 17% of IT projects are such colossal failures that they threaten to put the organization out of business.
In this article, we explore some of the reasons software projects have such a miserable success rate despite decades of experience and the availability of modern development methodologies, powerful technology stacks, and skilled practitioners.
The causes discussed here were gathered from various surveys of IT and business leaders.
Top Causes of Project Failure
Most survey results are in fair agreement as to the causes of software project failure. Every project is different, with its own set of challenges, but overall, the causes of project failure fall into a few categories:
- Lack of stakeholder involvement
- Unclear business objectives
- No consensus on the “definition of done.”
- Shifting organizational priorities
- Changes in project objectives after project start
- Inaccurate or incomplete requirements gathering
Other essential causes cited include unclear project vision, lack of risk assessment, and inaccurate cost and time estimates.
Lessons Learned
What conclusions can we draw from this list? What do these items have in common?
First, you will notice that none of these items is related to technology. Poor technology choices happen in IT projects, but according to the surveys, they are not a standard or primary cause of project failure.
It’s also clear that lack of developer ability is not a significant factor. Again, incompetent or inexperienced developers can and do get assigned to a project. There are many software developers, some better than others, but you can rarely blame a failed project on the developer’s skill.
What about the project manager? Some items on the list could be traced to the project manager, but not all of them, and not in all cases. For example, if the organization chooses not to share all relevant information with the project manager, resulting in inaccurate requirements or cost estimates, is that the project manager’s fault? It might or might not be, depending on the situation.
However, most, if not all, of the reasons listed above are related to what we call the “project environment.” This includes factors such as:
- Executive support: Is company leadership 100% committed to the project’s success? Are they allocating adequate funding and making the stakeholders at all levels available to work on the project? Moreover, have they made their support known to the rank and file?
- Organizational maturity: Is the organization ready for a project of this scope and complexity? Does the organization understand its strengths and weaknesses and how they affect project execution?
- Business processes: Many enterprise software projects are intended to solve a specific business problem or a well-defined set of issues related to business processes. Before applying a software solution, those processes should be examined critically to ensure they are as efficient as possible and fill a vital need. There is no point in automating a process you shouldn’t be doing in the first place.
Up Next
In the next couple of articles in this series, we will examine what organizations should (and, just as importantly, should not) do to avoid software project failures.
How Solution Machine Can Help
Solution Machine’s consultants have extensive experience with IT modernization projects, including application upgrades, cloud migrations, and more. By staying connected with our clients, we’ve been able to quantify the financial benefits, on both the cost and revenue sides, for projects we have helped execute.
If you are planning an IT modernization project, contact Solution Machine today to learn how we can help you estimate the financial impact of your initiative.