What are the Major Software Project Failure Factors? 

On the market since 2013, APP3null is one of the pioneers of the app industry. In these last 6 years of our work, we found that out of over 90 projects, only 3 failed technically in one form or another. Yes, you heard us right – 3 out of 90. Of course, this does not mean that the rest “went through the roof”. No, there are economically successful projects and less successful ones. We often have no influence on that. But technically speaking, only three projects have failed so far. Why? What causes Software Project Failure?

We strongly believe that our positive experience is not representative of the industry. On the contrary, we have often “rescued” projects from customers who had reached a dead end. These customers were still lucky that they had not spent their entire budget with the wrong provider. The number of unreported cases should be much higher and I personally assume that 50% of software projects are not completed successfully.

So what are the main reasons and how can you successfully avoid this fate?

Enclosed are reasons of Software Project Failure :

• Wrong contractor
• Lack of cooperation
• Wrong technologies
• Technically too demanding
• Insufficient budget

1.   Software Project Failure: Wrong contractor

This mistake is the number one reason why many clients end up with a bunch of bad code but no finished product. The software development market is huge and confusing; the price is dumped as if there is no tomorrow. For the layman, it is very difficult to distinguish who can actually deliver and who is simply blinding.

There are hundreds of companies in South Asia whose business model consists solely of luring naive customers with hourly prices below $10 (!) and delivering nothing in the end.

But also in this country, there are enough black sheep. Often, companies in the DACH region take on projects in order to outsource them abroad, without the customer being aware of it. Outsourcing was and remains associated with risks, which affect professional agencies just as much as inexperienced individuals or companies. The result: they bear the same risks as if they were outsourcing their project themselves, but pay significantly more.

Projects often fail because of freelancers. Indeed, there are situations where freelancers are a perfect solution for your requirement. However, not always! In larger projects, where many technologies are used, it is very risky to hire a single freelancer. What if he gets sick? What if he “doesn’t feel like it” anymore? Who controls the quality of his code? Is he really working only for you or on five projects in parallel? In fact, several times we have saved projects that were started by freelancers but never finished.

Now, how can you minimize these risks? Rules of thumb:

• For large projects, hire companies, not lone wolves.
• If something is too cheap, it has its reasons. Good app developers cost a lot of money. If an offer is too cheap, better stay away! Developer wages have also risen sharply abroad and are almost at the level of the average German wage earner.
• Be extremely careful with outsourcing to distant countries. If the worst comes to the worst, you will not be able to go to any court. Legal guarantee? No way! Ask local agencies first. If their offers are too expensive, ask these agencies if they can recommend a reliable company abroad. Usually, most DACH agencies have a few foreign partners and are happy to forward low-budget projects to them.
• And of course the usual steps: check references, quality of projects, contact old clients from the provider and ask for experience. Read the negative comments on freelancer platforms.
• Find more details here, on how to find a suitable provider for your project.

2.   Software Project Failure: Poor collaboration

This is why one of our projects failed. At the start of the project, the contractor and the client are best friends. The contractors are motivated, polite, still in a kind of “sales mode”. The question is whether it looks that way at the end of the project. Often it doesn’t. But why?

1. Be honest with yourself: How much time are you willing to invest in the project? Software projects are time-intensive and need a lot of input from the customer. Are you available during the day? Are you willing to answer the “stupid” questions of the app developers? After all, you’ve already explained everything. It can’t be that people still haven’t figured it out, right? Yes, they very well may, so breathe in and out and explain again. The software project will not run without you.
2. You have another technical partner or your own developers and you want them to work with the agency. The technicians will already find a common language. I get it… But you forget that the technicians often don’t know what to do with each other. I mean, they are developers! 🙂 Everybody is the best, everybody finds his/her technologies and code better; the other side rather does nothing and he/she has to do everything.
3. Add to that the workload of the technical staff on your side. Of course, it is very smart to promise the agency that you will finish e.g. backend in two months, forgetting that your IT department has no capacity at all.
4. It also happens more often that feedback loops are extremely long. If you don’t show motivation and drag out the project from your side, the developers will lose motivation as well and in the case you can always say, “we waited for you for two months, now you want us to finish in a week?”

Our recommendation:

• The product owner must schedule sufficient time and be available during the day.
• Communication between the internal and external IT teams must be moderated. Do not blindly trust that “the technicians will find a common language”.
• Provide your own input in a timely manner and insist that your counterparty do everything in a timely manner as well.
• Be nice and polite to the developers, we are human too….

3.  Software Project Failure: wrong technologies

This mistake is very common. The software industry is extremely dynamic, creating new technologies, languages, and frameworks every day. App programmers are often eager to experiment and clients are frugal. When these two preferences collide, things get adventurous, and as is often the case, such adventures then have consequences. The typical case:

A new framework for mobile apps is coming onto the market. The client is promised that by using this framework, the costs would be significantly lower than native app programming. Afterwards, it turns out that the community behind the framework is still in its infancy, there is a lack of libraries and support, and the framework may be completely abandoned by the operators. But even with established frameworks, like Xamarin or React Native, we’ve seen developers end up in technical deadlock time and time again. There are a variety of reasons for this that I won’t go into here, but it happens again and again, unfortunately.

Our recommendation: experiment elsewhere instead. In software development, it has paid to use proven technologies. Don’t run after all the latest trends, stick with “oldies but goldies”. Only when the technology has actually established itself does it make sense to use it.

4.   Technically demanding

We also had to make this sad experience. Programmers are often too self-confident and promise a lot without actually checking the feasibility beforehand. This happened to us once ourselves. We tried to link two very different systems and synchronize the content, which was not directly supported by any of the systems. Result? 6 months of work, thousands of invested hours on a fixed budget. At some point we gave up and closed the project deep in the red.

Recommendation: for the technically challenging matters and for topics new to the app programmers, it often makes sense to validate the technical feasibility. It is recommended to have the core function developed as part of a preliminary project, a kind of prototype, so that it can be tested whether it is technically feasible. If this core function doesn’t work technically, then the rest of the project doesn’t make sense either. So for little effort, you’ve determined that further investment in the project doesn’t make sense.

5. Software Project Failure: insufficient budget

Software projects are not always easy to plan. The larger the project, the more likely it is that many aspects will be left unconsidered at the beginning. As the client, you would therefore always need to include a buffer. The costs quoted by the vendor are rarely the amount that will be spent at the end of the project.

Besides, every project needs support and maintenance and of course further development, new features, etc. What happens if you have little wiggle room on the budget? Nothing good:

• Your change requests cannot be implemented
• Further development of the project is not possible
• The supplier realizes that there is not much to get from you, that the project is more likely to fail due to lack of budget and that he/she will never get a follow-up project from you again. Thus, motivation and quality fall.

Recommendation: Always include plenty of buffer. If the provider says 50,000 euros, then have 70,000 euros ready.

Negotiate carefully: Don’t let yourself be ripped off, but don’t reduce the budget to the level where it’s just about worth it for the provider to develop. The app developer must be motivated, and to be treated like royalty, you must also pay royally.

 

Find out here, how to finance your app project.

Software Project Failure: Conclusion

Customers often pose a question: What causes Software Project Failure? We hope this question has been at least partially answered in this article. There are a variety of reasons why your software project can fail. In our experience, the five reasons listed above occur particularly often. Stick to our recommendations. If you have any questions, just give us a call; no one has ever died from good advice.