CIO’s Dilemma: Buy vs. Build

Buy vs. Build would depend on a combination of strategy, functionalities required, affordability and timing.

There are many variables and considerations to the decision upon ‘build versus buy.’ This decision is unique to each organization, industry, and application. There are pros and cons to each but regardless of which decision is taken, IT leaders need to make the case to successfully bring quality and speed with IT deliveries. Here are a few angles to see it through in order to make the right decisions.

Strategy: Decision making varies amongst companies depending on the vision of the business leaders, organizational strategy, and that influence the answer to the following questions.

-        Is it your core competency? Will these products/services create a competitive advantage for your organization?

-        Is it something will increase revenue or significantly reduce cost or give competitive advantages? 

-        What's your budget? What's the perceived value of the business? 

-        Are you confident it will generate more revenue? If not, can you rent it till you're sure? 

-        Do you want your system to scale as required?

-        Does it have to integrate with other internal/external systems? What's the effort?

-         Is this product going to be integrated multiple times across many other products? 

-        Can you afford to maintain it on your own? 

Functionality - Build or buy? That depends on what your infrastructure looks like and the legacy programs in place. Build vs. buy also depends on how specific your application or system is going to be. It would also depend on whether you were looking for a component of a system as opposed to an entire system. Everything is a matter of degree. All large-scale businesses build AND buy. Buy when there are mature/industry standard products available or when supporting operational/secondary lines of business. Even when you decide to buy, you’ll need integration professional services, so there are few cases in a plug and play fashion model. But between buying and building, there is a middle-ware solution option, which is “Assemble.” Today, truly building from scratch seems little tough for most IT organizations as no one wants to redesign the wheel, even the vendors themselves rarely build their commercial solutions from total scratch, but taking the Lego approach to integrate multiple and different specialized commercial and open source software components.

Affordability - Is there a cost-benefit or is it a discussion about timing and convenience for buy vs. build? Generally speaking, buy for commodity services with efficient cost, build when seeking competitive advantage. However, the buy option often involves plenty of customizations or integrations. There are also many options for rapidly building new solutions, which is the attraction of the buy option.

Timing - Is the functionality required immediately or is their time for it to be developed in-house? Normally an internal IT development team would want to take on the challenge; however one would need to consider time-to-market and cost of development. Timing matters in order for the company to run at the digital speed today. Plus, why do you reinvent the wheel? Has someone else already developed what you require? Timing is critical. You buy when the solution provider can meet most if not all of the critical requirements without a lot of customization, with faster speed. If this is not the case then build the solution that meets most of the requirements. ‘Build’ pitfalls: Too often large-scale projects are started and when finally completed, no one ever goes back to measure or ascertain if the project was indeed a “success” in delivering the projected results that were originally proposed.

Maintenance-When your main focus is on the business applications which can create a unique advantage, it is better to build. Firstly, no outside supplier knows your business as you do, and to try and fit a square peg into a round hole (or vice versa) is the prime reason so many software projects fail. Moreover, you are not only building the system, but you are building the support staff, following your priorities, support staff that can maintain the system long-term. You retain the know-how. Even if you buy, you must insist on a source code license, and have your own staff trained in maintenance of the code, and have know-how transferred as part of the purchase agreement. This way you control your destiny. You must be able to modify the system to support the changing business environment and practices without relying on the third party to do so.

The competent CIOs would make the correct decision in terms of the overall strategy for the business. Buy vs. Build would depend on a combination of strategy, functionalities required, affordability and timing. The "rule of thumb": You build when it gives you a competitive advantage (unique product feature, lower cost, etc.) otherwise, you buy. In today's environment, there are many options available to buy and it’s usually in your best interest to pursue that option first.