Recently I was talking to somebody at Oracle who recounted the case of a potential CRM customer that got away. Oracle had beaten out Salesforce, Microsoft, etc., and was poised to close the sale. Then the customer decided not to purchase, but rather to continue developing their homegrown CRM system.\nThis customer was faced with the build vs. buy question and decided to build. Always a difficult question to answer, it is too easy to make the wrong choice. There are two responses to this question:\n\nMake an emotional decision that "feels right"\nMake a rational decision driven by data\n\nMost decisions are a blend of the two extremes, but many companies lean too far in the emotional direction. When hard data is available, making an emotional decision is not good business practice!\nMost organizations are relatively low on the Software Selection Maturity Scale. They usually start with spreadsheets, but as the analysis proceeds the limitations of spreadsheets become apparent. They also realize how much work is involved, and lack a clear idea of how to proceed. In the end, they may do a very high-level analysis, but underneath it is an emotional\u00a0decision based on what\u00a0\u201cfeels the best\u201d. The final decision is often made by a committee, and that has its own problems.\nA rational build vs. buy decision starts with well-defined requirements. Then potential products are evaluated to measure how well they meet those requirements.\u00a0If you are considering replacing a homegrown product, include that in the evaluation.\u00a0It is usually worth starting a\u00a0new enterprise software project\u00a0with an evaluation, even if the ultimate result is a development project.\u00a0So how can the build vs. buy question be answered in a rational way without getting overwhelmed by all the work?\nRequirements\nThe allure of building software is that all requirements can be satisfied, but that is a mirage. Resource constraints mean coding must be prioritized, and some requirements will never be met. Then the team may not fully understand the problem domain, and may not discover unknown requirements.\u00a0\nBegin with a tool designed for software evaluation and selection like the free Wayferry App. To discover all requirements, even the unknown ones, use the technique of reverse engineering features back into requirements. Start with the homegrown code to develop a baseline, and then reverse engineer potential replacement products. This builds a comprehensive list of requirements that includes the unknowns. Note that it is well worth the effort of front loading requirements development because this reduces overall project risks.\nOnce the requirements list is complete, those requirements must be rated for importance. This has the added benefit of building stakeholder buy-in. The output of this exercise is a comprehensive requirements profile that adequately captures organizational needs.\nThe gap analysis\nUse the completed requirements profile to create the RFIs (or RFPs) that will be sent to the vendors. Design the RFI to maximize vendor response. You don\u2019t want to miss out on the best-fit software because that vendor didn\u2019t respond. Score vendor responses in the app,\u00a0which automatically does the gap analysis and calculates fit scores.\nThe build or buy decision\nOnce you have fit scores for the homegrown product and potential replacements, you can rationally answer the build or buy question. Assuming normalized fit scores where 100% means all requirements are fully met, if several cloud or off-the-shelf products have a fit score of 80 percent or more, then buying is the right way to go.\nIf all commercial products score lower than 60%, there are three other possibilities:\n\nReduce the scope\u00a0of the project by eliminating certain functionality.\nCombining one product with a small custom code module\nCombining two or more commercial products\n\nEach of the above increases the fit score. If none of these approaches works well enough, then building\u00a0the app can be the right way to go.\nConclusion\nIf an organization has an in-house development team, there is always the push to build because they can supposedly satisfy all needs. However, from my experience and observation, it is usually far cheaper and faster to buy than to build. After all, if a problem has been adequately solved in a commercial product, why solve it again? Why not focus on a new and more interesting problem?\nIn this article, we summarized a process for making a rational build vs. buy decision. While it takes significant work to execute properly, the costs of making the wrong decision will be felt for years. On the other hand, the consequences of the right decision can resonate with the bottom line for decades or more.