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.\nIn 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.\n1. Immature software selection process\nWhile fast-growing companies are the exception, by their nature major software purchases are relatively rare\u00a0events 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.\n2. Overconfidence\nWhen it comes to making a major software purchase, lack of experience with selecting that type of software can lead organizations to ask the question \u201cJust how difficult can this be?\u201d 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.\n3. Underestimating work\nEnterprise 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.\u00a0If 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 \u201cnew\u201d requirements causes implementation nightmares that take much longer than originally planned.\n4. IT lacks business experience\nWhat 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\u00e9cor than a building contractor.\nBecause 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.\n5. Project scope not actively managed\nWhile 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.\n6. Doing the wrong work\nWhen 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\u00a0to do is to satisfy yourself that the new software can adequately handle your existing processes. The reasons are:\n\nCollecting requirements is a big enough task without the added burden of process analysis and optimization.\nYou need the framework of a software product around which to optimize processes, otherwise you are operating in a vacuum.\nSoftware vendors often have best practices with their product which can significantly reduce\u00a0the work needed for business process optimization.\n\n7. Selecting software for the wrong reason\nMajor software selections are often made for the wrong reasons, such as these:\n\nThe software worked well at my previous company, so it will work well here (typically made by a new executive).\nSoftware selected by committee.\nIt did well in the demo, and the sales people are so good.\nCompetitors use it (they may hate it, but you don't know that).\nIt is the market leader.\nBiased selection.\n\nThe 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.\n8. Inadequate requirements\nRequirements 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?\u00a0Well-written requirements\u00a0include 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.\n9. Functional fit not verified\nThe purpose of the gap analysis is to measure how well potential software products meet the organization\u2019s 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.\n10. Using spreadsheets for the gap analysis\nWhile 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.\nFor 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.\n11. User buy-in not created and nurtured\nThe 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!\n12. Expectations not actively managed\nA 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.\n13. Trusting vendors\nWhen 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.\nCaveat emptor.\u00a0It 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.\n14. Not auditing vendor responses\nIt 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.\n15. Skipping vendor due diligence\nDue 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.\n16. Relying on procurement\nCommodity 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:\n\nTreat enterprise software as a commodity purchase.\nOverlook the critical step of building user buy-in during the requirements analysis phase.\nLack experience when negotiating cloud contracts or software licenses.\n\nConclusion\nSuccess 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.