Making a choice between Custom built products or buying a Commercially available Off the Shelf Products (COTS) is a dilemma that all business enterprises must deal with sometime. Like with any decision, business function heads need to weigh the potential upsides and downsides while making this choice. In the words of Nolan Bushnell, one of the founding fathers of the video gaming industry “When you are building something, you know all of the trade-offs”.
How Do Organizations Decide?
One strategy adopted by large scale enterprises is to decentralize the decision-making and accordingly IT budgets were divided between the Technology and Business Teams. This budgeting process has evolved over the years as an answer to changing business needs and the need for technology to align to that. It is now seen more as a strategic tool and validator of overall IT Strategy and Roadmap rather than just a control mechanism. However, even now one fundamental dilemma exists – “Who has the D on new Tech aka Innovation? And how centric is the Build versus Buy Debate to answer this quandary? To answer this question, you need to ask another question – What is the problem being solved and who are the stakeholders? Is it a tech problem or a business problem? Are most users Tech Savvy or are the users pre-dominantly from Business Teams trying to solve for Business Operations?
Four Factors that Impact the Build Vs. Buy Decisions
Before we take this line of thought further, let us look at a few important factors that organizations must keep in mind in this situation of trying to decide between build and buy. In our experience, there are 4 major sub-factors that influences the decision-making process. Moreover, these sub-factors have a significant interplay and hence they cannot be evaluated in isolation from each other.
- Time to Implement – Especially when the request is initiated by Business, the time to implement the solution is the most important factor. For Business-Critical requirements, time factor may even supersede the cost considerations. Until or unless, organizations see a compelling and long-term and sustainable Competitive Advantage, chances are the decision will go in favour of off the shelf products. Because of a faster rollout, the notional savings in opportunity cost will make up for the sometimes-higher upfront costs and the use of tried and tested product.
- Organization Readiness – This can be further divided in two parts – System and People Readiness.
- System Compatibility – Compatibility with the rest of the systems should be considered. When we buy off the shelf, the ease of integration varies widely. Even though most COTS offer API Support, sometimes it’s easier to build especially for legacy systems. Furthermore, the build process allows Businesses to align roll-out of features to their priorities and needs. Furthermore, Business Priorities change periodically. Irrespective of build or buy, the solution adopted needs to be flexible enough to respond to the ever-changing business requirements.
- Change Quotient of People – This can be often ignored but without high rates of adoption, any software rollout will fail. This can contribute substantially to the overall costs of the project through slow or less than desired adoption rates. Users in large enterprises work on multiple applications and it pays to have all of them inter-linked in a seamless manner. If the users are faced with using multiple standalone application with difficulty in navigation between them, chances are there will be resistance and lower user adoption.
- Cost – Budgetary limitations are always a factor in decision making. It is a long-held belief that it is cheaper to buy software as compared to build but that may not be always true. To answer this, one must look at the total cost of ownership through the complete lifecycle. This will include both direct and indirect costs. There are templates and frameworks available which allow you to cover all the different cost aspects and streamline the decision-making.
- Continued Maintenance and Support – When looked from the long-term lifecycle of a product or service, this is very important both from cost and quality perspective. If the internal IT Team is short-staffed or devoid of bandwidth, it is better to buy. Furthermore, when one buys, the complete responsibility shifts to the vendor. However, you must live with the fact that changes to the system will be dependent on the cycle followed by the vendor and won’t be as agile. Even if the internal teams have bandwidth, a case may be made that they will should spend their time on critical value adding projects and not for operational maintenance.
As mentioned in the beginning, we are dealing with trade-offs. Irrespective of the decision to build or buy, the trade-offs compel us to look for various risk mitigation strategies. However what needs to be kept in mind is that the decision is multi-dimensional, and all the sub-factors are inter playing with each other.
So What Do You Do to Mitigate Risk?
- When you buy
- Sometimes it works if the vendor does a quick POC for a sub-function. Documenting the journey helps to mitigate risks if a wider rollout is implemented.
- Work with the existing features of the product and try to align it to your business process. Mapping current processes and understanding and working around the limitations can pre-empt disruptions.
- Evaluate the integrations on offer beforehand to enable as seamless an experience as possible to the end users.
- When to build
- With newer Development Methodologies and hosting through Cloud, the time to develop and implement can be reduced.
- There is control in build as what you need and nothing else needs to be built for. You can also build based on which features align with your business priority.
- Pre-Define Governance Metrics around Cost, Timeline & Schedule, and Performance so that any deviation can be checked in time and corrective action plan implemented.
At this stage, lets accept that the decision to build or buy is as complicated as it comes and there is no one size fits all approach that can be taken.
Application Engineering – To Build or Not to Build is the Question
At DefineRight, we invest time to understand your business function’s needs vis-à-vis your Organization’s Business and Technology Roadmap, interact with various stakeholders in your teams to better understand their requirements through our in-house Discovery Framework and help you in making this decision for an improved Return on Investment.
