Buy versus Build Decision for Software Product

Buy versus Build Decision for Software Product

Have you ever had to make a decision to solve a business process problem by either buying (subscribing) a Commercial-Off-The-Shelf (COTS) software product (service) from an IT company or building it in-house (or getting it developed by an outsourced vendor)?

I found the following steps useful for evaluating a product or solution to navigate through the process of making an informed decision, including, but not limited to:

1.     Look at Your Corporate Products and Services Catalog

If you traveled in any airline, the flight attendants advise during the safety video or announcement, “Note that the nearest exit may be behind you.” Similarly, while evaluating a product or service to solve a business process or problem, do not forget to review the existing product and service catalog of your company. If you do not know whether your organization has one or not, try to reach out to your Enterprise Architecture (EA) or IT Service Management (ITSM) teams.

Many big corporations have already invested heavily in one or the other platforms, which may serve a specific purpose. But one might be able to use the existing platform (including current customizations and integrations) to solve the other business cases with an incremental cost.

Granted, it may not be the Gartner recommended top ranking product for a particular solution. However, if one can implement the same solution in an existing platform with marginal expense on top of the current team and licensing costs, probably, it would be worth considering.

2.     Keep the Time Horizon in Perspective

One must consider the time horizon of the product/solution for the business process.  For example, if the decision is being made for a large corporation, for any solution (product or service) being evaluated keep 5 to 10 year (or 3 to 7 year) lifespan in perspective.

Whereas, for a small company, with the restricted budget, the time span could be 1 to 2 year because no one may know what the company would look like in a year. Hence, the long-term view and heavy investment may not be justified in the latter case, and one may consider buying a ready-made COTS solution versus building a product internally.

However, for large corporations, before one could make a decision, it would be wise to gather more data and do further analysis as suggested in the below steps.

3.     Weigh the Cost of Implementation and Customization

Evaluate the implementation cost for any COTS product (service or solution) that may require some customizations, including but not limited to, integrations with any existing enterprise systems, company-specific branding, etc., before users can use it.

Also, analyze the cost of developing a solution in-house, including, but not limited to, the cost of development, infrastructure, hardware and software licensing cost, etc.

Analyze the costs not just for the resources required to make the purchased (or subscribed) solution production ready, but also for keeping the railroad running in parallel. It may include transitioning any of the existing (or manual) processes over to the new system including the cost of associated training, marketing, and communication.

4.     Weigh the Cost of Incremental Maintenance

Any software system once implemented, usually, requires some up keeping. Hence, in addition to serving the primary business needs, the primary objectives are to ensure that the solution is maintainable, flexible, and scalable under reasonable budget throughout the life cycle of the product.

At times, the implementation cost might appear less expensive (usually in case of COTS product), but the maintenance cost could drain the budget. Additionally, depending on the technology used, one might find it hard to acquire or source appropriately skilled resources for the maintenance work.  Apart from the direct impact, it may also impede the organization and teams from the lost opportunity cost perspective.

In other words, I would avoid any product or solution with high routine patching and maintenance costs. Also, technically, if a solution would make it harder for the customers to have changes per their evolving business process requirements, that solution should be low in ranking in the evaluation report.

5.     Evaluate a Prototype or Minimum Viable Product (MVP)

As the saying goes, “a picture is worth a thousand words.”

During the evaluation process of either a COTS product or an in-house developed solution, insist on a prototype or minimum viable product (MVP) where the solution would reflect the basic look and feel of the target business case.  For example, one can develop an MVP style prototype or have the vendor configure a COTS product as a prototype in proof of value (POV) environment.

People are “people,” they have their own experiences and perceptions. Moreover, each product or solution has different terminologies, acronyms, etc. For a serious evaluation process, I would not talk in abstract or vague terms that may derail the whole project. Instead, with the help of a prototype, I would try to connect and speak in the language of the business team(s).

It is easier for folks to understand prototype during a presentation that some may call a picture on the board as a wire-frame and some as mock-ups. Nonetheless, they are looking at the same user interface, behavior, input, and output.

Additionally, it tends to trigger a healthy interactive dialog that would draw much-needed feedback out of the stakeholders – an essential ingredient for a successful project.

6.     Estimate Cost Savings — Direct Cost Savings or Cost Avoidance

One of the most critical aspects that C-Suite folks are in interested in is what value would the evaluated (proposed) solution add to the company.

In the business case, IT teams may phrase it, like, “it will automate XYZ process,” “it will help ABC team save QPR hours daily,” or “it is the industry best practice,” etc.

However, believe it or not, the only value most of the times folks sitting on the finance committee are interested in is would it save cost somewhere, or would it help avoid expenses anywhere.

In other words, pay extra attention in analyzing and articulating the benefits that genuinely reflects the projected cost savings of the evaluated product or solutions.

7.     Negotiate

Yes, bargaining works, even at the “fixed-price” shop — it is called the introductory discount for “x” time-frame! For example, for a cloud-based COTS product, one can negotiate the licensing cost. For an in-house developed product, one can negotiate the hourly rate for developers and infrastructure licensing costs, etc.

Just because the project is funded as part of the original budget planned for the year, it does not mean the cost control goes out the window.

What the worst that can happen? They may say, “Sorry, we cannot reduce the prices, or we have a fixed-price policy.” Or they may say, “We have already quoted you discounted rates.” Nonetheless, it would be worth a try.

In general, there is no silver bullet — the above list is not an absolute list of steps for all the situations. However, keeping these steps in mind while evaluating a product or a solution, one can avoid making a costly mistake.

Comments are closed.