10 Reasons Why Software Projects Fail

Software projects fail more often than not, and the result is a waste of nearly $75 billion dollars.  

There are alarming statistics around why software projects fail. Executives admit that projects are doomed from the start,which translates into 75 billion dollars in abandoned software projects. When projects that could transform the way we live, how we interact, and how we experience everyday life, aren't shipped because of failed software, that's a problem.  

In no particular order, here’s our list of the top 10 reasons software projects fail:

10. Absence of good Project Manager (PM)

If there's no Project Manager, things slip through the cracks. Features don't get announced, things are built the wrong way, and the project gets off track.  

The value of a good PM is immeasurable.

A good PM is the glue between engineering, sales, marketing, and clients. They're able to navigate unexpected issues that arise.

Good PMs must have deep technical expertise to be able to be the glue, coming from design, QA testers, etc. PMs need experience communicating between the different departments.

Moreover, technical people must learn how to talk and work with other people. The smarter someone is, the more they tend to assume that they can take on all roles when it's more difficult to take on a role of a good PM. The industry can do better at teaching engineers the value of the business side.  

9. Setting Unrealistic Expectations

Everyone wants to ship and be valuable to your tribe. That means we say yes to too many things. It's important to look at not just technical time but communication time and how long it will take to roll out. That helps align expectations better.  

Unrealistic expectations come from missed scope and missed activities.  

It's up to developers and clients to work together to know what's realistic. Unfortunately, there's a lot of misinformation in the field about how long projects will take.  

One of the most troubling things about the software industry is that it's become a la carte. Fundamentally, software can't be built like that. There are too many things to be built off the shelf.  

When people are shopping for software, you should be looking at competitive advantages, not the fastest and cheapest path to completion.

 8. Fixed SoW or Scope Creep

We should have the opportunity to go with the flow and make changes as needed. Sticking strictly to an SoW is a fool's game. We always add flexibility clauses. Change orders are time intensive, costly, and prohibited to having good relationships.  

Flexibility is how projects succeed.

Projects either succeed by extreme rigidity or flexibility. Anything in the middle where you're flexible on some things and rigid on others, is destined for unmet expectations.

7. Poor Communication - Not speaking the same language

It all comes down to how effective your communication is with your client or PM. Communication can be improved using Domain Specific language. When you don't have a shared vocabulary, it allows you to communicate effectively. We're able to speak using our lingo without confusing each other.

Additionally, people have to trust what each other is saying. You build rapport over time by consistency. The more we communicate the better we are at it. The more frequent and consistent communication we have, helps people understand each other and notice breakdowns in communication. It's more important to be honest than silent.

6. Lack of Talented Engineers

The worse your engineers are and the longer your timeline is, the more likely they are to build something unmaintainable. PMs are, again, so important because you have to manage your good engineers well. Even with good engineers, there's no guarantee that you're going to build anything good.

You need good engineers plus good leadership from a project management perspective.  

Talented engineers know how to think through problems, how to leverage off the shelf technology, how to automate, etc. Having good engineers will 10x your project.  

5. Misaligned Goals

One side wants to bill as many hours as possible, the other side less. When your goals are aligned with your customers' expectations, you change the metrics that you pay attention to.  

As soon as the money figures itself out, don't measure it anymore. Focus on the things that really matter. For example, a weekly standup meeting is more effective than tracking hours.


4. Team Consistency

A lot of companies look at freelancers to leverage complex projects. It's difficult to keep freelancers or even your internal teams together for a long time. The consistency piece plagues everyone. It's hard to retain people in the tech industry.  

One approach is to use freelancers and supplement those with full time people. The full-time people become your anchors with vested interest in your company and stay around longer.

Another approach is cultural documentation. Being very communicative of the things that you're doing. You want to automate things as much as you can so new people don't have to learn as much.  

Finally, get rid of toxic people on your team.

You need people that want to work with clients and be on the projects.  

3. Slow Starts / Long Legal

For any project, one of the key factors isn't velocity, but momentum. When things run out of momentum, velocity drops off. It's hard to succeed when there's no momentum. There are things you can do upfront like kick-offs and workbooks to keep people engaged. These are critical for project success.  

2. No Discovery

You've got the requirements, but there are so many unknowns. It's so easy to detail some of the requirements, while others are much more difficult. Clients tend to think that discovery will be expensive. However, taking the time upfront to understand the project and put together a cohesive project plan is crucial to success.

Andrew's rule of thumb: If you can't communicate the vision to someone non-technical, then you shouldn't build it.

1. Earning your Complexity

In the beginning of projects, you don’t necessarily know how many users your project will serve. It's about building the flexibility that will serve 10,000 users but work for 1 user. When you build in unnecessary complexity, it takes more to support. You can't run a lean shop on complex architecture.

It's building what you need today with flexibility to get to where you want to be in the future. 

You're going to get complexity with success, it's how you handle the complexity, move forward, and how you lead your complexity while moving forward.  

Thanks for reading through!

We want to share our best Thoughtful Software Practices with you in a free E-book. Grab your copy by subscribing to the Thoughtful Software newsletter.

Build Thoughtful Software
Andrew Wolfe
Written by

Andrew Wolfe

Andrew has an M.S. in Computer Science from Georgia Tech University. But he prides himself over 10 years of experience working in the software industry for well-known companies such as Diebold, Tableau, Explorys, and Onshift. After years in the corporate and startup worlds as well as running his own consulting firm, Andrew realized he had to do more to improve software products and practices. From that, Skiplist was born. Skiplist is the opportunity to focus on thoughtful, quality software and change the software consulting industry.