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.
