Published: Aug 10, 2020 by John Placais
Hidden Costs of Build vs. Buy Decisions
So, you have a problem that you think technology can solve. Let’s say, for example, you currently have a team of people manually processing incoming data. Leveraging software to tame your data can be a breakthrough goal. After project discovery has given an understanding of the details of your challenges, there is usually a decision to be made about whether or not you can leverage a third-party product, or custom build something yourself. Typically these decisions are based on traditional costing models and qualitative assessments of vendor demos. On the “build” side is the cost of hiring or leveraging an existing software development team to build a solution, as well as the cost of a smaller maintenance team after the product is complete. On the “buy” side is the purchase and implementation cost, as well as the ongoing license fees for the software product.
Comparing the two numbers gives you a seemingly easy way to choose between the two - just pick the cheaper solution! Sadly the reality is that this equation is incomplete and can miss some potentially large costs depending on what you choose.
When picking a software development team to build your product, there are many risks. Have the software developers led a software product of this size to successful completion? Do they have the right technical skillset to tackle this specific challenge? Are they knowledgeable about the business data and processes? Are they disciplined enough to adhere to a software development process? The variability in these answers can lead to complete success or failure depending on the team.
Comparatively, when choosing a vendor software product, there are many unknowns as well. Are the software sales teams exaggerating about the capabilities of their product to make a sale? Are the sales teams fully aware of what your needs are and how their product can be a good fit? How much will the implementation cost and how long will it actually take? How buggy is their product?
Many of these questions cannot be quantitatively measured, which means your team’s judgment call has a larger margin of error and risk. This explains why in some cases, regardless of your decision, project estimates can be inaccurate. If you look at statistics for implementing ERP systems, for example, the majority of implementations are both over budget and took longer than estimated, with several failed implementations to boot.
One of the most common reasons for a bad implementation is a mismatch between the needs of the company and the capabilities of the software product. Most software products have significant limitations on what they can do, or how they manage data.
On many occasions, our team has witnessed decisions made by an executive to implement an off-the-shelf product to save the company money. The idea was great - outsource the company’s software needs and reduce your in-house IT footprint. Get out of the business of software development – after all, that’s not the core focus of the business. However, what ended up happening was that the software product was not a good fit, and in order to get it to work properly, the in-house IT team had to build around the product to fill in the missing functionality. The result? The worst of both worlds. You now have to pay software licensing fees AND retain an in-house team to support it. That can double your costs - but that’s not all. Because the firm now has two products supporting one business problem, your business users’ daily experience of having to switch between the two slows them down, adding even more hidden cost to the decision.
So how do you deal with all of these risks? How can you avoid these hidden costs? There is no silver bullet to making the perfect decision between build vs. buy, but there are things you can do to improve your odds. First, make sure you have gathered all of the business needs. You need to have a deep understanding of the problem you are trying to solve before you can find the best solution. Your needs may not be the same as another company’s needs. Your needs today may be different from your needs 3 years ago. Write down all of the features you desire from software, and rank them in terms of necessity. Make sure that you identify a single business person or subject matter expert (SME) to lead the project. This person needs to have the power to make all the decisions and the time available to guide the project to success.
Second, if you are looking at a software vendors’ product, it needs to have each one of the necessary features you have listed out in order for the product to be a good fit. If you are picking a software development team, they need to understand the key features and have experience with that part of the business, as well as the ability to dedicate time to discussing the product with the SME.
Finally, test out the software as soon as you can. For a vendor product, do a proof-of-concept. The vendor should be able to demonstrate their product with your data. Your SME and your business users should all be involved as they vet the viability of the product. For a software team, start with a small piece of functionality, or a prototype. This should allow you to get feedback sooner rather than later as to how the whole project will go.
Over the years we have seen software development teams build successful products that boosted the firm’s efficiencies and capabilities. We have also seen vendor products be a perfect fit for a firm, replacing manual work and adding value. Both paths can be a success, but they require dedication from the business units involved.
