Why selecting enterprise software is so difficult

By some accounts perhaps up to 70 percent of enterprise cloud or COTS software projects are failures, where a failure is defined as delivering substantially below the ROI that was used to justify the project. While the technical press regularly features software disaster stories, these outright failures are only the tip of the iceberg. More frequent are the partial failures where the software doesn’t work as hoped but is not bad enough to discard and start again. Of course, most people don’t like to talk about their failures, so these tend to be quietly forgotten.

Selecting enterprise software is a more formidable problem than most people realize. This article examines why software selection projects are so often underestimated.

Overconfidence

Overconfidence is one of the largest contributors to software selection failures. It causes a blind spot, trapping people in their areas of experience and expertise. Even if you implement several different systems, you know only those systems, and you know only the most recent system well. Because there is such a rapid pace of innovation in the market today, it is almost impossible to know all the potential products well enough to select best-fit software without a thorough requirements analysis followed by a gap analysis. Overconfidence appears as bias, causes people to underestimate the work that needs to be done, and prevents them from selecting best-fit software for the particular needs.

Underestimating complexity

Most enterprise software development projects, whether commercial or in-house, take years before they work well. One of the reasons is because the software has so many features. For example, ERP systems can have well over 10,000 features.

When purchasing software, an organization must consider how well the features work for their particular needs. Familiarity breeds contempt: IT professionals understand the applications in their fields, but they fail to appreciate how complicated these products really are. The failure to adequately deal with the complexity of so many features and requirements puts software selection projects at risk.

Underestimating effort

An adequate requirements analysis is the foundation of a successful enterprise software selection project. Gathering requirements can be 50 to 75 percent of the work, and is almost universally underestimated. Enterprise software is complicated, and ensuring there is a good match with organizational needs takes time and effort, which must be planned up front.

Unknowns

To quote Donald Rumsfeld:

…there are known knowns; there are things we know we know. We also know there are known unknowns; that is to say we know there are some things we do not know. But there are also unknown unknowns – the ones we don’t know we don’t know… (Wikipedia)

When selecting software, it is these unknown unknowns that cause projects to fail. Typically, these appear as unanticipated problems during implementation, although they sometimes only show up later after the software goes into production. Use the idea of front loading requirements development to reduce the risk of unknowns. Also, you need to anticipate future requirements based on where the organization is heading, which extends the useful life of the software investment.

Shortcuts

By the time an organization realizes how much work is involved with the requirements, they have usually committed deadlines to the business. To meet those deadlines, they are tempted to take shortcuts, which pave the way to a software disaster. Some of the more common shortcuts taken are:

• Not enough requirements detail. Undiscovered requirements appear during implementation, increasing costs and causing delays.
• Relying on committees to select software.
• Relying on previous experience. Falsely assuming that because the software worked well at a previous company it will work well at the current company.
• Following the competition. Falsely assuming that software used by a competitor will be adequate.
• Selecting the market leader. Usually considered a “safe” choice, for example, “Nobody is fired for buying (insert vendor name here)”. However, because a product is the market leader does not mean it is the best-fit for the organization’s needs.
• Relying on vendors to select software. Common in governmental organizations, this is a bit like asking the fox to guard the henhouse. Very seldom will vendors advise a potential customer that their product is not a good choice.
• Relying on consultants who resell products. These consultants specialize in a few products, and will tend to recommend something that they sell. After all, they want the implementation business.
• Relying on analysts. If the software is in the top right quadrant, it is assumed to be good. Analysts are a great place to start, but their analysis is written for an average software purchase, and not your particular organization.

Conclusion

Forewarned is forearmed. When evaluating enterprise software watch out for these problems. To minimize project risk and maximize the probability of success make sure they don’t happen to you.