The corporate procurement process traditionally focuses on achieving the best purchase price. While this may be the right approach when buying commodity items, when it comes to buying enterprise software it is completely wrong. A far better approach is to focus on the value provided by the software rather than\u00a0its price.\nTo paraphrase Benjamin Franklin \u201cThe bitterness of poor functional fit remains long after the sweetness of a low price is forgotten.\u201d If you pay too much for software, all you lose is a little money. If you buy on price, you risk losing everything, because software that does not adequately meet requirements will eventually be replaced. Government departments\u00a0that take the lowest bid when purchasing software often fall prey to this problem, and it also happens in private enterprise.\nThe source of software value\nValue is in the eye of the beholder. It is determined by the buyer and what they are prepared to pay. When it comes to enterprise software, the value does not flow from deliverables like meeting project milestones. Rather value is in the outcomes that flow from using that software, i.e. from the ability of the software to meet the organization\u2019s particular requirements.\nBy its very nature, enterprise software is extremely complex. For example, if a mid to large sized company is considering ERP software, a thorough analysis can yield numbers approaching ten thousand requirements. The value of the software comes from adequately satisfying these requirements. Only the buyer can decide how much satisfaction is worth to them, and therefore how much they will pay.\nDetermining software value\nThe starting point for determining software value is identifying the requirements that must be satisfied, including both functional and nonfunctional requirements. There is a grave risk of the wrong software being selected without\u00a0an adequate requirements analysis being done up front. Once all significant requirements have been identified, including\u00a0unknown requirements, and rated for importance to the organization, a gap analysis is done to measure how well the potential software products being considered meet those requirements.\nNo software product is a perfect fit, \u00a0and all involve some degree of compromise. However, knowing how well products meet those requirements allows you to estimate their value to your organization. It is wise to factor in the cost of not meeting certain requirements into the calculation as well. Once you know the value, you can decide if the price of a particular software product is reasonable or not.\nSometimes the wrong software is bought, which sets a ceiling on how well it can meet the organization's needs. If that ceiling is too low, the software will eventually be replaced. Even if the best-fit software was bought, a thorough requirements analysis is still vital to avoiding the pains typically associated with these projects.\nWhy the value approach works\nWhen requirements are not discovered in the analysis phase, they will be found during implementation. If they are not satisfied \u201cout of the box\u201d, then the implementation team must decide how to meet them by configuring the software. If they can\u2019t be adequately satisfied with configuration, the implementation team must develop a workaround, e.g. add extra cost options, find suitable add-on products, write custom code, re-engineer business processes, etc. All of this takes time and money, which is why finding substantial numbers of so-called \u201cnew\u201d requirements during implementation causes schedules to slip and costs to balloon. When go-live dates are repeatedly pushed out, you can be sure there is serious trouble on the horizon. Think back through your own experience: how many projects where implementation slipped badly were eventually an outstanding success?\nThe value of enterprise software comes from its ability to satisfy requirements. If a thorough requirements analysis is done up front and no significant requirements are discovered during implementation, the project stays on schedule and within budget. Users are happy because the software works as expected and there is minimal business disruption moving to the new system. Projected cost savings are realized, and the software delivers on the promised value.\nIf software is bought on price, you can absolutely guarantee that shortcuts were taken, and a thorough requirements analysis was not done. Such projects always carry a serious business risk. On the other hand, organizations undertaking the rigor of a mature\u00a0software selection process\u00a0and selecting a product by value are far more likely to achieve the desired outcomes. The software with the greatest value is the product that best satisfies requirements for the price. At the end of the day it really is about the value of requirements satisfied, and not about the price.