Find the Software's Fatal Flaws to Avoid Failure

  • Written By:
  • Published:


When compared to the needs of your business, application software can have fatal flaws. These flaws may make it difficult if not impossible for the application software to run the business. If you do not understand the issues in your business that can expose fatal flaws in software—it can cost you a lot more than money to fix them and perhaps put your business at risk.

What is a fatal flaw?

If we list all the things that application software has to do, we get a very long list. The reality is that most application products that claim to serve a specific need (SCM, CRM, ERP, etc.) do most of the things on the list. But every business has a few essential requirements that do not appear in some or most products. Often, these requirements are vital to your success. These items are non-negotiable. This small list of requirements which are vital for your success but do not appear in most packages are your fatal flaws. The business does not have flaws; the software packages have flaws relative to your specific needs. The list usually makes up a small percentage of your total needs, perhaps a few percentage points, but without them, you will fail.

The fatal flaws are most often found in application areas but can also appear in technology areas. A common source for fatal flaws is industry standard practices. For example, all buying and selling in the meat industry uses a concept called catch weight (inventory is carried by both the package and the weight). If you are in the meat industry and your applications do not support catch weight, how do you conduct business? You may do business with a very large and powerful customer (the big three auto manufacturers, larger retailers, etc.) they may dictate how business is conducted. If your applications cannot accommodate the demands of these large customers, you have fatal flaws. If you are a make-to-order manufacturer who later services the product, any disconnect between manufacturing and field service can be a fatal flaw. Technology issues creating fatal flaws often align with strategy. If providing customer service through the Internet is part of your strategy, proper security may be a fatal flaw.

What is the impact of fatal flaws?

If you select a software package with fatal flaws, what happens? A company in Texas (US) spent millions of dollars and deferred implementation for over eighteen months adding a feature that was a standard industry practice. The feature was available in a number of other packages but they chose a package without that feature without even realizing it was not part of the package. After two years, a company in Rhode Island (US) eventually gave up on a package that did not allow for a fundamental concept in how the company worked with its customers and internal inventory system. A Virginia-based company (US) had to purchase, modify and install an unplanned and additional package to overcome a technical deficiency in the product they originally purchased.

How do you find your fatal flaws?

It may appear that finding fatal flaws should be easy, but it not always so. People know the business and therefore know what is required. However, since they work there everyday what the business needs may be considered common practice and part of any software product. What the people inside the company think is common practice across industry may not be so.

A recent court case points up the difficulty. A buyer communicated to potential vendors that they needed function "x". The buyer had a set of expectations of what it means to have x. The vendor who eventually supplied the software heard the need for x and applied a different meaning to the term x. During the entire evaluation cycle, the buyer looked at the surface of x and assumed what was underneath. The seller showed the surface of x and never went into details. Both parties thought they were communicating effectively. Both parties thought that the need for x was satisfied. Not until they were in a detailed pilot program did the mismatch in the detailed definition of x come to the surface. After over a year of trying, the project was canceled and the parties were in court. X was a fatal flaw that could have been avoided if the parties had realized the lack of communication.

Companies must seek out areas that potentially represent fatal flaws. But since the flaws exist in the software, not in companies, they often need help from people who are more knowledgeable in software packages. Seek out individuals with experience with software in your type of business. Ask companies in the same business about their experience and if they found any fatal flaws. Locate consultants with experience in your business. Even during initial discussions, ask them where the fatal flaws may lay for your business.

Ask vendors what they consider the unique needs of your business. If they say there are none, that package does not address the issues. If they point out some areas, that package does address these issues. If a vendor is really focused on businesses like yours, they will quickly point out the issues that belong on the fatal flaws list. If the vendor offers a white paper that addresses the unique requirements of your specific type of business—it is a very good sign that they understand and care about your kind of business.

How do you use fatal flaws to avoid them?

We often see the thick request for proposal. But if you know your fatal flaws, a different approach is called for. Since all vendors will have over 90 percent of what you need, you must focus on the few percentage points that may be the fatal flaws. Instead of sending vendors a four-pound RFP, send out the short list potential fatal flaws. Ask them to tell you if they do the items on the list.

Of the vendors who say they do the items on your fatal flaws list, invite them in for a demonstration. Ask them to show you each of the items on the list in detail, and nothing more. The vendor will want to do an introductory presentation and show you what they consider the best features of their product but you must stay in control—you only need to see the items on the fatal flaws list.

Any vendor who can prove they handle the items on the fatal flaw list should be invited back. Now they can do their introductory presentation and show you the rest of the product.

When asking for references, ask for companies who needed the items on your fatal flaw list. When doing a site visit, ask to see how the customer is doing the items on the list in question. Of course, to talk to end users who work in the area affected, not just IT people.


For any business, software needs exist which will prove difficult to satisfy. Application packages will have fatal flaws where they do not meet these needs. When evaluating software, start with the potential fatal flaws and continually look at the details surrounding them. You need to be comfortable with everything about a product, but if they fatal flaws are not avoided, it can cost time, money and perhaps success.

About The Author

Olin Thompson is a principal of Process ERP Partners, LLC. He has over twenty-five years experience as an executive in the software industry with the last seventeen focused on the process industries including the ERP, SCP, and e-business related segments. Olin has been called "the Father of Process ERP." He is a frequent author and an award-winning speaker on topics of gaining value from ERP, SCP, e-commerce and the impact of technology on industry. He can be reached at

comments powered by Disqus