“There are some kinds of software you just buy: word processors, e-mail clients and anti-virus packages are obvious examples. But when it comes to software that serves more specialised needs in the organisation, like financial systems, many people wonder if it wouldn’t be better to build their own,” says Kevin Phillips, MD of idu Software. At least that way, the argument goes, business will get exactly what it wants.
In reality, there are very, very few circumstances under which it makes sense for companies to build their own software – the costs are invariably higher than expected, and the benefits almost always outweighed by the risks.
There are three main reasons why businesses consider building their own software. First, they may have something that already does almost everything they want, and they believe a few enhancements will take them all the way. Second comes internal politics; and finally, the common belief that their requirements are so unique that no off-the-shelf package can do the job.
Let’s take these reasons one at a time. The first motivation is common, and very powerful, especially for small to medium-sized businesses. Many of these businesses run quite comfortably for years on heavily customised versions of popular packages. Yes, even an incredibly complicated Excel spreadsheet.
That spreadsheet has typically taken years to build and tweak to suit just about every situation the company has ever faced. But inevitably there comes a time when they just need more, or need to do things more efficiently – and then the temptation to build on what they already have is very strong indeed.
The temptation is often strengthened by internal politics and sentiment – people who have invested years in tweaking a spreadsheet will almost always support a self-build option. It can be very hard to believe that any off-the-shelf package can replicate what they have built, and none will ever be good enough.
Which brings users to the third reason: the belief that their requirements are so unique they can only be met by developing their own systems. Linked to this is often a reluctance to change business processes just to suit the requirements of a software package.
Actually, this is a very bad reason to build their own software. Most companies vastly over-estimate the uniqueness of their specific financial requirements. And unless their existing processes are 100% efficient, change may prove to be for the better.
This can be very hard to accept, but it’s true: the way things have always been done is not necessarily the best way to do them. In most businesses, processes and systems evolve in fits and starts over time, changing reactively when they face particular problems.
As exceptions and special cases accumulate, so do the extra actions and processes needed to cope with them. The end result is often complex and rarely elegant or efficient.
In a case like this, writing bespoke software to suit existing processes will simply entrench inefficiencies. Users miss out on the opportunity to adopt some best practices, which are often built in to packaged systems based on extensive experience across many countries and industries.
Worse, the chances are high that self-built software won’t even meet all the needs, since those change all the time. By contrast, packaged systems tend to be incredibly rich in functionality to accommodate the many diverse requirements of the many users of the application that motivated for its creation in the first place.
If businesses discover a new need in their solution, the chances are it’s already catered for in the packaged solution, and better still they will be faced with functionality that they never had access to before; and therein lies an opportunity to revisit current processes and functionality in light of the opportunities presented.
Packaged systems almost always provide 95% of the functionality that any business needs. If there are 5% of the needs that aren’t met, far better to write just that extra 5% than the other 95%. Then there all the other advantages: upgrades to new operating systems, reliable support, and regular updates and enhancements.
What do users get if they build their own? They may get exactly what they want – although that’s not guaranteed. They will also, very often, be exposed to some nasty risks as well. The most common – and it IS common – is becoming dependent on a single supplier or even worse, a single individual.
Phillips has seen many cases of companies operating on legacy systems that can only be maintained, at horrendous consultancy rates, by someone who used to work for them.
With custom-developed software, there’s also a huge risk of obsolescence: there’s rarely a clear upgrade path built in. At some point, users will either have to abandon it, commission an expensive rewrite or find themselves stuck using a 15-year-old operating system because an upgrade will kill custom software.
There will always be exceptions, of course: for some people, some of the time, custom software is the way to go. But it’s a lot rarer than many people think. Before taking on the risks of a custom build, a company should take a very hard, unsentimental look at which of its needs really are unique. Almost always the answer is: not nearly as many as people think.