Software: Build or Buy?
Introduction
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 the single most important 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, 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.
Cost
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 more users, the more likely it is that
custom software will be more economical.
Lead time
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.
Risk
|
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
|
Summary
The decision between custom and packaged software is not clear-cut. Packages address
standard functions such as accounting, distribution, inventory and HR. However,
at the heart of every single business is something that makes it unique –
its value proposition. To capitalise on this may call for a more strategic approach
than selecting the same package as everyone else.
|