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\u00a0software disaster\u00a0stories, these outright failures are only the tip of the iceberg. More frequent are the partial failures where the software doesn\u2019t work as hoped but is not bad enough to discard and start again. Of course, most people don\u2019t like to talk about their failures, so these tend to be quietly forgotten.\nSelecting enterprise software is a more formidable problem than most people realize. This article examines why software selection projects are so often underestimated.\nOverconfidence\nOverconfidence 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.\nUnderestimating complexity\nMost 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.\nWhen 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.\nUnderestimating effort\nAn 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.\nUnknowns\nTo quote Donald Rumsfeld:\n\u2026there 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 \u2013 the ones we don't know we don't\u00a0know...\u00a0(Wikipedia)\nWhen 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\u00a0front loading requirements development\u00a0to 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.\nShortcuts\nBy 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:\n\nNot enough requirements detail.\u00a0Undiscovered requirements appear during implementation, increasing costs and causing delays.\nRelying on committees to select software.\nRelying on previous experience. Falsely assuming that because the software worked well at a previous company it will work well at the current company.\nFollowing the competition. Falsely assuming that software used by a competitor will be adequate.\nSelecting the market leader. Usually considered a \u201csafe\u201d choice, for example, \u201cNobody is fired for buying (insert vendor name here)\u201d. However, because a product is the market leader does not mean it is the best-fit for the organization\u2019s needs.\nRelying 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.\nRelying on consultants who resell products. These consultants\u00a0specialize in a few products, and will tend to recommend something that they sell. After all, they want the implementation business.\nRelying 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.\n\nConclusion\nForewarned 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\u2019t happen to you.