Build Vs. Buy - Is There a Right or Wrong?

A common dilemma in the IT world is the everlasting dilemma of a CIO, should I buy software or invest in building one?

I do not think there is a straightforward question, as this issue contains multiple layers of strategic decisions that impact the decision. 

Build and buy can coexist and using the process smartly can provide an upgraded system.

So, what should we think of when we contemplate a build Vs. buy approach?

Below are some key items I believe should be taken into consideration.

● what is the company’s strategy? If your company is focused on maintaining and stabilizing its processes, then maybe a ‘buy’ solution is the best approach. However, if your company is an innovator and has unique processes that put her ahead of the competition, then there might be good merit to ‘build.’ The CIO establishes the IT strategy in line with the companies, and part of that strategy is the approach to system design. Are you a CIO that focuses on the development and believe that building a system can create value and that the IT team is built to maintain it? Or your focus is on learning what others did and what is possible to do with commercial off-the-shelf (COTS).

● IT team size. Building a system usually requires a larger IT team that can develop, test, and support the systems development life cycle (SDLC) process. Outsourcing development is always an option but that brings some other challenges that we will not cover here.

● Organization Culture. Often being dismissed, this is a crucial component in the decision that affects both approaches.

“If there is a product in the market that answers most of the needs then prefer it to buy and see how it fits the organization into the system.”

● Build – to support a ‘build’ environment business experts (SMEs) should define their needs and work with IT to build a design document. This requires time and discipline. Can your organization support it?

● Buy – buy strategy requires your organization to accept a dictated solution, this might cause friction as the SME might reject it.

The items mentioned above are only part of a more complex decision on strategy however, once they are resolved/agreed upon the process becomes more technical.

There is one more critical component one must consider, are Build and Buy mutually exclusive? Can we achieve more by combing the two?

It is a fine line to walk but if done correctly the result will be a great product.

When should I build? If your organization has a unique process that adds value, then you should Build as there cannot be a solution available. An interesting test will be to look for such a solution as there are cases in, which we believe we are unique, but if a system performs a similar task, then we may want to review if we are unique.

when should I buy it? In my view, if there is a product in the market that answers most of our needs then I would prefer to buy and see how I fit the organization into the system. A perfect example is an enterprise resource planning (ERP) solution, there are so many solutions out there and some are designed for specific industries that it does not make sense to build one.

As stated above, there is always an option to combine. Use a ‘buy’ system for the non-unique process and enhance it with a ‘build’ system.

No matter what you decide, always check the market as it is beneficial to learn what your peers are doing.