---

TCO Studies Miss Basic Incompatiblities

By Brandioch Conner

Once again the “Total Cost of Ownership” (TCO) “debate” rages.
The only problem being that no one agrees on the measurements or
even what is to be measured. So why not one more useless
opinion?

First off, TCO is fairly well understood when it is applied to
cars. No, really, this isn’t another car analogy. TCO (sometimes
reffered to as “True Cost of Ownership”) is easy to find for cars
and not many people argue about it. For cars, it includes
everything from the initial price, the repairs over five years, all
the way to how much you can sell it for after those five years. The
good news is that it is easy to measure and compare between the
various makes/models.

The problem with the various “TCO studies” regarding IT systems
out there is that they neglect certain basic facts. The TCO between
two systems is only comparable if:

  • The techs are 100% identical between the companies
    compared.
  • The apps are 100% identical …
  • The users are 100% identical …
  • The local/remote access is 100% identical …
  • You get the idea.

Suppose Company A (100 employees) has 90 of their employees
(each with a laptop) as salespeople on the road (with 10 people and
workstations spread between 3 regional offices), dialing in or
using wireless/hotel DSL and running off-the-shelf contact
management software.

But Company B (100 employees) has 100 of their employees working
at one site, doing data entry on an in-house built database.

Any comparison between the two would be useless. But that’s just
what most of the TCO “studies” seem to aim for. Not only that, but
they miss the really important aspect of this discussion: TCO does
not, by itself, mean anything. It is only useful when you also
consider the “migration costs” and Return on Investment (ROI). So,
here are my definitions for these items.

TCO: Licensing costs and recurring costs such as electricity,
patching, salaries, office rent, annual training, etc. If done
correctly, this should not change from year to year (adjusted for
inflation). I believe that is the most important point. If the
numbers are changing then the calculation is useless.

Migration costs: This is the cost of getting from where you are
right now, to the other system. Migration costs are paid once while
the TCO costs are paid year after year. The licensing costs go
under TCO instead of here because they are part of the system.

ROI: Basically, how much money you make from using the system.
It doesn’t matter if there is a low TCO and low migration cost if
you aren’t making/saving more money with the system than without
it. If you’re arguing over TCO, that means that you’ve already
conceded that both systems make money. All you’re arguing over is
whether one makes money faster than the other.

The important calculation here is: (X years) * (ROI – TCO) =
migration costs.

How soon will the system pay for the migration so you can start
seeing a profit from it? After that, it’s all $(ROI – TCO) as
profit.

Now, the TCO difference would have to be very large before that
equation would start to be persuasive. Saving 10% a year is nice,
but it depends upon how many years you’d have to spend before you
actually saw those savings. So it seems to me that the real issue
would be the migration costs. And high migration costs usually mean
“vendor lock-in.” It isn’t the new system that costs more, it’s
getting rid of the old proprietary system.

Now it’s car analogy time! So, after getting real good ROI and
low TCO on your new car for five years you find that not only can’t
you sell it for any money, but you have to pay thousands of dollars
to have it disposed of as hazardous waste (unless you trade it in
for more of the same from the same compan). Is it still a good
deal? Why do all the TCO “studies” done by “independent analysts”
miss a point that should be obvious to anyone who’s ever owned a
car?

Most of those “independent analysts” prefer to limit their “TCO”
calculations to one specific version (say, Win95 or NT4.0 or
Win2000 or WinXP). I believe that is because that approach allows
them to completely ignore any costs associated with upgrading those
systems (the migration costs) for that system (that’s why
“independent” is in quotes). For example, if you used Win2000 when
it was released and then switched to WinXP when it was released and
still run WinXP today (so you’ve spent 5 years on Windows), you’re
actual expenses will include licenses and upgrade work that they
will never include in their calculations.

Their approach is not so much “TCO” as “Product Cycle Costs”.
You may still be using the workstation and it may still have apps
and data you need, but as far as they are concerned, all those
factors cease to exist.

So, what does all this mean in a real world scenario? Not very
much. Which is why I’m usually dismissive of such “indepentent
studies” comparing their TCO “findings” of different systems.
Comparing two cars is easy, comparing two different IT systems in
two different companies is impossible. In fact, the only item of
any real importance is the fact that your migration costs are not
fixed. Migration costs are driven by the cost of the technology and
the availability of the skilled techs to perform the migration. The
more time you have between starting the migration and finishing it,
the more money you can save. If you’re looking at migrating from a
proprietary system to an Open one, contact the vendor of the new
system and give them the price you want them to hit for the
migration. Then let them work on the technology and skills so they
can hit that mark. A percentage point shaved off of the migration
costs is worth more in the initial calculations than a percentage
point improvement in TCO.

Get the Free Newsletter!

Subscribe to Developer Insider for top news, trends, & analysis