Organizations buy enterprise software for the benefits that accrue from using it, and those benefits are realized from the features of the software. Requirements are used to define the desired features, and there is always the temptation to expand the list of requirements so the new software will do more. However, this increases costs and risks.\nWhen buying enterprise software the question becomes one of defining an optimum set of requirements that can be realistically satisfied by software available on the market. This article explains a method of doing this.\nRequirements scope\nWhen buying enterprise software defining the scope of requirements can be very challenging. For example if an organization is thinking of an intranet, what should they include? Possibilities are content management, collaboration tools, file sharing, corporate directory and many others. When looking at something like ERP, should the proposed new system include HRIS, Supply chain management, CRM and so on?\nAll enterprise software systems have edges or boundaries to their functionality and need to interface with other systems. The difficulty is deciding where those boundaries should lie. Often existing systems can help you decide. For example if a company already uses Salesforce, it is unlikely that CRM functionality would affect the selection of a new ERP system.\nThe first step in a new software project is to develop a requirements profile that adequately defines\u00a0organizational needs. The key to doing this is using the technique of reverse engineering features from potential products into requirements, which also discovers requirements the organization does not know they need.\nNext is the gap analysis to measure how well potential products meet the requirements. If you use a scoring system where a fit score of 100% means every requirement is fully met out of the box, you can verify the requirements scope of the project. If there are:\n\nSeveral potential products with a fit score of over 85 percent, this means the requirements scope is well matched to what the market can provide.\nNo potential products with a fit score of 65 percent or more, this means the requirements scope is not aligned with the market.\n\nBear in mind, when you are buying software, you are restricted to what the market can provide. By using a system that measures how well potential software products meet requirements, you see how closely those requirements are aligned with what the market can deliver. If the fit scores are high enough, you can proceed with the purchase. However, if the fit scores are too low, the scope of the requirements needs adjustment.\nAdjusting requirements scope\nWhen there are no products on the market close enough to the desired requirements, you need to find a way to boost fits scores relative to those requirements.\n1) More expensive software\nIt may be that to stay within budget, more expensive software products were not considered. If those products do adequately meet needs while cheaper ones do not, then they are worth considering. For example, if a midsized organization was considering mid-range CRM software, but nothing scored well enough, they could find that a high-end product like Salesforce would be a better choice. To help decide if it is worth spending the extra, they need to estimate the ROI.\n2) Versions\nVery common in the cloud, a vendor may have multiple versions of a product, e.g. basic, business and enterprise accounts. Evaluating versions that are more expensive may increase fit scores to acceptable levels.\n3) Add-on modules or products\nVery often, a vendor has their own or 3rd party modules that can be added to the product, for example, think of adding something like Crystal Reports. Adding one or more modules or 3rd party products may increase fit scores to acceptable levels.\n4) Combinations of software\nYou may find that no one product adequately meets requirements, but a combination of two or more products does. If you decide to go this route, verify that the product interfaces are up to the task of seamlessly exchanging information.\n5) Reduce scope\nHere you eliminate requirements to reduce scope, which can boost fit scores. For example, one of our clients was looking at Clinical Trials Management Systems and wanted the solution to include document management software that met FDA requirements. All the products they considered included rudimentary document management, but none was good enough. The solution was to remove document management requirements from the scope.\n6) Reduce scope with code\nSometimes no software on the market meets needs because of a few showstopper requirements. By writing a small amount of code, these requirements can be satisfied. For example, take construction cost estimation software, which typically gets item costs from industry databases. In one case, a client wanted their estimators to use historical cost information from RFPs rather than using the industry databases. Since code had to be written to import the cost information, adding functionality to that import code to manage the historical price information was worth considering.\nConclusion\nNew enterprise software project risks are significantly reduced when the scope of the requirements are well matched to potential software on the market. To achieve that match, it is sometimes necessary to adjust the scope of the requirements.\nWith appropriate communication, employee expectations of the new software are well matched to what the software actually delivers, which also improves user buy-in.