How to determine when to build or buy enterprise software

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.

This 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:

• Make an emotional decision that “feels right”
• Make a rational decision driven by data

Most 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!

Most 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 decision based on what “feels the best”. The final decision is often made by a committee, and that has its own problems.

A rational build vs. buy decision starts with well-defined requirements. Then potential products are evaluated to measure how well they meet those requirements. If you are considering replacing a homegrown product, include that in the evaluation. It is usually worth starting a new enterprise software project with an evaluation, even if the ultimate result is a development project. So how can the build vs. buy question be answered in a rational way without getting overwhelmed by all the work?

Requirements

The 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. 

Begin 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.

Once 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.

The gap analysis

Use 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’t want to miss out on the best-fit software because that vendor didn’t respond. Score vendor responses in the app, which automatically does the gap analysis and calculates fit scores.

The build or buy decision

Once 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.

If all commercial products score lower than 60%, there are three other possibilities:

• Reduce the scope of the project by eliminating certain functionality.
• Combining one product with a small custom code module
• Combining two or more commercial products

Each of the above increases the fit score. If none of these approaches works well enough, then building the app can be the right way to go.

Conclusion

If 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?

In 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.