recently i was asked to review a proposal for the medium term development strategy (covering the next 3-5 years) for a company that was contemplating a major extension of the functionality of their in-house business system. one of the key questions being raised was whether the company should continue its current practice of in-house software development or should attempt to replace its custom software with off-the-shelf packaged product(s). this is clearly a fundamental decision with many ramifications and implications, and is not something that can be handled in a 30 minute meeting on a wet friday afternoon (not that they were even suggesting such a thing). while the following is only a part of the final result, it does address some of the key points at issue and may be of some interest, and maybe even of some use, to others.

build or buy?

this is a fundamental decision that will dramatically affect the organization in all aspects of its operation. currently the company keeps the responsibility for the design, implementation and maintenance of its business critical software in house by employing both development and support staff. it is likely that, in order to support any major extension of the current suite of software, the requirement for it staff, and probably for external support (i.e. consultants/contractors) even if only in the early stages of development, will increase. in the light of this, the possibility of purchasing packaged software rather than undertaking the development directly is potentially attractive.

however, it should be borne in mind that while it is often true that buying an off-the-shelf package reduces the need for in-house it development (and even support) it does not remove it completely. since the software in question is undoubtedly “business critical” the possibility of losing the system and being unable to obtain the necessary support must be taken seriously. at the very least, a full operations staff will be needed to ensure continuity of service and system availability and to manage routine operations connected with system maintenance and security. however, there are other issues that must be taken into consideration before buying a software package even assuming that suitable candidate(s) can be identified.

functionality

the first, and unquestionably the most important, is that of functionality. this is a major problem, which affects all off-the-shelf software because there is a direct contradiction inherent in all packaged software. simply put, in order to be attractive to as many potential customers as possible the software must encompass as wide a range of functionality as possible. however, any one client has a particular set of requirements that will probably require only some fraction of the whole and so they may end up paying for functionality that they neither need nor want. consequently, packaged software falls into three broad categories:

  • first there are the non-specific software packages that we all use daily. this group includes all development tools and applications like word processors and spreadsheets. these are not, in the context of the build or buy debate, "packages"
  • second there is software that implements a specific set of functionality that is governed by fixed rules. this is definitely  the most successful and widely available packaged software. the differentiation between such packages is largely down to the design of the user interface, the degree of modularity (i.e. how much of the totally available functionality you have to buy) and the ease with which the application can be integrated with other software. for example, all accounting systems have to  be functionally identical (i.e. they must have gl, ap ar and these must function in a way which complies with irs statutes, accounting practices and the law) but there are nevertheless numerous variations available
  • finally there is software that is designed specifically to facilitate the operations of a particular industry or market sector (often referred to as ‘vertical market’ software). such software often originates within a single company or organization and is then ‘generalized’ to a greater or lesser extent and offered to other companies in the same business.

any packaged software that is to replace a current, customized and in-house built application would fall into the third category. the issue with implementing any such software within an existing organization is the “degree of fit.” since, by definition, the software has not been designed in house it is absolutely certain that it will not operate in exactly the same way as current application does.

the key question is, therefore, the degree of divergence between the company's methods and procedures and those that underpin the software. a fit of less than 90% should be grounds for immediate rejection; moreover, customization of either functionality or processing should be eschewed at all costs. the reason is simply that all software is built around a set of assumptions, and those underlying assumptions drive all functionality and processing. if the functionality and processing methodology do not obviously fit the organization’s requirements then it is a sure indication that the underlying assumptions are inappropriate. any attempt to force the software to work in a way for which it was not designed (i.e. customize it!) is doomed to failure.

the general rule when considering off the shelf software is that the only way to successfully implement it is for the organization to adopt the exact functionality and processing that the package provides. the only customization that should be undertaken (apart from cosmetic items, like changing logos and report layouts) should be for totally new functionality.

in the most successful implementations of off-the-shelf as a replacement occur when either:

  • the organization wishes to change its operating process and procedures, but does not want to re-write its entire suite of software in order to do so. in this case the new software is the mechanism for implementing change
  • the organization wishes to extend its existing operations but has neither time, nor resources, to undertake the necessary development work. in this case the new software is the mechanism for introducing new functionality

notice that in each scenario the packaged software must be implemented 'as-is' and does not attempt to duplicate the current system's implementation.

change management

the second issue, only slightly less important than functionality, is that any company is a provider of services whose success in the market place depends, to a greater or lesser extent, on being able to respond quickly and efficiently to changes in requirements. when software is under the direct control of the company, changes can be implemented in whatever fashion, and at whatever pace, best suits the organization's operational needs. in other words, as long as control of the software and development resources are under the direct control of the organization it is not only in control of, but actually drives, change.

