Why Software Development Projects Fail

Software project success rates are all over the place.

The numbers vary between industry reports, but regardless of source, the odds aren’t in your favor.

BCG estimates that 70% of digital transformation efforts fall short of meeting targets. A 2020 CISQ report found that the total cost of unsuccessful development projects among US firms is an estimated $260B, while the total cost of operational failures caused by poor quality software is estimated at $1.56 trillion. The Standish Group’s 2020 CHAOS report estimates that around 66% of software projects fail.

Those are pretty troubling stats if you consider the vital role that IT and software solutions play in terms of how we work—and live—today. However, it’s worth noting that the best chance of success is understanding why software projects fail in the first place and making sure that risk mitigation is a big part of the planning process.

Below, we’ve outlined some of the top reasons for project failure—and how to avoid these costly mistakes.

Unrealistic expectations

One of the main reasons for project failure has to do with a lack of understanding on the client side. In our internal survey, many 3Pillar software development experts mentioned this was one of the primary reasons that a project might not succeed.

The problem is, we often see customers that don’t know how the software development process works or how long things are supposed to take. They don’t have a clear understanding of how the software integrates into the overall digital landscape of the organization.

So, as you might imagine, they often ask for projects to be delivered ASAP, at the lowest price point and highest quality.

Naturally, the outcome is disappointing. Either the product comes in later than the target deadline or doesn’t meet basic requirements or quality standards.

Part of the problem is, decision-makers make decisions alone—and if that person is, say, a VP or C-suite executive with a limited understanding of what the development project actually entails, there’s going to be a disconnect between the vision and the reality.

3Pillar’s Jaime Salame says, “most clients have a rough idea of what they want to accomplish, but they don’t know the path or the process to get to it. This can be translated as not having a healthy backlog. We provide best practices, a path, a way to measure it, and we deliver.”

Bottom line: it’s critical to be realistic about timelines and budgeting. Complex projects take a lot of time and a ton of planning. Talk to internal stakeholders, your in-house development team, and engage your external development team in a cooperative planning process.

Lack of Technical Documentation

Another reason for project failure? A lack of technical documentation. According to 3Pillar DTS, Javier Trevino, “projects will surely fail if they don’t include technical documentation for the high-level architecture and tech stack, as well as a detailed roadmap that guides design, development, implementation, testing, and deployment efforts for the proposed solution.”

Often the clients themselves either don’t know what they’re looking for, or they have a hard time communicating their vision to the development team. Either way, that lack of clarity makes it challenging for projects to move forward.

Without a guiding vision and a clear understanding of how a software solution should be built, it’s impossible for business leaders to estimate how much a project will cost and what kind of resources are required to make it happen.

The software architecture should always address the most critical functional and non-functional requirements, which are key to helping business leaders make smart decisions and, ultimately, set the stage for project success.

Angel Moreno says one of the biggest signs that a project is in trouble is when “nobody on the business side cares about well-defined requirements.”

Scrum Master Rodolfo Carmona adds, “without documentation, teams can’t follow a uniform set of standards or quickly apply new approaches. Most of the time, when business requirements change, the development team ends up spending a significant amount of time researching directly inside the codebase to gain an understanding of the effort involved. As a result, they often miss some essential business rules and need to go back and fix them later.”

Avoiding this problem builds on our last point—business leaders must first set specific goals and establish realistic expectations around how the project is likely to impact the business. That first step is more about looking at software projects from a high level, while here, you’ll need to work with internal subject matter experts to capture requirements.

These are the people who use the solutions each day—think salespeople, accountants, product managers, customer success teams, etc., but also those who work on the technical side: developers, engineers, testers, DevOps teams, etc.

Javier Trevino adds, “Unclear requirements result in a lot of change during sprints, which prevents team members from completing story points, and results in implementing an unstable, patched end-product.”

If requirements do change, it’s important to address them in the next sprint rather than to change the game mid-sprint.

Resistance to Change

People want to change—in theory. In practice, however, resistance comes from all sides.

3Pillar’s Cesar Gutierrez says many organizations struggle to move away from legacy systems and processes. “One of the biggest barriers to success happens when clients “migrate from old technologies to new ones. There is a willingness to change, but there’s also the challenge of developing an understanding of how things will work moving forward, and many times, it’s hard for people to let go of previous practices.”

Angel Moreno adds, “Processes are another big one. Many companies are stuck in some ‘very old ways’ when it comes to internal processes. So, it’s always a challenge to help clients adapt to new standards and stick with it.”

Combating resistance to change is one of the main reasons that we talk so much about nailing down “culture” before implementing new processes or solutions. Without the right culture in place, it’s hard to get buy-in—particularly among front-line employees who may not have a say in the decision-making process or middle managers tasked with leading change management efforts with little context for why they’re doing this.

While there’s a lot more to it than that, it’s essential that everyone—at every level—understands why they’re making this change and can take ownership over their role in helping the company achieve critical objectives.

Forgetting About the Customer

Customer-centricity is critical—but many organizations struggle to ID customer needs/use feedback to inform business decisions.

Pre-Sales Engineer Denisse Vega says the source of many software development project failures stems from situations where “engineers don’t understand the end-user. “

Software Engineering Lead Paul Estrada says he often sees clients struggle to build “features that users truly want and provide a way to boost business revenue.”

Ideally, the business strategy places the software in a competitive and profitable place. It involves focusing on making continuous improvements to the end-user experience, differentiating your solution from the competition, and using real user feedback to inform decision-making.

Lack of Testing

Most people understand that software needs to be tested for bugs. However, when there’s a time crunch, it’s often one of the first things to be abandoned.

Unfortunately, that means the software might not work as anticipated and could lead to some disastrous results—angry customers, service interruptions, security breaches, etc. —and expensive, time-consuming fixes post-launch.

Testing should be embedded at each stage in the development process, which is standard in any Agile or DevOps practice.

Free!

A Business Leader’s Guide to Software Development

Download Now!

STE Octavio Islas says, “sometimes automation testers try to improve things by building new frameworks or utilities. It’s a good practice—if there’s enough time. But, if it wasn’t part of the initial plan, testers are being diverted from the tasks required to complete the project.”

He says the problem isn’t that they’re trying to improve tools and processes, it’s that they prioritize the act of improvement over the actual testing.

“There is an unlimited number of areas that can be tested. The quality assurance team needs to understand which of those areas are essential. It’s common for priorities to change based on what’s been uncovered in recent builds, as well as what changes the development team has made to the codebase. Because the target is always changing, testing needs to be continually adjusted.”

While requirements are always evolving, testers need to remain on task during each sprint to deliver projects on time.

Final Thoughts

There are many reasons why software development projects fail, but it’s crucial to understand that there’s a lot of overlap between these risks. They all link back to the same root cause—poor planning.