18 enterprise software selection risks and how to avoid them

Organizations always seek a return on enterprise software investments. All too often, that planned ROI doesn’t materialize because the best-fit software is not selected. This article examines the more common software selection risks, along with suggestions to alleviate those risks.

1) Unknown requirements

Unknown requirements are those that the software buyer doesn’t know they need. They usually surface as problems during software implementation, where workarounds can cause delays and cost overruns. There are two aspects to unknown requirements, namely breadth and depth. Breadth refers to requirements not covering specific functional areas. Depth refers to how detailed the requirements are in an area.

The solution is a requirements analysis of sufficient breadth and depth. Reverse engineering features from potential software products into requirements is a very powerful technique for finding unknown requirements. Once these requirements are known, they are factored into the selection and later the implementation. Since they are now in the project plan, they no longer cause unplanned delays and cost overruns.

2) Inadequate requirements

Some organizations just don’t appreciate the importance of adequate requirements development upfront. However, requirements are the foundation for selecting best-fit software. We all know what happens to buildings with inadequate foundations, and the result is the same for software selection. The solution to inadequate requirements is a comprehensive requirements analysis.

3) Lack of user buy-in

Disinterested or passive-aggressive users can put an enterprise software rollout in serious jeopardy. The solution is to include all significant users in the software selection process. An effective way of doing this is to involve those users in rating requirements for importance to the organization. Here the reasons why the requirements are important, how important they are, and to whom they are important are captured. When users see their names written on requirements, along with why those requirements are important to them, they feel involved which builds that critical buy-in.

4) Software scope

No enterprise software does everything, but sometimes organizations want it to do too much. The scope of the problem they want to solve is too broad. For example, we were helping a client to select software to run their business, and they wanted it to include document management. Although the products they were considering included this, it was rudimentary and did not meet regulatory requirements.

The scope problem is solved with a reality check against what potential software can deliver. Develop a comprehensive set of requirements, and then evaluate the software products against those requirements. If you use a normalized scoring system where 100 percent means every requirement is fully met, and no product even scores 70 percent, the scope of the requirements must be reduced. In the example above, the client removed the document management requirements from their project. The best-fit product score rose to 79 percent, and they made the purchase. See Comparing Products in a previous article.

5) Analysis paralysis

Here the selection and evaluation project expands to fill the time available. A primary cause of this is a lack of confidence in the selection methodology, especially the problem of unknown requirements. The organization is afraid of selecting the wrong product and ending up with a software failure on their hands. The solution is a well-defined software evaluation and selection process that consists of three phases:

1. Requirements Profile: Capturing requirements, and then rating them for importance
2. Rating products against the Requirements Profile: Capturing RFP or RFI responses, the gap analysis, and ranking the potential products
3. Selecting the software: The demo, reference checking, and the selected vendor response audit.

6) Accelerated time scale

Occasionally enterprise software selection projects have and accelerated timescale. This can be a management decision, a regulatory deadline or other reason. Whatever the reason, selecting enterprise software in a hurry almost certainly leads to serious problems and even potential software failures. The only solution to this problem is to plan and take the time to do a comprehensive software evaluation and selection.

7) Political interference

This happens when a senior executive forces the software selection decision. Reasons for this can range from slick sales people, previous experience with the software, all the way to bribes. The defense against political interference is to use a comprehensive data-driven evaluation to show where the favored solution is weak compared to the best-fit software. Of course, this relies on you being able to make the case persuasively, but at least you have the data to back up your claims.

8) Selecting the wrong software

The primary cause of selecting the wrong software is taking short cuts. For any enterprise software problem, there are usually only a small number of products that will fit the bill. With a little research, surely we can find the best match? Relying on luck is not a good strategy. Likewise, purchasing software because a competitor uses it is just as bad because you have no idea of how well it works for them or you. Imagine buying that software, only to learn the competitor is in the process of replacing it.

The solution to selecting the wrong software is to undertake a comprehensive evaluation and selection analysis upfront, which prepares the way for a successful implementation. For example, involving the users in the selection builds buy-in. Reverse engineering requirements from features of competing products finds unknown requirements early on in the project, rather than during the implementation phase where they cause delays and increase costs.

9) Selecting end of life software

