Weighing options: Build vs. Buy: A Fresh Look & Other 'Gotchas'

Commonly accepted wisdom on Wall Street holds that firms should almost always buy off-the-shelf packaged software because "building custom applications is too risky, costly and time consuming." This, together with the widespread perception among many in senior management that integrating multiple applications is somehow now 'simple' has tilted the age-old 'Build vs. Buy' debate strongly in the direction of buy.

Much of Wall Street seemingly suffers from cognitive dissonance, since not all firms subscribe to the prevailing wisdom. On the contrary, all the major firms have hundreds, if not thousands of programmers dutifully engaged in, what else? Application development. So, what is going on here; are all firms that insist on building custom software applications just crazy? We will answer this question by:

- Debunking myths about custom software development as we take a closer look at misguided comparisons with purchasing packaged software.

- Offering fresh perspective on some 'Gotchas' or 'Hidden' costs and risks of buying software.

- Providing a big picture view and 'rules of thumb' for when to buy versus build software, together with an overview of what the essential tradeoffs are.

Debunking the Myths

The myths-stemming from the never-ending supply of failed software development project horror stories-revolve around cost, time, risk and complexity, which are interrelated parameters.

The process of deciding what to buy, if performed with proper due diligence, can itself cost a sizeable percentage of the purchase price. Likewise, the further away from the 90 percent plus functional requirements 'fit'-what we see as the minimum necessary for a successful installation-the more the package will need to be customized or tailored, with concomitant increase in ultimate cost, not to mention risk. The cost of 'wrap-arounds' can easily double the listed sticker price. Research published in Forbes magazine showed that for every dollar spent on Enterprise Resource Planning (ERP) software, firms spent another $4 to $10 installing and customizing.

When an 'apples to apples' comparison is made, and all relevant costs are considered, including 'hidden' costs we discuss below, the cost of building software is often competitive with the cost of buying. This can be especially true when choosing between building one integrated system, versus buying and combining multiple vendor packages.

It is an understatement to say that not all packaged software implementation projects are successful and cost-effective, even with broad definitions of 'success'. Nor are they easy and simple. The risk of failure is great, and it occurs far more frequently than commonly thought. Consider too that many firms will 'declare victory' even if they end up not using the package or have suffered from excessive cost and/or time overruns. Unfortunately, it is not unheard of for firms to have even gone out of business because of a 'mission critical' package implementation failure.

Packaged Software 'Gotchas'

Arguably the most critical and overlooked cost of buying off-the-shelf software is the opportunity cost of giving up business functionality, and thus the ability to differentiate one's firm from the rest of the pack. This is increasingly important as competition intensifies on Wall Street. After all, what kind of competitive advantage can be achieved by using the same vendor package as 18 other firms?

Since the 'fit' is rarely even close to 90 percent, new customers are typically faced with three choices: use as is; change the way the firm does business to fit the product; or heavily tailor the package.

Both the first and second alternatives result in sub-optimal benefits. The third is fraught with peril, whether the vendor or customer does the customization. In the worst case, it can even contribute to the vendor's demise, which is bad for both vendor and customer. We elaborate on this risk below. To their credit, some vendors are quite disciplined on this point and adamantly insist on a single code base, so that heavy tailoring is not always even an option.

Veteran customers can suffer from a similar phenomenon, when they desperately need custom enhancements, but no others do. In such cases, the poor customer may be forced to get in line, wait and hope. This situation is the flip-side of the coin of one of the benefits touted for going the off-the-shelf vendor route, a broader installed base of customers for maintenance, support and enhancements, and illustrates what could be called 'conflicting objectives' risk that customers often face.

Vendors are caught in the 'eternal tug of war' between promises to veteran customers, newly won customers and prospects they are trying to land. Often there is an element of 'bait and switch' in that whatever the vendor promised about customized enhancements after the customer's purchase, they are more likely than not focusing instead on what it needs to develop to achieve the next sale.

