Total Cost of Ownership

I’ve recently been consulting on a large web based research project. Whilst I can’t go into too much detail about who my client was, I can say that it was one of the most varied consultations I’ve undertaken for a while. Looking back on my experience got me thinking about the long term Total Cost of Ownership (or TCO for short) of systems.

The first issue I had to settle was that although the system had been successfully migrated from one Internet Service Provider to another, and to all intents and purposes should have been working, a vital part of the system was unavailable. It had just ‘stopped working’. Fortunately, I’d seen this type of problem before and even though I’d never had direct experience of the web-based software that was being used for the project – a well respected third-party piece of software – after a chat, a cup of coffee, and a quick look at the system, it was quickly apparent to me what the problem was.

The sense of relief at solving just this one problem was palpable. It literally meant the difference between success or failure of a large project already under huge time pressure. And yet it was such a small change required, that – as a web nerd – I had seen before, but which, in an ideal world, my client could have been trained to be aware of.

And that brings me to my first point. The cost of a system is more than just the cost to buy it or build it. Ideally you need to factor in training time for any new system. Few people do this, and if I’m honest I’ll include myself in that number when I look at new software myself. Because my client clearly hadn’t been trained to use the software they had purchased, they were the at mercy of a supplier who not only charged way above what I consider the market rates to be, but who was, by all accounts, difficult to get hold of in any case.

The old adage of teaching a man to fish came to mind. My client had the fishing rod, but they didn’t know how to fish and the fisherman was off fishing for someone else. I hope I did my bit in teaching my client to ‘fish’, so to speak.

Then came data security. My client needed to securely move data from within a live database on the web to somewhere completely off that particular server. The final solution agreed upon was an elegant combination of different techniques, but during the course of my consultation, it became apparent that had a little more thought been given at the time of design of the system as a whole, data security could have been vastly higher for a nominally higher investment in database technology.

Sometimes, saving money in the upfront investment stage could well cost you later on in terms of the risks introduced into the project, not necessarily just in terms of data security.

A more expensive system may be quicker and easier to install, it may offer better features such as reporting functions or easier maintenance than other alternatives, or have a better record of reliability, or be more compatible with your existing systems. In all cases it really is worth investing the time to research what’s available on the market rather than plumping for the perceived or de-facto standard software for what you want.

There were other minor issues that I helped to fix, some of which were related to the migration between Internet Service Providers, and simple things like adding a few new web pages and updating the text on existing pages. Again, I tried to teach my client to fish as they were capable of doing these things, but in the past, the ability to do so had been obfuscated from their view. That during my time consulting with them they became aware of how to do things and where to do them will stand them in good stead going forward.

TCO is a bigger issue that I’ve gone into above, but the general gist is that it is important take care to consider the implications of your system beyond the initial investment.