The Buy Versus Build Dilemma: Navigating an Ocean of Technology Choices

If you’re ever involved in your organization making technology choices around a critical business need, you may find yourself at a fork with several different paths. Do you buy software, build something yourself, hire someone else to build something custom for you or do a combination of all the above?

Navigating technology choices in any field can be daunting. How do you ensure that you’re identifying the best options to serve your organization’s needs? And how do you support the decision-makers?

In her recent presentation at LocWorld 40 in Portugal, Kamilla Krawczyk, Technology Solution Manager, shared the model that she uses to address the “buy or build?” question when it comes to developing technology stacks. It’s a comprehensive and organized method that she uses in her role at RWS Moravia to ultimately analyze data and make recommendations to decision-makers. And it is generic enough that you can use this same approach to support decisions about your tech stack, too, no matter what business you’re in.

Today’s landscape – an ocean of options

Traditional industries like manufacturing, pharmaceuticals, banking and automotive have a selection of mature, industry-specialized ERP (enterprise resource planning) systems at their disposal. Such systems support an organization’s end-to-end processes and often go beyond their actual needs, connecting almost every imaginable business function and enabling advanced automation, workflows and business analysis.

But what about in the localization space? Can localization companies buy an off-the-shelf ERP system to deliver all the functionality that’s important for their business? Or can localization customers use their ERP systems to integrate localization into their core business processes? In most cases, the answer to both is “no.” Despite there being a myriad of third-party specialized tools and point-to-point integration options available, to date there is no ERP-class solution on the market for the localization industry.

Some companies who consider themselves “techie” may choose to build proprietary technology ecosystems. Others may build their own tech stack out of necessity, either because there is nothing to buy or because the buy options are insufficiently comprehensive for them. Others still have taken the path of assembling solutions out of third-party tech components (or a combination of third-party and self-built components) and then making the parts work through operational integration.

The current wealth of platforms with well-functioning APIs combined with the rise of service-oriented architecture has created more options than ever for serving the end-to-end needs of a localization operation.

So, how to choose the right path? This was the problem Kamilla encountered when she sought out a methodology for technology decision-making.

Spoiler: There’s an art and a science to the methodology, but it's within everyone’s reach.

Making technology decisions

High-level approaches to answering the “buy or build?” question are the same, regardless of the industry. You could make an emotional decision based on what “feels right” or make a rational (and more scientific) decision driven by data.

How companies approach this usually depends on where they are on the Software Selection Maturity Scale. Yes, there is also a maturity model—the universal tool that organizations use to drive improvements in their practice—for software selection!

Most organizations are between levels one and three and may be more inclined to make their choices based on what “feels right.” Or, they may be a bit more objective; for example, by asking a number of stakeholders for their “on a scale of 1-10” evaluations of the proposed solution (à la NPS). The higher the maturity level, the more an organization understands the value of a data-driven approach and a thorough needs analysis.

So, what data is important and how do you get it?

Starting high-level

Kamilla advocates for a disciplined, scientific-but-pragmatic approach to decision-making that translates evaluation steps into easily comparable quantitative scales wherever possible. It can be useful to begin high-level. A good starting point is to look at the anticipated lifecycle of the product you are going to buy or build.

Gartner’s Pace-Layered Application Strategy is a helpful tool in categorizing applications into three types based on their lifecycle:

1. Systems of record: A long-term investment that supports business-critical transactions, such as ERP, CRM and SRM systems. If you keep them up to date, systems of record will be around for 10+ years.
2. Systems of differentiation: These are specific solutions for individual business processes that create your competitive advantage—maybe an advanced client portal or an automation technology that cuts your turnaround time by half. Depending on the strength and configuration of the solution, its lifecycle would be one to three years.
3. Systems of innovation: Whereas you’d need to ensure systems of differentiation work for a number of stakeholders and use cases, systems of innovation are built for one particular use case, usually for one team. These last up to 12 months.

In the Gartner model, each system type comes with a default recommendation of whether one should buy or build:

This guideline is a helpful first step in your decision-making process. You can determine where on the spectrum the solution is that you are trying to implement in your organization.

Data-driven discovery

Next, you will be going down two paths: financial analysis and functional analysis.

Financial analysis helps determine such elements as the solution's cost, maintenance and subscription fees. Also, if customization is needed, that may be an important addition to the overall solution cost.

Functional analysis is the backbone of the entire assessment and starts with an in-depth quantification of the functional needs of the stakeholders. This is necessary to more accurately estimate the final cost of the solution.

But, the first step on your journey is to define the stakeholders and their requirements. Based on the project’s goals, the relevant teams need to define what their needs are today and try to forecast what they might need in the coming two years. (Check out our six-step process for choosing a TMS for more details on how to define and prioritize requirements and stakeholders.)

The stakeholder-verified list of requirements serves as a basis for RFIs and facilitates the collection of information from vendors that will be used to select the five (or less) companies that you want to invite for live demos. Live demos help you assess how well requirements are delivered using a gap analysis, in which you assign each solution a “fit” score—an objectivized number on a scale (1-5, 1-10, etc.) that indicates how well the software performs in each area. The scale’s values should be defined and used consistently to weigh each option.

Decision time

Now that you have all the information collected, it’s easy to create a simple table of all the evaluation results. Plus, you will visualize your cost-impact-over-time simulations by comparing financial options. Depending on the outcome, it may or may not be clear which is the best solution, but there are parameters you can look at to help make the right choice.

For example, in the table below, you can see that System C has the second highest score for functional requirements, but also the lowest gap score. This is likely to translate into the shortest turnaround time for customization as well as the lowest budget. Minimizing customization scope also translates into the greatest chance of project success.

The general recommendation is that if, at the end of your analysis, you find that the solution meets at least 80% of your needs, then you should buy.

If it does not, you can always increase its fit score by:

• reducing the scope (eliminating certain functionality)
• making small customizations
• combining two or more products

If none of these approaches work, then build is the answer.

Finally, you will compile a one-page summary that contains a table like the one above and your cost simulations, distilling things down nicely for the decision-makers.

In some cases, regardless of what you thought the outcome of the analysis would be, data may tell a different story—the benefit of the disciplined, data-driven approach as opposed to the “what feels right” approach. Even if 20 stakeholders have the same gut feeling, it’s still subjective. And while that may work for simple solutions, complex ones (or where a lot of money is on the line) require a more thorough analysis.

Have you had success with a different data-driven process for deciding whether to build or buy enterprise software? What are your observations about ours? Do you need help with a buy versus build decision? Don't hesitate to leave a comment here or contact us!