The worst case example of the inherent conflict between a customer's desire for stability, i.e. the wish to avoid unnecessary change, costs, etc., and a vendor's need for new sales, is a desupport notice. This is not as uncommon as one would think. Just because you are content with the technology platform you purchased years back does not mean that the vendor can still afford to support you when yours is the only firm remaining on that platform.

A customer can never really know for sure that a vendor it has chosen will remain in or committed to the business long enough to support him in the future. This is especially true when it comes to our industry, since the dynamic and complex investment software marketplace is in a constant state of flux. New vendors are constantly streaming in, and existing ones are exiting, either voluntarily, via merger or in the worst case, via failure.

Ironically, as we alluded to above, the risk of a vendor failing increases the more accommodating it is in terms of heavily customizing its code for multiple customers. The best example is the firm that created a new market space for PC-based software for the buy-side while reportedly implementing upwards of 20 different versions for its customers. When two paradigm shifts hit it at once-from Btrieve and DOS to Sybase and Windows-the firm was like the proverbial deer caught in the headlights, as it tried to deal with existing customers who desperately wanted to get off the old platform, while simultaneously getting a new technology version ready so that new sales would not dry up. No surprise when the firm-with its limited R&D budget-was forced to sell itself to a major industry player.

Another risk associated with heavy tailoring of packaged software is that of reduced support and/or the inability to take advantage of future enhancements, especially, though not only, when the customer does most of the tailoring. This is also ironic in that many firms choose a packaged solution because they prefer not to have to deal with either software development or support. Of course, firms can always follow a different path and farm out both custom software development and support if they decide that they are willing to forego the benefits of the broader installed base of a package vendor in return for individualized responsiveness and more control inherent in a one to one relationship with a custom software developer.

The last 'gotchas' we touch on go together, and can be called integration and complacency risk-the idea that 'best of breed' is so simple and easy breeds nonchalance. We have seen enough package installation projects fail because they were seen as so 'simple' that common sense went out the window. Integration risk itself rises exponentially as the number of packages to be cobbled together increases.

The Big Picture

So, when should you absolutely only buy software? Let's oversimplify to make the point. If all of the following are true, it would be insane to even consider building:

- No competitive advantage can possibly accrue from a custom built system

- Firms all perform the business functions/processes to be automated the same exact way.

- Close to 100 percent of the functional requirements are met by the package in question.

- There exist at least a couple of established, quality vendors who are committed to the market

We are not saying that unless the above criteria are met firms should always build, as opposed to buy, software. This would be ludicrous-since aside from the case of basic office automation type software (a la Microsoft Office, etc.) it is rare for all of the above to be the case. With the exception of the easy case regarding pure 'shrink-wrapped' software, in the real world the choices are more complex.

Conceptually, the build vs. buy choice should be seen as a continuum and not as a binary decision. The more a vendor package is customized, the more the project actually resembles a 'build' decision. Since few would view trading and investment systems as anything like 'shrink-wrap,' decisions regarding the deployment of such applications merit careful thought and consideration as each firm weighs the respective functionality, cost, risk and related tradeoffs that apply to its unique situation.

In summary, following are some of the key issues and tradeoffs that decision makers must bear in mind as they consider the build vs. buy dilemma:

- Cost, functionality and risk are all easily mis-estimated.

- Purchasing software involves its own 'hidden' risks and costs, which increase the more a package needs to be customized.

- Use of IT as a strategic weapon and as a point of differentiation vs. just trying to keep up

- Ability to control one's own destiny in the face of 'planned obsolescence' and special requirements

Potential benefits of one fully integrated system vs. integrating multiple vendors:

- Avoid the siren song of 'best of breed' and the associated complacency.

- Deal with fewer vendors

- Fewer interfaces, errors, reconciliations, and corrections and therefore lower costs

Whichever path is pursued, firms that dismiss the build option out of hand are clearly doing themselves a disservice.