Build vs Buy Software?

Introduction

Ask any software vendor what are the three words that strike dread in their hearts and the answer nine times out of ten will be “Request for Proposal” (RFP)!

Generalising, there are 4 Types of RFP, which I have listed in order of vendor preference:

  • A well-written genuine RFP – this is the best to deal with as it is organised in a logical and straightforward manner. That said, even the best written RFP will still take many man-days for a vendor to complete. Unfortunately, these are the rarest type of RFP.

 

  • The poorly-written genuine RFP – this is when a client is either very confused as to what it is they actually want, or the RFP is poorly written and confusing. Lazy clients will often cut and paste from previous, often unrelated RFPs, and then omit to edit out the sections which are not applicable. Many hours or even days are wasted by vendors trying to understand what the RFP is actually asking for!

 

  • Making up the numbers RFP – this is dreaded by vendors, as whereas the previous two RFP types indicate the genuine opportunity to win business, this type of RFP is issued by a prospect that needs a minimum of three bids. Accordingly, in addition to the vendor that they have already selected for the work, two unlucky vendors waste a lot of time and effort. They never even had a fair chance to win the contest, as the final outcome was already decided.

 

  • Brain Picking RFP – this is by far the most irritating RFP type of all, whereby the prospect will pretend to be going through an RFP process, be fully engaged and have lots of walkthrough meetings and many questions. However, in the end the vendors find out that nobody actually won the business, it was awarded to the internal IT department, who had conducted the exercise all along in order to get free training and insights into product design and functionality.

 

Having fallen victim to all three types of ‘bad’ RFPs over the years (a well-written genuine RFP is always a pleasure to deal with), this got me thinking more about the rationale behind why some companies decide to build rather than buy.

Adaptiveus, which is not related to ADEPT Decisions, describes the whole process of build versus buy analysis as:

“The “build versus buy” analysis is a framework that businesses use to make technology decisions. The analysis is used to compare the cost and benefits of developing a new technology internally (i.e. building) with the cost and benefits of purchasing an existing technology from an external supplier (i.e. buying).”

Source

 

This article will focus on why companies should buy software, rather than attempt to build in-house, which is a process that often ends in tears!

 

Why Buy?

Disclaimer

This article is written by a software vendor and so could be viewed as biased, or one-sided, but in reality, the case for most companies purchasing software in most instances is rock solid. (Note: I am specifically avoiding saying that all companies should always purchase all of their software applications!).

More Cost-effective

Typically, a purchase decision will end up being more cost-effective over the long run. A purchase involves fixed costs, and any overruns are normally at the expense of the vendor. Delivery dates are typically agreed and set and so any slippage will often result in vendor penalties.

Cost increases are known and budgeted for over the lifetime of the contract and so it is very straightforward to accurately predict what the lifetime cost of the software will be.

In addition, as less client internal resources, both from the IT and user departments, are required on a full-time basis, the opportunity cost of a buy decision is a lot less than that of a build decision. (If your own IT department is at maximum capacity due to the inhouse development of a decision engine, then all other projects will be on the backburner, thus costing the company money and lost opportunities).

Better and Faster End Results

Whilst it is hard to quantify, a purchased software package will typically be superior to an inhouse build and will produce better results. A specialised vendor that is focused on the product, which is essentially their ‘bread and butter’ will have a better understanding of best practices and what the best technologies are to achieve them.

In addition, a vendor that has worked with multiple clients will know what works and certainly what does not work!

Finally, a buy software package will logically be a lot faster to Go Live, than an internally developed solution, which has to be built from scratch.

Access to Specialist Resources

By pursuing a buy decision, a client will gain access to a wide range of specialist resources that work for the vendor. These resources will typically have many years of domain expertise which is probably not available within the client’s internal team.

The cost-benefit of hiring these high-cost resources as employees is probably not a wise decision, as opposed to engaging with them as vendors during a project on a short-term basis.

Flexibility

Engaging with a software vendor provides significantly more flexibility for a client than developing inhouse. The client does not need to re-deploy large amounts of personnel to a software development project or hire a new team. All resource challenges are borne by the vendor.

In many markets, hiring new team members is often a long-term commitment and can become expensive, thus should be avoided, unless the company’s IT department is in empire building mode! This is often the case when a build decision is made. The other main personal driver of a build decision is job security for the IT managers.

Scalability

Associated with flexibility is scalability. This is a strong driver behind a buy decision as it ensures that a project can ramp up and ramp down to match a client’s requirements. This type of flexibility is not really possible with a build approach.

Whereas an internal development will often face resource constraints, which typically result in project timelines slipping, a vendor has the ability to scale up and down as the project requirements change.

With the advent of Software as a Service, (SaaS), the scalability and flexibility advantages of an external vendor approach have increased in multiples.

Focus on Core Competencies

Engaging with an external software company that is specialised in the software product enables the client to be able to focus on what it does best, i.e., its core competencies. Just as a bank wouldn’t dream of owning forests and paper mills to manufacture its own photocopy paper for internal use within its business, the same applies to software.

No company, no matter how large it is, can afford to be a ‘Jack of all trades, master of none’.

Politics

More often than not the decision to build inhouse is often taken for political reasons, where the main proponents believe that for some reason or other, they can build a better, faster, cheaper software solution than an external vendor.

As mentioned previously, this may be true for some specific cases, where the client has an unique problem or line of business, but for the majority of businesses, especially lenders, the business case does not stack up.

Buying software circumvents political decisions, as the external partner is not part of the internal politics of a client, thus can act as a neutral third party, with the company’s best interests at heart.

Industry Trend

Adaptiveus describes the industry trend, which is certainly showing that the majority of companies now follow the buy path, for the many reasons which have been discussed:

“The software industry has seen a significant shift in the way that companies acquire and use software over the last three decades. In the early days of the industry, most software was custom built for individual organizations. This was a time-consuming and expensive process, but it was the only option available.

As the industry grew and matured, commercial off-the-shelf (COTS) software became more prevalent. This type of software is pre-built and can be purchased by any organization. It is typically less expensive and quicker to implement than custom built solutions.

 

Over the last decade, there has been a trend towards Software as a Service (SaaS). This model delivers software over the internet, on a subscription basis. It is typically even less expensive than COTS solutions and can be up and running quickly with minimal upfront investment. The trend towards SaaS is likely to continue in the coming years, as more companies move away from traditional software purchase models.”

Source

 

Summary

This article has motivated why for the majority of lenders a buy decision is the most logical one. There will always be companies that decide to build inhouse, but this is contrary to the prevailing wisdom and also industry trends.

In conclusion, I am reminded of a famous passage from Hamlet:

“Whether ’tis nobler in the mind to suffer

The slings and arrows of outrageous fortune

Or to take arms against a sea of troubles

And by opposing end them?”

Source: William Shakespeare, Hamlet

Perhaps in the article’s context this passage could be customised to:

Whether ’tis nobler in the mind to suffer

The slings and arrows of outrageous internal IT departments

Or to take arms against a sea of vendors

And by opposing end this dilemma?

 

About the Author

Stephen John Leonard is the founder of ADEPT Decisions and has held a wide range of roles in the banking and risk industry since 1985.