Deciding to Build Versus Buy Software Products

The build versus buy decision is often a hard one to make since software vendors routinely over-hype their products. Buying point products that are “best of breed” and simple enough to be piloted in your environment with your data is the only way to get past the hype. Buying suite products that attempt to automate everything imaginable always entails a high upfront cost and a high risk of project failure. Some vendors have gotten this message and are starting to modularize their products. The reality with ‘suite’ products is that they do 50% of the business processes pretty well and the remainder is often “marketing tick marks” which are not fully built out.

In today’s competitive business environment, all companies need to focus their precious IT resources on activities that support their core competencies. They can’t afford to be distracted from their mission by reinventing the wheel. This inevitably leads to the ongoing issue: Should technology be built or bought?

Just because something is built in-house doesn’t mean it’s “free”.

In determining the right answer, there are four questions to consider:

How Much Will It Cost?

This is literally the $10,000 question (or $20,000, or possibly more). Just because something is built in-house doesn’t mean it’s “free”. Make sure you’re considering the cost of the internal resources that would be used to build a solution, so you have an apples-to-apples comparison. This will require that you talk with all the stakeholders and gather requirements for the software, from which your internal build team can provide a time and cost estimate.

For the ‘buy’ side, obtain a quote from a software vendor and estimate both your internal cost to roll out the software and the integration cost, as well as any configuration or customization costs. This estimate should be reasonably accurate. Compare it to the cost estimates of internally developed software.  Keep your specific requirements in mind, many of which you may not fully understand until you’ve gone through demos of the vendors’ products.

In addition to initial rollout costs, find out what your costs would be for ongoing support and maintenance of the new software for both a purchased and an internally-developed system.

How Long Will It Take?

Is the system something you can create and roll out faster than a vendor could implement it? Rapid deployment is critical if you want to realize benefits immediately. At times, homegrown solutions become obsolete before they’re even completed, while purchased solutions can be up and running in less than a month.

In a few years, the system may need enhancements that will be absolutely critical at that time. Who will do the work?

Also consider how long it would take to build new features into an internally-developed system, and if that time will meet the needs of the organization. With any cloud software solution on the market, new features will be deployed and available within days of release; however, ask any vendors you’re evaluating about their product release cycle so you can understand how often and how quickly to expect new releases. You may even want to ask about their feature request process and how they integrate those requests into the product.

How Risky Is It?

How solid is the vendor? How many customers do they have and how happy are they? Talk to some customers who are using the product in the same way as you expect to. Companies that claim to have thousands of customers should have one in your city whom you can visit. Call their bluff and visit one of their customers.

Conduct the same level of diligence on the build-it-yourself option. Building an in-house solution requires staff for maintenance and upgrades, and these costs can be difficult to estimate. Keeping pace with technology advancements is time-consuming and challenging, and takes staff away from your core business. Often, you’ll end up with one person who “owns” the system and is the only one who really understands it. What happens if this person quits? In a few years, the system may need enhancements that will be absolutely critical at that time. Who will do the work? If you’re contemplating writing your own time tracking system, ask yourself if you really want to become an expert in this kind of technology. These systems can be much more complicated than you might think, especially if your organization has certain compliance, security, and data privacy requirements.

You will also need to think about other needs of the organization, which may end up being beyond the scope of the build project and/or the competencies of the internal resources:

• Is a mobile app needed?
• Does it need to integrate with other systems?
• What kind of reporting is needed? How will those reports be generated and what will they look like?

How Strategic Is This?

What will your IT shop learn from building this application in-house? Is this knowledge consistent with your company’s core business strategy? Will the education your team gains from this exercise lead to improved capability for your company’s business, or will it detract from more appropriate knowledge? These are hard questions to answer, but necessary if your goal is long-term success.

The general rule for IT organizations when making a build or buy decision must be centered around quick and inexpensive “hits,” as well as projects that just cannot be purchased at any price. Furthermore, if you make the decision to buy a time tracking platform rather than build one, there are numerous considerations you must take into account in order to choose the right time tracking solution for your business.