When a vendor buys a competitor to acquire their customers rather than their technology, that software can go into end of life mode. The acquired product is milked for revenue, but development largely ceases. The best that can be done is to be alert for signs that a company might be acquired. If a company is being acquired and you have not yet made the purchase, that is a good reason to hold off.

End of life mode also happens if a vendor loses interest in a product or decides to exit a particular market. The best indicator here is the release history of the software. If no significant new features have been introduced in the last two or so years, that is a red flag and suggests the product should be avoided unless there is an exceptionally good fit with your requirements. Another indicator is the technology used to develop the product, e.g. would you buy an enterprise product written in Cobol today, even if it was a great fit with your needs?

10) Selecting bleeding edge technology

Boldly going where no one has gone before is the opposite of selecting end of life products. Let’s face it, if the software is new there are always elevated risks of things not working as promised. Ask if your organization can accept these risks. A way to uncover such risky products is to search LinkedIn and the job boards for references to them. If few people mention the software, that is a sure sign of low market penetration, and something to be avoided in most enterprise situations.

12) Selecting the wrong vendor

When you buy from companies like Microsoft, IBM, Oracle there is little risk of them going out of business. Unfortunately, larger vendors are seldom hotbeds of innovation. If you want more innovative software, you may need to consider smaller vendors or startups. Then there is the risk that these companies are not what they appear to be.

The solution is vendor due diligence. Recent investments in the company are a good sign because investors will have done the research. Check the vendor’s references by speaking to customers. Look on LinkedIn for people who mention their product. Look at their corporate blog, tweets, their reputation on Glassdoor, etc. Look at the resumes of the management team. (If the company website doesn’t  list the management team, that is a red flag.) Use something like Google maps to check they have a physical address. Again, no evidence of the vendor at a physical address is a red flag. None of these individual items is critical, but when many of them add up in the wrong direction, that suggests avoiding the vendor.

13) Non-compliance risks

Selecting the right vendor means minimizing the risks of vendor non-compliance, which can put your business at risk. For example in the case of cloud software, vendor security and IT governance should not compromise your business. Generally, vendor compliance with appropriate certifications like SSAE 16, ISO 27001, FINRA, HIPAA, 21 CFR Part 11 and so on minimize these risks.

14) Underestimating implementation times & costs

After the enterprise software has been purchased, implementation can begin. If you supply the implementation vendor with the detailed evaluation of how the selected software meets your requirements, they can provide work estimates that are more accurate. If a thorough requirements analysis uncovered all unknown requirements, there are few, if any, unpleasant surprises during implementation.

15) Underestimating system importance

There is always the temptation to dismiss back-office systems as non-critical. However if new systems like payroll, invoicing, accounts receivable have problems, you will find out about them soon enough! The solution is a thorough requirements analysis with adequate input from the system users. Any system that is critical to the operation of the business needs to have the work done up front to select best-fit software.

16) Business disruption

Since an enterprise software deployment will disrupt business, it is wise to examine the risks and have mitigation strategies in place. For example, adequate training of users is critical. In general, any project that starts with a comprehensive requirements analysis and selects best-fit software will minimize disruption risks. Head in the wrong direction and you can pay the ultimate price, as did Foxmeyer Drugs when a failed ERP selection forced them into bankruptcy.

17) Overconfidence

Overconfidence is underestimating the difficulty of selecting best-fit software for an organization’s particular needs, or worse, just “winging” the selection process. When this happens, the opportunity to maximize ROI is missed. Realize that you won’t know the right system when you see it, and that judgment can be swayed by persuasive sales people. Use a data driven software selection process.

18) Risks to your job

Finally, a more personal risk. If the software selection fails, you could be at risk of losing promotion or even being fired. The failed project can even tarnish your reputation.

What is not in this article

Software selection risks overlap those in several other areas, e.g. implementation risks. In the interest of keeping to a reasonable length, this article does not include the following:

• Implementation risks, including outright failure. This article focuses mainly on software selection risks.
• While management buy-in is a project risk, it is not really a software selection risk per se.
• Pilot projects are not included because they function to verify a selection, rather than to make it.
• Contractual risks. Some enterprise software vendors, especially larger and more aggressive ones, include very biased terms into their standard contracts. These risks are more part of contract negotiation than software selection.

The recurring mitigation theme through all of these risks is that a comprehensive requirements analysis followed by a software selection based on the product gap analysis is the best way to minimize software selection risks.