Top 3 Reasons Custom Software Projects Fail

#customdevelopment#saas
reasons-software-projects-fail

TL;DR: Building good software is difficult. Faster, better, cheaper for custom software is a myth. If you want good software, find an existing customizable solution for your business needs.

The Sales Myth

Imagine if car companies only sold custom-designed cars. While the result might get you from point A to point B, if you're constrained by a budget and timeline yet still expect a high-quality product, you will be sorely disappointed. It's no different with custom software solutions. The solution might perform all of the business requirements, but it's not going to be pretty. IT leaders are becoming more and more tech-savvy. They understand that great software is an iterative process. Version 2.0 will inevitably be better than version 1.0. A salesperson might promise to deliver a custom solution that is faster, better, and cheaper than the competitors, but the harsh reality is that it is a myth. These three reasons will lead to a problematic or failed implementation. All hope is not lost, though! Unless your enterprise is in a very niche industry, there is likely a product that meets 90% of your requirements.

It's All About Scalability

It turns out that the unique requirement for the car you wanted was the interior and exterior colors to be red. You realize that for your budget and timeline, you can get a Toyota Camry. You'll pay an upcharge for the color customization, but it is a highly reliable car. The initial cost is known, and maintenance is reasonably predictable. Everyone is happy. I don't mean to continue repeating the analogy, but I am often shocked by IT leaders' resistance to go with a proven solution. When purchasing a scalable software product, you're only paying for the company's marginal cost to make a profit. With a scalable solution, you can indeed get faster, better, cheaper.

Nowadays, with software-as-a-service, you can usually try before you buy or not get locked into long-term contracts. SaaS substantially lowers the risk that your technology will be outdated in a few years or worse, introduce technical debt to your organization that ends up costing multiples more to maintain over the lifetime of your custom solution.

It's A Winding Road

No one understands your business as you do. Unique requirements can potentially still cause some barriers when customizing SaaS. Setting clear communication guidelines and providing sufficient time from knowledge experts is a must. It's also essential the vendors provide excellent service. If any critical business issue is found, you need a fast response time to avoid any negative impact.

Also, do not select silos. Modern software needs to be able to communicate with other solutions securely, ideally through a REST API. A solution can be a perfect fit for your requirements, but if it locks in your data, that's a hard pass.

In other words, make sure you have a good mechanic and don't buy a car that only runs on CNG. You're still going to have to work through issues, but as long as you plan and are aware of what to look for, it will be a pleasant journey.

Interested in learning more about DevOps for SAP?

Get the latest news, insights, and tips delivered right to your inbox.

Originally published April 5, 2021

Related Articles

production-ready-with-automated-testing

What's the Most Effective Way to Get Your E-commerce Platform Production-Ready?

Automated testing is vital for ensuring your e-commerce platform is production-ready and that customers don’t have to deal with unforeseen issues themselves.

#automatedtesting#ecommerce#sap
headless-architecture

Headless Architecture

Headless architecture has been around for some time but has picked up popularity recently, particularly in e-commerce, as the number of sales channels customers expect continues to grow. Any technology leader needs to learn the differences in architecture and understand the benefits and drawbacks of each. At the 20,000 foot view, there are three different architecture types.

#architecture#omnichannel
journey-with-sap-erp-devops

Our Journey with SAP ERP DevOps

The 2006 release of SAP ERP 6.0 predates Docker's initial release by seven years! The two technologies are geared towards different scenarios: think monolithic on-premise server vs. cloud-native microservices. What could be gained by combining the two? Software development teams outside of the SAP ecosystem are years ahead in leveraging DevOps ideas, automated testing/continuous integration, and modern version control tools (i.e., GitHub) to realize tremendous productivity and quality gains. Containerizing ERP would be a considerable step towards accessing these advantages for ABAP development.

#devops#saperp#docker