The TCO/ROI Scoping SweetSpot

If your IT costs are rising constantly on a wave of apparently critical legacy systems that you don’t know how to get rid of and nobody knows how to support, chances are you are missing the TCO/ROI sweetspot when scoping your business cases and projects.

Estimating how many users, servers, licenses, and features you need for the new shiny system you want to implement is relatively easy: just list all the things you need to get that up and running and stop there – but give me a few beers and I can rant for hours on why that is so horribly-not-at-all-and-under-any-circumstances true.

Just looking at your project may tell you something about what it will cost to get your system to work, but that is like figuring out what it costs to build a house without taking down the old one or moving the furniture. To make a proper business case, you need to look at the BIG picture and answer some of the hard questions like:

• What can you retire when the new system is up?
• How many years before the next major upgrade is due?
• Is it realistic to expect everyone to be expert users from day one? Day 500?
• Are you sure you have EVERYTHING in the project that’s needed to realize all the benefits you listed in your business case?

So to get a proper evaluation, you need to scope at least two aspects of your calculation and your project very carefully:

Systems

If you look at too few systems, it is easy to overlook dependencies and feature overlaps. You can make everything dandy within the project, but once you’re live all your benefits get hollowed out by a flotilla of annoying factors like:

• Users having to use the old systems for single tasks so you can’t retire them
• Data retention legislation so you can’t get rid of servers
• Legacy license agreements that means you have to pay for the same feature twice even though you don’t use it anymore, and so on.

On the other hand, if you look at too many systems – as you’ll sometimes see when overzealous guys in my position want to get ALL it costs for all systems on day one – you’ll just drown in data, and you wont be able to deliver any meaningful answer to anything.

In my experience, your best bet here is to cluster systems into domains like HR, Finance, Productivity, and so on, with as clear a boundary as you can manage, so you have a fairly good overview without being hampered down by too much detail.

This is not easily done – and particularly not within a single project where most of the stakeholders on projects have vested interest in the outcome – so you’ll probably need some permanent non-project roles to define the domains and take the long-term TCO responsibility for this to work properly.

Timeline

The main thing to remember here, is that you can’t disconnect the project timeline from the TCO timeline: If you listed a benefit in your business case, it has to be realized before you end your TCO timeline.

Getting that timeline just right though can be a bit of a problem. Andy Kyte mentions nine years as the average time to fully replace a core IT system, and that’s probably spot on in most cases, but I usually take a less scientific approach and look at the software lifecycle of the product instead.

If you implement an IT system, chances are it will need a major overhaul in 4-5 years, and you want at least one or two of those overhauls to make sure you have a good idea about what’s going to happen. On the other hand, if you look much beyond that, the risk of the software being completely replaced by something else becomes so high that it undermines the validity of the TCO.

In my experience, the scoping sweetspot for the TCO timeline is somewhere between 5-10 years depending on the system you are looking at.

Summary

Working with TCO and ROI is not an easy task. As I’ve mentioned before it’s sometimes more art than science, and it can be tempting to give it up altogether and just look at each project individually, because after all, if we get the project approved, who cares about all the old stuff or the future. That will just take care of itself wont it?

Wrong. Of course. If you’re serious about making IT that is a competitive advantage for your business, you need to be not only good at scoping, you need to be better at it than everybody else, because in the end correctly scoping changes is what differentiates the good projects from the bad and the winning business from the ones muddling along.

Read More:

• Gartner – Andy Kyte (Gartner membership required to read articles)
• ITNews – Oprhaned apps are “draining” IT budgets