Why Do Software Projects Fail? The Answer Is Simpler Than You May Think

Learn about the reasons for software project failure, and find ways that your business can avoid becoming a statistic. Here’s a hint: great software development is all in the communication.

Editor’s note: This piece was originally published in 2014. It’s been so popular that we decided to update it in 2019.

A 2008 study by IAG Consulting examining success rate of all IT projects, including software development, claimed that 68% of these projects fail. How could this possibly be? This number is staggering!

When it comes to software development projects, failure can oftentimes be attributed to a disconnect between what customers expect, what developers expect, and what each side thinks the other expects. The way a developer thinks about what they do is often different from how the client, who needs to hire the developer, think about what they do. Could these misaligned expectations be the root cause of such a high number?

The IAG report specifically mentions the lack of business analysis as a leading cause of software project failure. Thus, the goal of this post is to bridge the disconnect and help clients of development firms avoid falling into the 68%. No matter how flawless the code is, if the end product doesn’t help the client meet their goals, the development will be considered a “fail.”

The Main Reason Why Software Projects Fail: Communication

When it comes to software development, the biggest contributor to failure has nothing to do with technology at all. It’s a lack of business analysis before the development begins. Analysis includes asking questions upfront, and getting to the root of the matter – the “why” behind the development goal.

As a prospective client, you may be surprised at the sheer quantity of questions asked by developers before work on your project begins. For example, back in the day when a prospective client said they made widgets and needed a software tool to track their widget inventory, the project was accepted at face value. But in today’s highly-technical world, there are many interdependencies between business operations and software that must be accounted for. There are also many questions.

Let’s consider the widget maker’s inventory challenge. Rather than diving right in, a prudent development team would start asking questions:

• What is it about the current inventory process that is broken?
• Is it really broken, or is something else in another part of the business creating the problem?
• Will fixing the inventory system cause something downstream in the process to break?

Within the scope of the widget maker’s literal request alone, there are many interdependent factors that need to be considered. To stakeholders from the widget manufacturer these questions may at first appear like they have nothing to do with the project’s intrinsic goals of inventory management. Yet, it’s often true that the best questions at the beginning of any software engagement are non-technical.

• Why do you make widgets?
• What are the challenges of the widget market?
• What do you hope your business will look like in 3-5 years?
• What are your ambitions? Are you just trying to sell more widgets, or to expand into other product lines? Do you hope to disrupt the widget industry with a new uber-widget?

As a client, you may wonder why this is any of the developer’s business or concern. What do the answers have to do with inventory management? Maybe nothing, or maybe everything. What if a lack of effective inventory management isn’t the problem at all? Maybe it seems like the true problem, when it’s really just a symptom of a larger unaddressed challenge keeping the business from meeting a greater unrecognized potential. Until the questions are asked, the developer cannot know.

>>LEARN MORE: Five steps to achieving clarity in your software requirements

Avoiding Software Project Failure: The Discovery Journey

This isn’t a case of the salesman thinking he knows what the customer wants better than the customer does. It’s a true journey of discovery that a client and software developer must take together. The problems custom software addresses are very rarely confined to one compartmentalized silo, and neither side can understand what to address until fundamental questions are asked. Asking questions helps increase understanding, which helps avoid one of the major reasons why software projects fail.

It’s important to be patient when your developer asks probing questions that seem to go beyond the immediate needs of your project. That’s a good sign. A development team that doesn’t ask questions is likely to be uninformed or not care much about your project.

“Are we truly addressing the needs of your business, your current customers and the market you’re in at large? Or are we at risk of leaving you among the 68% of software project failures?”

How To Combat The Reasons Software Projects Fail

In addition to asking questions, there are some other things you can do to avoid software development failure. The 6 tips below will help set you on the path to success no matter what project you are enlisting a development team for.

Forget Technology

While forgetting technology in a development project may seem counterintuitive, thorough business analysis at the beginning of a project is the best way to assure success at the end.

Remember the Humans

To ensure you’re building a product users need and want, get the requirements right through probing questions, precise answers and walking step-by-step in a user’s shoes.

Keep the Conversation Going

Communication shouldn’t stop once the upfront questions are asked, but should continue through ritualized communication is the most effective way to manage change and move the project forward.

Think Small

It’s easy to “dream big” and throw around lots of ambitious ideas, yet software projects with limited scope and only the most essential, user-focused features have the greatest chance for success.

Try It Before You Buy It

To ensure the most successful user experience and validate requirements, there Is no substitute for a working prototype.

You Can’t Afford Not To Test

While it’s tempting to rush to market the second your finished product is in hand, it’s essential to launch a suite of computer-automated tests first to detect bugs and ensure product quality.