There are multiple reasons why major software purchases fail, but one of the most common is that of an inadequate requirements analysis. The problem is caused by people being unfamiliar with requirements gathering techniques, and by grossly underestimating the amount of work involved.\n\n\nRequirements are to software selection as foundations are to a building. Get them wrong or leave things out and there always will be problems. This article examines the consequences of missing requirements in the analysis phase and describes how to avoid the problem in the first place.\n\n1) Inadequate functionality\n\nIf the initial analysis misses significant requirements, there is a risk of purchasing the wrong software. If this happens, missing functionality is discovered during implementation or early production use, but at that point contracts have been signed and it is too late to do anything about it. Your only hope is that the functionality gap is not too serious, but as some of\u00a0these examples show that may be a vain hope.\n\n2) Discovering \u201cnew\u201d requirements\n\nEven if best-fit software was purchased, if there was an inadequate requirements analysis at the start of the project, significant \u201cnew\u201d requirements will be discovered during implementation. This triggers meetings to rate those requirements for importance to the organization. These meetings take time to organize; they consume time, and they slow down decision-making. This exerts pressure on implementation project deadlines.\n\n3) Implementing \u201cnew\u201d requirements\n\nIf the organization decides the newly discovered requirements must be satisfied and the software does not meet them out-of-the-box, the implementation team must find a way to resolve the issue. Typically, they start exploring if the software can be configured to meet the requirement. If that does not provide acceptable functionality, they consider writing small amounts of code (e.g. event triggered macros or scripts), re-engineering business processes to fit the software, or purchasing add-on modules or third party products. Discovering too many \u201cnew\u201d requirements is the primary cause of implementation delays and cost overruns.\n\n4) Business disruption\n\nToo many missed requirements exert pressure on project schedules\u00a0and may cause some requirements to be skipped to save time. When the software goes into production this functional mismatch can seriously disrupt the business. An example of this happened at athletic shoe and apparel retailer Finish Line\u2019s botched supply chain software implementation which resulted in a $32 million decrease in sales and cost the CEO and Chief Supply Chain Officer their jobs.\n\n5) Unmet expectations\n\nWhen new software goes into production and significant functionality is missing, users must scramble to resolve the problems. Typically, this takes the form of ad-hoc business process reengineering and it imposes significant extra work on employees. Buy-in evaporates and users start to push back against the new software. Management sees the problems and thinks \u201cOh no! Not again!\u201d The CFO realizes that the ROI used to justify the software purchase will never be achieved, and will be even more skeptical of future software projects.\n\nWhat can you do about it?\n\nRequirements will be\u00a0discovered during the initial requirements analysis, during the implementation or in early production use. An implementation project that starts with a comprehensive list of ALL significant requirements, who wants them, why they are wanted and how important they are, enables the project manager to create a realistic implementation plan. When no significant new requirements are discovered, the implementation is on schedule and within budget.\n\n\nThis begs the question: How do you discover all significant requirements? The answer is to use the technique of reverse engineering requirements from the features of potential software products, and any currently used software. Essentially it is examining the features of multiple software products and rewriting them as requirements. It is the most reliable way to discover all requirements, including unknowns.\n\n\nThe secret of successfully painting a building is a thorough preparation. The actual painting is only a small part of the work. Likewise, a successful enterprise software purchase requires a thorough requirements analysis. Enterprise software usually has thousands of requirements and it can take months to develop a comprehensive list. However, if this preparatory work is inadequate, you are putting the entire project at risk. If you think this is too much work, just think of how much work a failed software project entails, and what it can do to your career!