Software: Build or Buy?
A conventional wisdom in IT is 'everybody knows you don't build software any more'. But some conventional wisdoms are actually wrong. We would like to put this one to the test. To do so we will consider the advantages and disadvantages of custom and packaged software in relation to the key decision points.
Differentiate or standardise
This is a crucial factor – whether the objective of the project is to differentiate or standardise the aspect of the organisation which is under review.
If you are launching a new product or service you are presumably striving for something unique. To gain a competitive advantage, the core business process needs to be different and the organisation requires freedom to engage in continuing business improvement, and to embark on major and rapid change.
Accordingly, software used in the core business area needs to be controlled by the organisation and sustain the differences in the business. Using a package as the support system is by definition standard, duplicable and outside the control of the organisation. Packages therefore present some risks where a project takes on a strategic significance.
On the other hand, if you are looking to improve a non-core function, such as inventory management, or possibly agenda management, you may want to standardise. As long as a suitable package exists, there is little to be gained by embarking on a software development. It may even be advisable to adapt work practises if necessary. The economy of scale offered by packages can drive standard costs down.
The cost of developing custom software is made up almost entirely of time costs. The following chart shows the costs involved.
In a package implementation the following time costs are involved.
Time savings in package implementations stem from the fact that less development is involved and testing is less onerous as a consequence. As a rule of thumb development projects require almost twice as many hours as package implementations.
Offsetting this are the licence fees charged by package vendors (custom software is free of royalties). The number of users to be licensed is likely to determine which option is more economical – the less users, the more likely it is that packaged software will be more economical.
If you have chosen a package which requires no alteration, the lead-time for implementing a package is about half that of developing a system. This is a simple reflection of the fact that half the number of hours is involved.
The gap closes the more package alterations are required.
|Nature of risk||How to solve with custom software||How to solve with package|
|Cost overruns and delays||Tight specifications and tight contracts||Tight specifications and tight contracts|
|Bugs||Formal acceptance criteria and warranty provisions||Choose a popular package|
|Software does not comply||Tight specifications and tight contracts||Tight specifications and tight contracts|
|Support||Create technical documentation for others to follow and use a popular platform||Choose a popular package and a reputable dealer|
|Availability||In principle this problem does not apply to custom software as long as there are developers to be found||If the packages do not closely match your requirements you're going to have to build something|
The decision between custom and packaged software is not always clear-cut. Packages address standard functions such as document management, accounting, distribution, inventory and HR. Custom software comes to the fore when you are looking for a strategic gain or operate in a manner which is not catered for by the packages. As usual, it's horses for courses.