Outsourcing vs Internal Development: When to Make the Switch?
The global outsourcing services market stands at about $90 billion. This means that every year, several companies around the globe choose to answer the question we are planning to answer in this post, with a resonating amount of dollars backing their response.
Most companies that can sustain a technology product’s growth often tend to have an internal team looking over development, features, updates, and maintenance. That is one part of the story. The other part would show you that even the most sophisticated technology companies like Google, Facebook, and Apple, outsource software and IT development & management.
So, if you look an inch beneath the convention’s curtain, you will find that the issue is more critical. Assuming you are not running on a primary constraint of cost structures, here is how you can organize your thinking and decide when to go for outsourcing and when to plan for internal development.
The Variables that Go into Decision-Making.
In and of itself, none of the variables dictate whether you should outsource, develop internally, or look for alternatives. But, your company’s position on each of these variables will give you a structured approach to decide which route would suit you:
1. Nature of the Product
Instead of focusing on the technical architecture of the product, focus on the features of the product and how you plan to use each one of them:
a. Product Type: After aggregating a list of features you need from the product, you will largely have the list resembling a complete product. For instance — if you need an AI-enabled interface that can handle routine queries on your website, you are looking for a chatbot. Similarly, you may need an API or a dashboard as the core product.
Understanding the product type will help you answer a key question — the lowest price for which you can get all the features you need and customization. For instance, — chatbots have become so popular that there are several standalone products available. You might not have to develop one from scratch. Even if you deploy it and realize you need more custom features, you can add them with the help of a technology partner later.
If the degree of customization is high, you should work with an outsourced team. If the degree of customized changes is too high and too frequent, you can consider hiring an internal team.
b. Use-Case: Along with the product type, focus on the users who will actually work with the end-product. Look at the frequency of use and benefits of having the product in the enterprise process. This will help you define the value proposition of the product. Later, if you decide you want to have an IT partner to help you in the development process, this value proposition will guide light in the process instead of the budget.
c. Strategic Significance: This variable can help you only if you have a strategy in place. By definition, a strategy has to cover several years. But that does not mean you have to develop the entire product internally. Break your corporate strategy into buckets of KPIs. Now see how your product is helping your business achieve these KPIs. If you are lagging on the KPIs already, it might help in thinking about working with a technology partner. If you believe you are ahead of schedule and have extra resources, you can consider having an internal team to focus on further development.
2. Availability and Allocation of Resources.
This is generally considered to be the primary variable for most companies. However, it does not work out the way most companies think. Here are the common forms of resources you should consider:
a. Operational Resources: This includes all the enterprise processes.
b. Financial Resources: This includes your company’s liquidity, cash flows, and budgets.
c. Technical Resources: This includes the technology you have right now.
d. Human Capital: This includes all the talent in the form of full-time employees you will need, to engineer, deploy, and update the project.
Focus on the availability and scale of your resources throughout the project lifecycle. For instance, — you might not have a dedicated IT Services Management team right now. But you will have one in the future. Account for it in your planning process.
Don’t forget the expertise of your resources. Take, for instance — the case for Google. Despite having some of the best software engineers in the market directly working on the company’s products, it uses outside technology partners, vendors, and agencies. Often, the external partners have the economies of scale, efficiency, and expertise better than a Google engineer for a specific requirement. This also re-emphasizes how having a good understanding of your product can help you decide whether you should develop it internally or hire an outsourced team to work on it.
The flip side of that analysis is — you have the IT resources right now to develop an internal project. Will the same resources be available in a few years when your project has scaled and will need more attention? This can help you decide whether you should have a partner working on a standardized solution that practically any team can maintain in the future, or whether you should invest in a dedicated team right away.
3. Risk Management
Here, risk management is a simple way to avoid uncertainties. Consider the following situations and how the concept of risk plays a critical role in outsourcing vs. internal development decisions.
a. Develop or Perish Situation: Your enterprise has run into an operational error. You are trying to solve it. It is not putting your business in bankruptcy, but it is eating up the margins.
Here, the time constraints are very high. For such situations, you cannot afford to go through the cycle of hiring and training people. You need ‘turnkey expertise’ — a team that comes, develops, and deploys a solution as quickly as possible. The variable you are trying to avoid is the fight between the time taken to reiterate and the direct loss to business incurred at the same time.
b. First Introduction to Market or Investors: Prototypes generally do the job for investors. But some investors seek a fully-functional demo of the product. At the same time, companies that want their brand as one of their strategy’s central tenets have to have a well-engineered and functional product reach the market in the first iteration. Once again, the focus is on avoiding iterations. Standardized offerings made by experts can help you launch the right product in one go.
c. Protecting Intellectual Property: You cannot patent ideas unless you have a tangible demonstration or product based on the idea. When you are seeking help in the very development of that product or demo, it is legitimate to think about potential IP breaches.
Despite popular belief, an IT vendor or technology partner has skin in the game and would want to keep your intellectual property safe. This is because a technology partner is in the business of technology development. If it pursues your idea, breaches your contract, and then fails to launch the product with great success — the risk can obliterate its operations permanently as the market will shun it. Since the risk does not match the low probability of a big reward for the vendor, your IP stays protected.
Hiring individuals, on the other hand, poses a different form of risk. There have been very successful technology companies developed on ‘derived ideas’ because the founder had better execution skills. You can hire the right person, but if the right person decides to go rogue, you will have more things at stake than the individual. She/he can get another job even if she/he pursues your idea and fails to execute it properly. The risk-reward ratio is more favorable for the individual.
It’s Not a Binary Decision.
Outsourcing and internal development don’t have to be this binary and at the throats to each other. There are other alternatives available that may suit your purpose:
1. Hybrid: Develop with Expert Help, Maintain In-House.
Ask an IT partner to develop the product for you. Then, hire a team to just maintain the product and manage updates with the vendor.
2. Go Open-Source.
Use an open-source option to understand the possible benefits of the product. You can build an API on top of it and have a functional, affordable, and customized solution.
3. Get a SaaS Version.
Many developers offer the product for free and the features & services on freemium. You can consider these options if the cost is the primary and urgent constraint.
In Conclusion
There is a simpler way to think about all of this — the quality of the team. If you have a team that has a great degree of expertise in developing the solution you are seeking, and the team is available, work with it. It will deliver value that far outweighs the costs of the project. This shifts the focus on value, instead of budgets. You can find such teams working with technology development companies & partners, or even within your firm.
Whatever you choose to do, make sure your thinking goes around all the project’s features, needs, and evolution. Staying within the budget is great, but not at the cost of foregone value.
