When it comes to IT portfolios, there are myths piled upon myths. One of the most frequent ones I’ve 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 up front: I understand depreciation is an issue. Major software investments are on the books in a fair number of situations I’ve seen 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 of your head right 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? Actually, the error is in not doing something about it, when new circumstances and information present themselves.
Or is it an error when your needs have actually changed? All software, once implemented, locks in a way of working. Change what you need to work effectively, and the software had better keep up or be changed for something that’s a better fit. Otherwise, you’re just crippling operations, and adding cost.
Or how about when a new entrant in the market has brought forth a better way to solve this problem, one with significant value to you? If their product is a far better fit for your enterprise, you should be jumping for joy — and doing what it takes to capture benefits that you, more than your competitors, can take advantage from now.
Give them time to catch up, and they will. There is no permanent advantage from technology, just a steady stream of increments. You have to seize them when they present themselves for your situation — and that will almost never line up with your long-range depreciation plans.
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 if you’re going to deliver value.
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”.
That was the right answer for the business, and talking that language with the Chief Financial Officer soon got the business on side, too. After all, when was the last time paying people was anything other than a cost? If so, why shouldn’t it be as low as possible?
What this (abbreviated) exchange showed them was that “now” (unlike “then”), 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. Talk money to those who are responsible for it. The change isn’t about technology, but about doing the right thing for the business.
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 as much as possible. The past does not control your future.
Put enough value on the table repeatedly, and depreciation won’t get in your way, either.