14 reasons why software projects fail

From outsized expectations to fundamental feature changes, software development projects get derailed — or declared failures — thanks to a variety of project management and technical factors.

14 reasons why software projects fail

Every software project begins with big dreams and grand visions. Somewhere in an alternative universe, there is a project that fulfills every dream but all too often software projects in our universe stumble toward the finish line and sometimes cross it.  

Analysts might like to toss out random numbers to estimate what percentage of software projects fail, but these are wildly inaccurate by definition because, well, failure is not a binary thing. You can end up with code that runs well but no one uses. Or you can end up with code that won’t even compile. Sometimes you can salvage something useful from the flaming wreckage and sometimes it’s best to run away before it explodes.

When the smoldering mess cools, the autopsies begin and people begin to look for an explanation of what went wrong. Here is a list of the most common reasons software projects fail.

Too few team members

The effects of trying to do too much with too few programmers is pretty easy to understand. There are only 52 weeks in a year and people can only grind out so much code before they burn out. I once worked on a team where the manager thought the right way to squeeze more work from agile teams is to schedule each “sprint” so it began immediately after the previous one. No relaxing. No thoughtful pauses to figure out what was working and what was failing. Sprint 42 ended Wednesday at 1:59pm and Sprint 43 began on Wednesday at 2:00pm. They even scheduled retrospective analysis meetings after the next sprint had already started. Some clever guy tried to suggest that they be renamed “marathons” and soon found another job.

Of course, it’s very tricky to guess just how many programmers is enough. Sometimes the plan is complete and the estimates are accurate. Sometimes roadblocks and problems get in the way. It may not be the manager’s fault that the job doubles in size but if you don’t have enough people on the job, your project is likely doomed.

Too many team members

If too few programmers can be bad, too many could potentially be worse. The very same network effects that makes some social media platforms so essential can also doom a software project. More people mean more coordination and that means more meetings, taking time away from writing code. You can try to cancel meetings to give programmers more time to create, but if you don’t hold enough meetings, you’ll soon discover that Team A’s API doesn’t interface Team B’s microservices.

Too many programmers can sap each other’s time, sending the project into a swamp from which it never escapes. It would be nice if we could just throw money at a problem by overstaffing a project, but you can’t.

1 2 Page 1
Page 1 of 2
7 secrets of successful remote IT teams