as soon as packaged software is involved, this ability is lost totally. instead of being the driver of change, the organization is reduced to being the recipient of whatever the software vendor deems to be the most appropriate solution for their needs in a timescale that they define. the more widely a given package is used, the more difficult it is for the vendor to implement changes quickly; if only because of the necessity to assess  the potential impact of any change on a variety of different clients.

while this is not necessarily a bad thing, it does represent a loss of control over a function that is often critical to the success of the organization as a whole and the realities and implications of such a loss of control must be fully investigated and accepted. while slas and similar contractual agreements can mitigate the risk, the fundamental question remains one of 'what-if…?' and answers should encompass scenarios ranging from the inconvenient (e.g. minor functional issues) to the catastrophic (e.g. the vendor's business collapses overnight).

cost

the perception of the cost of packaged vertical market software is often that it is significantly cheaper than custom development. in reality, the difference is rarely that significant, although it is undoubtedly true that the apportionment of cost over time will differ significantly. typically custom software has a high initial cost that declines with time while packaged software typically has a lower initial cost but has static, or even increasing, on-going costs.

this is simply because the development costs of the packaged software are borne by the supplier and amortized over time and across their entire client base. in addition to the initial purchase price there will also be an annual maintenance cost, typically in the 15-20% of initial cost range,  and usually with an annual increment built in. the cost comparison chart for "build" (black) versus "buy" (red) typically looks something like that shown at figure 1:

the consequence is that the total cost of acquisition and maintenance over the typical software life span of five years is usually comparable and, in some cases, custom software may actually end up being cheaper. 

 

figure 1: software build (black) vs buy(red) costs over time

however, the cost of the acquisition is only part of the story. taken over the system life span, the cost of the software itself is typically only 10-20% of the total. alan maccormack (assistant professor of business administration at harvard business school) stated in a 2003 paper that:

where costs do become significant for all types of software is in the level of staffing needed. by staffing, i mean the training, maintenance, support, administration and other personnel costs necessary to run the software package efficiently. these costs can add up to as much as 50% to 70% of a software system's total cost of ownership over its useful life.

normally these costs are not directly affected by the build or buy decision although if the vendor's consultants have to be used for training (a by no means uncommon condition when acquiring packaged software) there may be some direct impact.

conclusion

there is no single 'right' answer to this question, each case has to be treated on its merits. however, the more specialized a company's systems are, and the more frequent the requirement for rapid response to change, the more important it is for the company to retain direct control over its software.

apart from any other consideration, there is always the possibility that, by developing custom software for itself, the organization may find that it has ‘accidentally’ created a new vertical market application that has the potential to become a revenue generator in its own right. however, it should be stressed that this possibility should not, in itself, be grounds for choosing in-house development over a packaged solution – if only because all the reasons given above for not buying packages apply equally to other organizations to whom the company might eventually try to market their custom solution.

 

2 Responses to New Software – Build or Buy? A Personal View

  • boudewijn lutgerink says:

    Good read Andy,

    In his book “Return on Software” (ISBN 0-321-22875-8) Steve Tockey writes about this as well. In Chapter 8 and 9 He writes about “Bases for Comparison” of SW packages and “Developing Mutually Exclusive Alternatives”. A good read for anybody who is interested in making good decisions on this. I definetely consider your ideas in this blog worthwhile.
    Thanks for sharing.

    Well, it’s a topic that comes up so often in this business, and there is often a great deal of misinformation surrounding the discussion. That’s a very good reference you gave too. Thanks — Andy

  • Jun Tangunan says:

    Andy, this is an excellent topic (as usual).  I hope that prospective software buyers will also read this one.  Most companies I have seen so far is thinking that buying vs in-house developing is better.  If they can read this, they will think twice now.  

    One reason somebody gave me before is that an existing package out in the market has already been tested to work by other companies.  And I countered, “yes, but if it means changing your entire current manual operation to suit the design of that package, then you have to do it.  The software won’t adjust, YOU have to adjust! Are you willing to do that?”.  During that time I won. Still, more and more companies are opting to buy.

    Buyiung is not necessarily a bad thing, providing, as I tried to say here, that the decision is made on solid grounds and not simply on vague promises or assumptions.

    I  remember a company I worked with many years ago rejecting a bid for a custom solution of under half a million because it was”too expensive” and, at six months would take too long. They went instead for an off-the-shelf package from a major corporation and ended up spending over three million by the time they had done “customizing” it more than two years later. It almost bankrupted the company, and cost the IT Director his job – a truly great decision!

Leave a Reply

Your email address will not be published. Required fields are marked *