A Case Study in Build vs. Buy Decision Making

Every business with any sort of programming staff on hand has been faced with a build vs. buy decision. The company in this particular case study has a propensity for building everything stemming primarily from a cash flow problem in combination with a tendency for the management team to prefer intangible vs. tangible costs.

Building was the right choice:

In many cases over the years the decision to build many of their in-house tools has proven advantageous. One of the divisions has many hourly workers, and they needed a time card system of some kind. At the time, open source was not what it is today, so they had the choice of paying monthly for ADP's software, or using their own. This proved to be a great opportunity to create a simple tool that later grew as demands changed. Today they have a nice little application that handles the time card functionality as well as all the other HR data they need to collect and with a click of a button they can generate fully customized reports.

Another success story is in their telemarketing department. They needed to find a way to take calling lists in from the clients they serve, and then contact those customers and report back the changes. Software for telemarketing applications is typically geared toward large firms and costs thousands and thousands of dollars which they really didn't have to spend. Instead they plodded through the development of their own, customized solution and over the years have refined it as needs arose. They were well served by the ability to change things on the fly as clients' needs changed and today, they have a solution far better than anything commercially available since it is designed for their unique situation.

Building was very wrong:

This same organization later decided to branch into another area and needed to create a CRM solution. The new venture would be a much more traditional telemarketing situation and was intended to scale much larger than the other side of the business. Having seen success with the last CRM-like solution created, they decided to build yet again. Rolled in with this CRM though was a large need for reporting capabilities, as well as accounting, billing, and invoicing functionality. Despite the much larger scope, the decision was made and off they went.

Unfortunately, it was an ugly thing to watch. Delay after delay caused high tensions and missed deadlines as they tried to create things they had never dealt with before. No one on staff had any experience with accounting, and since there was no one defining specifications, the developers were just stabbing in the dark. This whole project just went horribly wrong.

A couple years into the business, they were having many problems and finally decided to buy a new solution for thousands of dollars. Unfortunately, undeterred by the cost, and wooed by the sales person that told them how easy the migration would be, they pressed forward, signed the deal and started implementation. That's where they met insurmountable challenges that they simply were not equipped to handle. To this day (about 3 years in), they are still struggling to fix the system that is handcuffing their growth.

What's the right answer?

Of course, the right answer is “it depends.” I also believe though that some simple principles can be employed to maximize the chances for success. Firstly, a real cost-benefit analysis HAS to be run on both scenarios. Intangible costs can be astronomical and can really cripple companies who underestimate it. The firm in this case study was bitten by a lack of analysis quite badly. They had an opportunity to be very early to the market, and could have grown very rapidly, but due to a severe underestimation of the resources required to build and maintain their CRM system, they have been struggling just to stay alive.

A company should seriously look into building, or obtaining open source solutions that they have sufficient staff to maintain when they are looking at building single task tools. If they are looking at a time card tracking tool, then it makes sense to build it. This is especially true when there are unique needs surrounding the situation. I cannot stress enough though the importance of looking ahead and not underestimating the resources needed to maintain the software.

The decision to buy comes in when looking at complex systems. Something such as a CRM can be very complex indeed. When combined with needs for invoicing, billing and overall accounting, it is extremely complex. At that point it will span several departments including sales, marketing, accounts payable, accounts receivable, procurement, and advertising. All of these departments will need to be stitched together in order to make the CRM of any value. The company in the case study had success in the first CRM-like application because it was focused on outbound tele-sales and had nothing to do with any other departments. Fundamentally, if your firm does not have substantial in-house experience with the type of application you need to develop, then buying it is probably your best bet.