14 reasons why software projects fail
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.
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.
Fundamental feature changes
In theory, developers like to consider themselves agile. That’s why they embrace the word. But sometimes agility can throw everyone off balance. It all depends whether the shift requires fundamental changes to the underlying framework. It’s easy to be agile when moving a button around or changing a color. But when it involves reworking the database schema or mucking around with sharding and replication, there’s no easy way to gracefully pivot.
Picking the wrong technology for the job
Even if you plan carefully and draw up the correct list of features for the project, things may fail if you use the wrong technology to build out the feature set. Databases, for instance, are designed to be as general and flexible as possible, but they have architectural limitations. If you try to push them to deliver something they’re not designed to do, you could watch them slow to a virtual halt when they scale. Or you may start off with a NoSQL database because they sound so cool only to discover later that you really need ACID-grade transactions to keep things consistent and the database doesn’t offer them. Oops.
Good planners draw up a list of features and prioritize them. But sometimes the priorities don’t line up with the reality of implementing them. In the worst cases, the most important features are also the hardest to create.
What are your developers to do? If they concentrate on the most important feature, they will make no progress and may end up delivering none of the functionality. But if they start knocking off the easy ones, well, they may end up with something that’s worthless.
Good planning requires more than a checklist. The architectural vision must take into account the needs and the cost of delivering them.
The market window closes
Sometimes it’s not the programmer’s fault. One of my projects was to turn a best-selling reference book into an app. The book sold like hotcakes in the years before the internet. The plan was to tap into that demand and make an interactive version that would let people sort and search through the data. The programming team delivered software that included everything in the book but was faster, prettier and much lighter than the book itself. But no one wanted it. We could barely give it away. It wasn’t the developers’ fault. The market just didn’t need or want the data any more. There were enough other sources and no one needed another app that would do much the same thing as news sites do everywhere.
Software projects can crater through no fault of the programming or management team. Sometimes an idea seems great, but the marketplace has moved on.
Bad architectural decisions
On one project, I was given the job of changing one number in one row in the database. When the user finished registering, I was to add the user’s id number to the latest order. It sounds simple, right? But the system was built on a microservices architecture and I couldn’t solve this by writing one line of code that would tell the database to UPDATE that column. Nope. The architectural plan was to add a new microservice call to the existing stack and even this was hard because my first microservice call needed to trigger another microservice call and so on.
In the end, the architectural whiz who created this network of microservices told me that it was all very simple and then he outlined a serpentine path through five different layers of the microservices architecture. So my job was to add five new API calls to five different microservices apps. Each of these was fully independent, so that meant adding five sets of automated tests for each layer. Each microservice API was developed by a different team over the years, requiring me to understand and emulate five different styles of coding. All to change one number.
The team was constantly being slowed down by simple requests like this. When I left, the five new API calls had been written and they had just been successfully tested together. But I never got to see them deployed.
Architectural decisions can last a lifetime — especially if your ego is thoroughly invested in them and you can’t change them. Project managers have to be ready to notice when the main architectural plan is not working so big decisions can be made. If leadership can’t notice when their plans go awry, the coders in the trenches will keep toiling away trying to make headway against an impossible headwind caused by a bad architectural model.
Blaming political factors for a technical failure may seem like a weaselly move, a dodge instead of a full-throated mea culpa, but it’s increasingly true. As projects grow bigger and span multiple organizations and layers, it shouldn’t be a surprise that factions appear and groups jockey for control, resources and ultimately power.
Political factions are different from real technical differences. There are often technical standards or code bases that do much the same thing in different ways. Take XML and JSON. Now that I’ve typed that, I can feel the fans of either rushing to explain why they aren’t the same and their favorite choice is the right one. They may be right, but when one part of a team loves one choice and another part holds the competing faction in the highest regard, well, friction is going to tear them apart.
This has grown even more common as architects split up applications into multiple, smaller services and APIs. Different groups will end up controlling these and they won’t always get along. If Group A likes JSON and Group B clings to XML, well, your team will either need to implement both or get one of them to change. All three are a pain for any team that must work with both Group A and Group B.
Betting on technology that’s not ready for production
Programmers love the latest new tools and frameworks. They want to believe that the new approach will sweep away all the cruft that bogs down the previous generation. They’re sure that the new abstractions and routines will unify, extend and simplify whatever it is that the code is supposed to do.
But often, the next generation is not ready for production use. The new features may be shiny and seem perfect, but there are often gaps that aren’t immediately obvious. Sometimes the code supports only a few file types or it interfaces with only a few databases. The others are coming real soon, they assure you, but your project needs to ship this month and “real soon” could mean six or more months before the features you need are complete.
Issues like this can doom software projects. The team bets on a new technology because it seems to solve many major problems and it often does. But somewhere along the line, usually in the final home stretch, the programmers discover that some part of the new technology is missing. Sometimes it’s not even documented. The developers of that code were going to get to it but, well, you know.
Betting on technology that’s soon to be outdated
It’s tempting to think like Goldilocks and blame technology that’s too old just as much as technology that’s too young. In my experience, the old stuff is usually more reliable and battle-tested, which is more valuable than a full feature set. But that doesn’t mean old technology is perfect. Features can be missing that are vital to your software project once it goes live. Worse, betting on old tech can cause you to miss out on future opportunities based on changes down the line. New ideas, protocols and file formats appear, and they can go unimplemented. And if someone from a competing team insists that you support some new protocol then the old tech will hurt.
Figure out how long it will take and then double it, the experts say. As if the proverbial experts have ever truly finished a project in their lives. They’re always offering opinions instead of writing code.
Deadlines are tricky. Many projects need to make it to market by a particular season or event. Yet when deadlines are first written down, your developers haven’t begun to discover the roadblocks and hurdles in their way. Then if the project slips and the event passes by without the software being launched, the entire project is seen as a failure even if the code is just about to run smoothly. Deadlines help everyone focus and pull together, but they also create expectations that can be unrealistic.
A good product manager surveys the competition before diving in but no one can predict what competition may appear out of nowhere. If new competitors introduce new features that you must duplicate, well, see the sections on feature changes and priority mismatches, above.
Rushing the process
Many software projects start as the vision of a person or team who wants to fix something. They come up with a phrase like “Snapchat for Y” or “Uber for Y” and then expect the product team to be as responsive as Snapchat or Uber. The problem is that figuring out the scope of the project, sketching the data flows and imagining the UI are often ten times as much work as writing the code. But the imagineers want to go from idea to code right away. (Why? You might blame developers who demo a new framework, database or serverless thingy with the promise that you can write a finished app in a few lines of code.)
The wireframes, database schema and user stories aren’t just hand waving, but an essential part of the job. But most people want to believe that a software project is just writing code to implement an idea.
False belief in the power of software
Sometimes the dreamers have unrealistic beliefs in the power of software to change the world. Many people imagined that social media would unite us all but somehow it’s just exposed fault lines that were always obvious. Many software projects begin with a blue-sky slide deck that promises to disrupt something and revolutionize some corner of the world. When shoving some bits in a database doesn’t save or transform anyone, well, people get angry, bored, confused or worse. Then they say the software is broken and move on. It doesn’t matter if the database is running smoothly and the app stores the bits in the right places. The software fails to deliver the magical transformation that everyone expected.
Many software projects can compile, pass QA, ship and even get decent reviews but ultimately fail to achieve any of the promises on the blue-sky slide deck because, well, those change-the-world promises are impossible.AbnAsia.org Software. Faster. Better. More Reliable. +84945924877 (Asia# Mobile, WhatsApp, Telegram, Viber, Zalo); +16699996606 (US# Mobile, WhatsApp, Telegram) [email protected]