Beware the Not-Invented-Here Syndrome
For those of you who know Australia – and Melbourne in particular – the prospect of police having to guard the entrances to the city’s famous Flinders Street train station would no doubt be hard to comprehend.
But that’s exactly what the authorities were considering a few months ago when I happened to be there for the Easter break.
Even more astonishing was the cause. You see this was nothing to do with terrorists, or a footy match between two fierce rivals; it was actually all down to software!
The problem was the new rail ticketing system – Myki – which by all accounts has been a disaster, causing massive delays and violence to erupt amongst the otherwise placid Melbournites. No wonder some were suggesting the system be renamed Myki Mouse!
Worryingly, a potentially bigger issue was also lurking - the threat of people getting crushed during peak times because of massive overcrowding. That’s just plain scary and from a health & safety point-of-view just about as bad as it gets.
But what really got my attention about this story was the fact that most of the problems with Myki were in fact software-related.
The question everyone wanted answering was why Melbourne were having such problems when both Brisbane and Perth had just been through similar upgrades without any issues.
The main difference seemed to be that whilst Brisbane and Perth had both purchased commercial ‘off-the-shelf’ software, Melbourne had decided to develop its own system.
Honestly I’ve lost count how many times I’ve heard of this exact same decision backfiring over the years – a few hundred would not be an exaggeration.
Welcome to the Not-Invented-Here Syndrome – or NIHS for short.
NIHS takes little explanation, simply meaning: if I didn’t invent it, it’s not going to be any good and I’ll be able to do a better job myself.
The opposite of Not-Invented-Here by the way is Proudly-Found-Elsewhere, which we will come to later…
Unfortunately, when NIHS strikes in the IT industry, the consequences are often horrible. Perhaps not as bad as the threat of violence and public harm but horrible and costly all the same.
Now I don’t know why Melbourne decided to develop its own system but usually with these things it’s down to a few individuals infected with NIHS who convince themselves that they can actually build something cheaper than the cost of buying in a commercial off-the-shelf alternative.
But as has been proven many times over, it’s an incredibly naïve assumption and once things start to go wrong, it’s usually too late to rethink the decision.
The organisation is now stuck between a rock and a hard place. Do they carry on and see things through even though it’s going to cost them an arm and a leg, or do they write-off the whole thing (including the book value of the so-called ‘asset’) and start again? Typically the decision is taken to continue even though the overall cost is now forecasted to be well in excess of the off-the-shelf alternative (not to mention the fact that it might never actually work properly).
The end result is a poor-performing solution that has cost way more than it needed to.
I guess it’s no surprise then that more IT departments are finally realising that NIHS is not only bad for business but can also be really bad for their individual careers. However, we still have a long way to go – especially in the compliance sector.
NIHS in Compliance
Now I’m actually quite a fan of Microsoft (for example, I happily use their Office applications) but the most common example of NIHS in compliance is Microsoft Sharepoint – or should I say the people who use Sharepoint as the starting point for their in-house compliance systems.
Of course this isn’t Microsoft’s fault. Technically I’m sure Sharepoint is brilliant but that doesn’t mean to say it’s a good answer for compliance management.
What I see time and again is that the development cost of Sharepoint is horrendously expensive and requires very specialist software knowledge to both develop and maintain. The end result is that the Sharepoint-built solution becomes bloated, difficult to use and has cost the company way more than an off-the-shelf equivalent solution.
Now of course my view of the world is heavily influenced by my passion for Mango and belief that commercial cloud applications are best. As a result I feel obliged to offer a more objective analysis of the situation so here goes…
The Economics of In-House Software vs. Off-the-Shelf Software
Let’s take a typical (albeit fictitious) cloud software company called Cloud Inc.
Cloud Inc. had been around for a good few years putting a lot of effort into developing, testing and refining their product. But it’s not been cheap - so far they’ve spent $2m on software development alone.
But for an organisation wanting to use Cloud Inc.’s tried and tested software it’s only going to cost them $5,000 per year.
What’s interesting is when you compare this amount to the total cost of Cloud Inc’s development, which, as a percentage is 0.25%. This means an organisation will only pay 1/400th of the overall development costs incurred by Cloud Inc. to use their software for a whole year.
But wait – there’s more.
You see Cloud Inc. doesn’t stop developing the product and ensuring that it keeps pace with changes in technology, legislation and the industry in general. They’ll probably spend a minimum of $1m in development costs each year.
So if we look 5 years out we’d see that Cloud Inc. has spent $7m in total development costs but only charged the client $25,000 to use it (i.e. 0.35% of the cost of the development over a 5-year period).
And that, my friends, is why so many organisations love cloud-based commercial applications like Cloud Inc.’s – because you get the benefit of millions of dollars of expert development effort for a fraction of the cost. Further, there’s no risk – you know exactly what it’s going to cost you and if you no longer need it, you simply stop paying and move on.
And so we have the opposite of NIHS - Proudly Found Elsewhere – where an organisation is actually proud to be associated with an off-the-shelf product like Cloud Inc.’s because it does a damn good job for a small outlay – plus they get terrific support and on-going development from the provider.
Of course that’s where the story should end but sadly not – all because of a guy called Wally.
Wally is an in-house software developer looking for his next project. He also suffers from NIHS so it’s no problem for him to rubbish Cloud Inc.’s product and decide that something better can be created in-house using Sharepoint as the platform.
But Wally knows how much the Cloud Inc. solution costs and so remarkably comes up with a plan to develop their new Sharepoint-based system for a shade under $5,000. What’s not to like, right?
Well nothing - apart from the fact that Wally is clearly delusional.
Think about it for a minute ... it took the experts at Cloud Inc. $2m but Wally thinks he can create something similar for less than 1/400th of the cost. Seriously, how is that possible?
Unfortunately, the answer is that it’s not! Wally by name, wally by nature.
Wally, you are not a well man and you need treatment right way. Enough said.
Off-the-shelf software has usually been proven over many years of development, testing and customer use. Great care must be taken when deciding to do it yourself – the numbers simply don’t stack up.