16 difficulties to avoid when purchasing enterprise software

Successful software purchases meet or exceed expectations; failures do not. Failures vary in degree from benign — e.g. those that are delivered late — all the way through to outright failures where the new software is dumped and the project may be restarted.

In this article, we look at common factors that make purchasing enterprise software so difficult. Being aware of these difficulties before starting a project can help you reduce their corrosive effects on the success of your next enterprise software acquisition.

1. Immature software selection process

While fast-growing companies are the exception, by their nature major software purchases are relatively rare events for most companies. Employees have not repeated the software evaluation and selection cycle often enough to develop a mature software selection process, which stacks the odds against success.

2. Overconfidence

When it comes to making a major software purchase, lack of experience with selecting that type of software can lead organizations to ask the question “Just how difficult can this be?” The core of this problem is simply not appreciating the complexity and detail that is involved in selecting the best software for the needs, and not understanding the business consequences of a poor choice.

3. Underestimating work

Enterprise software usually has thousands of requirements, and the magnitude of the software selection task is often severely underestimated. When requirements are missed in the initial analysis phase, they are discovered during implementation. This discovery triggers meetings to decide how important the requirements are, and what must be done about them. If these “new” requirements are important and can’t be met out of the box, then the implementation team attempts to satisfy them with system configuration, add-on modules, third-party products, developing code or business process re-engineering. Discovering too many “new” requirements causes implementation nightmares that take much longer than originally planned.

4. IT lacks business experience

What would you get if you asked a building contractor to design the interior of an upmarket home? You can be certain that an interior designer would do a far better job of the décor than a building contractor.

Because it is seen as their domain, IT is often tasked with selecting software. However, IT is more like the building contractor than the interior designer. While IT takes care of essential tasks like keeping systems operating, archiving data, security, backups, disaster recovery, and IT projects, they rarely have the business focus needed to select functionally adequate software.

5. Project scope not actively managed

While major software purchases can be seen as an opportunity to fulfill wish lists, all software purchases involve some degree of compromise. Organizations need to manage project scope (i.e. the range of features wanted) otherwise there is a danger of buying software that does everything but is not particularly good at anything. Also, lack of agreement on the project scope can cause analysis paralysis.

6. Doing the wrong work

When writing software, it’s common-sense to optimize business processes before coding them. But when purchasing software, it’s best to leave process optimization to the implementation phase of the project. All you need to do is to satisfy yourself that the new software can adequately handle your existing processes. The reasons are:

• Collecting requirements is a big enough task without the added burden of process analysis and optimization.
• You need the framework of a software product around which to optimize processes, otherwise you are operating in a vacuum.
• Software vendors often have best practices with their product which can significantly reduce the work needed for business process optimization.

7. Selecting software for the wrong reason

Major software selections are often made for the wrong reasons, such as these:

• The software worked well at my previous company, so it will work well here (typically made by a new executive).
• Software selected by committee.
• It did well in the demo, and the sales people are so good.
• Competitors use it (they may hate it, but you don’t know that).
• It is the market leader.
• Biased selection.

The only reason to select a software product is that the gap analysis showed it to be the best fit for your needs. Anything else and you are taking a serious risk.

8. Inadequate requirements

Requirements are the standard against which software is evaluated using a gap analysis. If that standard is deficient, is it any wonder that the outcome of a software purchase does not meet expectations? Well-written requirements include enough detail, descriptions, and examples so they can be properly understood in context. They also include who wants the requirement, how important it is to them and why it is important, which is essential information for the implementation team.

9. Functional fit not verified

The purpose of the gap analysis is to measure how well potential software products meet the organization’s requirements. This means rating requirements for importance to the organization, and then rating how well competing software products meet those requirements. If you don’t measure how well potential software products meet your requirements you are effectively “flying blind” when selecting software.

10. Using spreadsheets for the gap analysis

While accountants use spreadsheets every day, they do not run business transactions through a spreadsheet-based system. Spreadsheets can’t scale up to handle the volume, so accountants use systems specifically designed to manage transactions.

For the same reasons, spreadsheets do not handle the software gap analysis. There are just too many requirements. You need a tool designed to do the gap analysis. At Wayferry, we use our software evaluation app. You can also use a product like SelectHub.

11. User buy-in not created and nurtured

The time to create and nurture user buy-in is during the software evaluation and selection process. If buy-in is left to the implementation phase, it is too late and there is a serious risk of users rejecting the new software. A recent example of this occurred with a large pharmaceutical company. One of their sales employees described how a CRM system was forced on the sales teams, and how most of the salespeople ignored it. The outcome of this mismanaged CRM implementation was reflected by a 25% drop in their stock price and layoffs. That was an expensive failure!

12. Expectations not actively managed

A major software purchase can be greatly anticipated by employees, but if expectations are not managed, in their disappointment users can reject the new software. All major software purchases involve some degree of compromise, and it is vital for that compromise to be communicated to users before the purchase is made. Also, it is crucial that users see that the software selection decision was data-driven, and not the province of some executive or committee.

13. Trusting vendors

When requirements are unclear, ambiguous, incomplete or lack enough detail, software vendors make optimistic assumptions. Couple this with the natural enthusiasm of salespeople, and you have vendors overpromising and underdelivering.

Caveat emptor. It is the duty of buyers to be skeptical, and not just believe the smooth assurances of the vendor. Unfortunately for buyers, sales teams are skilled at making the software look like just what is needed. Remember that the software selection decision is made based on the analysis, and the demo merely confirms that decision.

14. Not auditing vendor responses

It is the duty of the buyer to verify that the software performs as expected before signing the contract. The primary way to do this is to audit the RFI / RFP response from the selected vendor to verify the software does indeed perform as claimed.

15. Skipping vendor due diligence

Due diligence should be run on both the software vendor and the implementation team. With larger software vendors like Oracle, SAP, etc., you don’t necessarily need to perform due diligence on the software vendor, but implementation vendor due diligence is critical. Smaller and more specialized vendors often implement their software with their own teams, so they must be run through the due diligence process.

16. Relying on procurement

Commodity products have relatively few requirements. Commodity purchases are where procurement teams use their negotiating skills and earn their keep. Enterprise software is at the opposite end of the scale, usually with many thousands of requirements. Procurement may:

• Treat enterprise software as a commodity purchase.
• Overlook the critical step of building user buy-in during the requirements analysis phase.
• Lack experience when negotiating cloud contracts or software licenses.

Conclusion

Success when making enterprise software involves using a well-defined process and not “seat of your pants” project management. When evaluating and selecting software, avoid the difficulties highlighted in this article, and you will stack the odds of project success in your favor.