Recently, I saw an online discussion responding to a request for advice on building vs. buying Quality Management System (QMS) software. About a dozen people familiar with various QMS software products offered advice. Only one or two addressed building vs. buying. Instead, most focused on brief perceptions of particular QMS products; and they generally agreed that available products don’t fit their own situations well.

I found the posts unwittingly revealed several common causes of why so many software acquisitions in general, and apparently QMSs specifically, encounter difficulties. Although “software acquisition” usually equates to buying, it actually is broader and starts with the building vs. buying decision.

Why Analyze Build vs. Buy

Many acquisitions skip build vs. buy analysis and jump right to specific products, probably unaware they are missing important benefits from a relatively small analysis effort, including more realistic expectations and guiding more productive actions.

A feasibility analysis compares various alternative approaches for accomplishing a set of requirements. Building and buying are commonly-considered alternatives. Sometimes alternatives include subcategories within building and buying. For example, one could evaluate buying an existing QMS product, a custom-built QMS, or a customized existing QMS product—all to operate on the buyer’s facility. Other alternative approaches could include also buying services to operate such acquired products or buying Software as a Service (SaaS)), where the seller provides and operates a QMS product for a number of different clients. Each SaaS client’s version is operated separately, and usually key variables can be tailored for the client’s preferences.

Feasibility analysis asks for each alternative:

• Can the approach reasonably accomplish the desired results?
• What are its likely costs and benefits?
• What are its technical, managerial, and business strengths and weaknesses?

After adjusting to address risks and deliver roughly comparable results, respective Returns on Investment (ROIs) are calculated. To estimate alternatives’ ROIs, obtain general cost information from the vendor for a representative foundational QMS, and if needed also for a higher-end product with extensive additional features. The approach with the highest ROI that exceeds the ROI of No Change (continuing business as usual) ordinarily is selected.

Then, if buying is indicated, prospective vendors of the selected approach are invited in a Request for Proposals (RFP) to propose specific product/service solutions and their prices. The acquirer evaluates how adequately each proposal satisfies requirements stated in the RFP and its relative costs and benefits ROI. The proposal with the most advantageous net benefit ROI is chosen and contracted for.

Building a QMS

Many organizations have unique requirements that existing QMS products apparently cannot satisfy. Similarly, using a particular QMS product could force the buyer to adopt undesirable or even unacceptable methods and procedures.

Building a QMS maximizes the buyer’s control, so the QMS satisfies the buyer’s unique requirements, including responding to requirement changes and applying preferred methods and procedures. Building can reduce costs of maintaining the QMS after it goes into production, since internal technical staff usually cost less than vendors charge for similar maintenance services. Moreover, developing advanced internal QMS knowledge and skills can be valuable.

However, building a QMS incurs far greater risk of taking longer, costing more, and performing poorer than expected; and you can’t tell what you’ll get until it’s already built.

It takes (far) longer for a built QMS to become operational than buying one that already exists. Development takes considerable time and requires technical and management capabilities the organization may lack, especially adequately defining requirements and design.

General Advantages of Buying a QMS

Even organizations that have set a policy of only buying software can benefit from evaluating feasibility of alternative approaches. Ordinarily, buying a QMS is far less expensive than building one, because its seller can spread the costs of building it among multiple clients.

Buying an existing QMS dramatically shortens the delay until it is operational and greatly reduces risk, because the buyer can see exactly what they are buying before they buy it. Moreover, often the seller already has had opportunity to detect and correct defects.

Although discussion comments questioned the suitability of commercially-available existing QMS products, they usually represent the thinking of QMS and development specialists. Thus, there is reason to believe they do what is needed, often in ways that builders with less expertise might not know to build. As such, a QMS product may incorporate methods and procedures an acquirer could benefit from adopting.

Other common advantages of buying a QMS include better documentation, Help and similar support, and regular updates of core functionality.

General Disadvantages of Buying a QMS

The biggest weaknesses of buying a QMS relate to not satisfying an acquirer’s unique requirements. This can hamper the QMS’s ability to serve its purposes and may necessitate the acquirer’s changing its methods and procedures, which can be costly and risky.

Customization is the way to satisfy unique requirements and can range from modifying parts of existing software to engaging a vendor to build an entire QMS. Customization is building, which is risky. The more customization, the higher the cost and risks. Engaging a vendor to build an entire QMS is maximal risk, reduced somewhat due to the vendor’s presumed greater skills and knowledge. Risk is lower when the vendor customizes their existing software and higher when an acquirer customizes it.

Post-implementation maintenance is similar. When provided by the vendor, costs are higher but risks are lower. Custom maintenance for the specific acquirer is ordinarily charged separately, whereas periodic product updates for all users of the QMS product are usually covered by a relatively economical standard maintenance contract.

Acquirers who choose to maintain an acquired QMS themselves may seem to save money because their internal staff costs are lower than a vendor charges. However, risks (and often costs) increase because the acquirer’s staff typically is not familiar with the QMS product and thus spends more total time due to encountering more difficulties and making more mistakes. Turnover of key internal staff can be especially damaging.

SaaS offers a variation that many acquirers find attractive. With SaaS, the vendor also operates and maintains the software, so their financial model includes spreading development costs not only across multiple customers but also across multiple years, cushioned by added revenue from integrated operations charges. Core SaaS systems are designed to be tailored, which increases their initial development cost and complexity. That is, they usually include a number of pre-built optional processing choices, so each customer’s version is somewhat unique without incurring the added risk of customization.

The SaaS acquirer’s risk is that available tailoring does not suffice to satisfy the acquirer’s unique requirements. SaaS vendors vary in the amount and cost of additional customization they will make for an individual customer. When a customer requests customization that would benefit other clients of the SaaS vendor, the vendor may choose to make it available to all customers and hopefully therefore charge the requesting customer less or even nothing for it.

Bottom Line

Building or buying a QMS could be right for your organization. It’s generally advisable to perform a feasibility analysis comparing these and other relevant alternatives. Such analysis starts with defining one’s QMS requirements, which too often is not done adequately. Prematurely focusing on particular products, especially ones the acquirer is familiar with, may seem like a logical approach but actually easily distorts requirement’s definition and feasibility analysis.