We’ve all been there, faced with the options to either buy or build an IT solution. Whether it is our responsibility to choose or to simply recommend the best option, we all seem to forget one key element in this decision. This element is called the opportunity cost.
Over the past several years, I have had the opportunity to work for a variety of companies on projects that utilized pieces of proprietary software within the technology architecture. These have included everything from a bulk e-mail generator to an application server. While on the surface, there was nothing technically wrong with these applications, I found myself often wondering, “Why build it yourself when there are so many commercially available products on the market?” So off I would go asking this question and every time, it came back to one simple answer: “It was cheaper to build it then to purchase it.”
Yet, as I worked on some of these projects I couldn’t help but feel that the projects were being negatively affected by these home-built technologies. Now came the big questions, “How much did building it in-house save?” “What is the cost of future projects that must utilize the technology?” “How much is it really costing to maintain the technology?”
As I investigated and pondered these questions I came to the conclusion that when the go-ahead for building these items was given, no one gave any consideration to the opportunity cost and only considered the acquisition cost of the technology (short term costs). To demonstrate my point, consider the following theoretical example.
A middleware piece of software is required. The purchase cost is $200,000 while the cost to build it in-house is $100,000. On the surface this is a no-brainer. Build it yourself and save $100,000. Ah, but consider the following. First during the building phase, you need to reverse engineer an existing technology. Guess what, you are only going to be able to reverse engineer something that is already on the market and not the next generation of the software which is about to be released. If these next generation features are valuable to your organization you will have to add them on at a later date (future development cost=$60,000). While your staff is busy building the software, your company could have already purchased, taken delivery, installed the software, and been profiting from it for several months (time to market opportunity cost=$30,000).
Next, you’re required to dedicate staff to the building and testing of the software. What else could your staff have been working on that goes more to supporting the core business (the opportunity cost = $20,000).
The other two sources of opportunity cost are future development and training. Once the software is built, the IT staff is reassigned and no one is available for enhancements or fixes on a timely basis. If purchased externally with a maintenance agreement, you would be automatically receiving bug fixes and version enhancements. Remember that someone also needs training to use the software.
With commercially available software there are manuals, training facilities and frequently published books on using the software. None of this exists for home grown software. Finally as you face staff turnover, you can’t simply go out and hire someone who knows the software. Instead you are forced to hire someone with experience with a similar commercial product and then train them on the difference between the two (the opportunity cost=$10,000).
In this example, building it saves $10,000 over the first year. Is building it in-house truly worth all the associated headaches? Now consider the on-going costs beyond the first year. It is easy to assume an annual cost of $30,000 on a maintenance contract and at least twice that cost for in-house development (including all opportunity costs) assuming an annual major upgrade.
Now you may be thinking that I would never advocate building software in-house. On the contrary there are many instances where it makes sense. All I ask of you is when you’re making such recommendations or decisions, you consider the true cost (including opportunity costs) of the project. When you do this, you may surprise yourself once in a while.
K’necht is a Toronto-based consultant specializing in the project management of Internet and other technology projects. He is a frequent speaker at technology conferences and can be reached atalan@knechtology.com.