When it comes to IT portfolios, there are myths piled upon myths. One of the most frequent ones I come across has to do with the amount of money that’s already been spent on a portion of the portfolio.
“We have to keep this”, I’m told, “because we’ve invested so much in it already”.
Let’s make one thing clear: I understand depreciation is an issue. Major software investments are on the books in a fair number of organizations for upward of ten years: if this is the fourth year after buying into something, you can feel trapped by the size of the write-down that might be required!
So there are times when you have to bite the bullet and live with something, even if it did turn out to be a mistake.
But let’s think about this a little more closely. Suppose it will take you three years to actually make a change.
You needn’t even consider a write-down of the residual depreciation until the last shred of the previous application is gone.
You could accelerate part of the write-down if you have fiscal capacity to do so — or you could burden your budget going forward with residual depreciation and the depreciation for the replacement simultaneously.
In other words, IT Portfolio Management (as with so much else in IT) is really a money game, and one you should become more adept at playing.
But let’s get past the money aspects and see what else underlies this sense that “nothing can be done”. In far too many cases, the real claim is one of fear. “If we change this, someone may come back and ask why we made the original mistake.”
Wipe that thought out now! Is it a mistake to use your judgement and choose a reasonable course of action, only to find out in a few years that the future has unfolded differently? Or that your needs have actually changed? Or that a new entrant in the market has brought forth a better way to solve this problem, one with significant value to you?
I think not: in fact, failing to take action under these circumstances is the mistake, not what you chose to do earlier.
Sometimes it takes a real effort to break through these barriers, for, as we all know, IT can finally come to the new course of action only to find that there is zero appetite for it in the business — in fact, there’s active hostility to making any change here. Some other tactics are in order.
For instance, I saw one situation recently where the sunk costs of modifications to a standard package to support a customized payroll system was in the millions (with millions more required to upgrade to a supported version of the package in terms of retrofitting those modifications to the new version) and where discussing doing away with the modifications (i.e. changing payroll processing) was “off the table” at the demand of the business.
I suggested a successful thought experiment to shake the issue loose. “What does the payroll process actually cost your company?”, I asked.
When told the operational side also ran into the millions per year (for a 4,000 person payroll), I said “then what if the company was told you could spend $300,000 per year to pay people, and no more?” The IT answer was “I guess we’d have to look at a payroll processing contract and make a lot more things standard”.
What this (abbreviated) exchange showed them was that it made very little business sense for their company to be buying payroll packages, modifying them, and operating them internally.
What did make sense was to simplify payroll: most of the difficulties had to do with union contracts, many overlapping classes of managerial and professional workers, etc. More than fifty years’ of complexity had been allowed to build up.
“But they’re going to protect their department,” came an observation. That’s true — so do your homework. Find other organizations like yours who do things the way you’re proposing.
The story ended with an agreement. Payroll would be simplified: no more modifications. This, in turn, opens the door to junking the package, too: it’s been a poor investment and there are other ways to solve this problem, starting with making use of the ERP package they own.
But they wouldn’t go the outsourcing route yet: HR did protect their department. Still, it’s a help — and to keep from being outsourced HR “ate” the residual depreciation, relieving the IT budget.
Stop thinking you’re locked in, and start getting down and dirty with the numbers.
Your job is to continuously have the right set of solutions available. You can only do that by ignoring sunk costs (other than as a depreciation issue).
The past does not control your future.