To print: Click here or Select File and then Print from your browser's menu

This story was printed from silicon.com, located at http://www.silicon.com/

Story URL: http://comment.silicon.com/0,39024711,11016096,00.htm

The Value Proposition: the Y2K ransom theory
Paul Strassmann, leading technology guru and Butler Group associate, has not been congratulating US companies on a job well done. In fact his comments on the Y2K spending have been a little unsettling. In this, the second of a monthly series of articles, Jonathan Stephenson, Butler's UK IP explains why

By Jonathan Stephenson

Published: Wednesday 01 March 2000

If we consider for a moment the modus operandi of a kidnapper, it is one of extracting the maximum ransom from the victim's next of kin, based on the perceived worth of the victim's family. A corporate ransom would be based not on the complexity of the IT infrastructure but the net profits of the company.

Strassmann's detailed analysis of 55 leading US companies has so far revealed a better correlation between corporate profit and Y2K spend than any of the more logical correlations such as IT budget, cost of information management, turnover or industry group. This rather worrying fact suggests that Y2K budgets were based on the amount of cash available and not the size of the task - that is, the ransom model.

Strassmann's analysis is based on figures for the US and you will have to make your own judgement as to whether European's reacted in a similar way. In the US, companies filed their Y2K budgets with the Security and Exchange Commission and so better statistics are available than in the rest of the world. The total Y2K budget for corporate America was equivalent to half annual profits - over $300bn.

Clearly the reaction of the frightened victim is to throw all available cash at the problem. It does not sound like the outcome of a careful risk assessment followed by a targeted programme of remedial work. I am not suggesting that there was a carefully planned plot to extract and spend funds, but we could surmise one of the following processes at work:

1. The old systems are so old let's take this opportunity to renew our IT infrastructure and get some nice new systems in for the millenium.

2. Watch your back, hang the expense, let's throw everything we have at the problem, because if we don't and it goes wrong our heads will be on the block.

Strassmann compares the Y2K problem to an insurable risk. By spreading risks over large numbers of businesses we cut the costs of a number of rare but potentially expensive disasters. He suggests that the insurance industry has let us down over the Y2K problem by not providing a mechanism to spread the Y2K risk. While no-one is suggesting that a one-off premium would have been the right answer to fixing up a potentially flaky bit of Cobol, there are lessons to be learned from the comparison.

A more balanced approach to the Y2K risk would be to assess the impact that a bug could have on the company and then take action commensurate with the risk. A major insurance underwriter I contracted for many years ago, rang me last year and insured their system (that I was the last to work on) against Y2K failure by paying me a very reasonable (read 'low') rate to be 'on call' for three days in January. They were prepared to take a risk that the system would fail provided they had the insurance in the form of my agreement to drop everything and fix any bugs that may arise. At the level of the business unit that relies on that application someone had assessed the risk and avoided the potentially expensive exercise of having me check, test and certify the code. As it happens they took an extra backup just in case, ran the date sensitive premium calculations and the application was fine. If it had failed the debug costs would have been equal to two man-days work. Now, had that been a real-time air-traffic control system the risks would have been of another order of magnitude.

I think if we have learned any lessons at all from the Y2K bug it is that software has a long life and should be managed much more as a corporate asset than we have traditionally. The mainframe systems that were the focus of the Y2K programme are now more valuable as century compliant systems and companies will be reluctant to write them off. It is interesting to compare Strassmann's concept of Knowledge Capital, which includes all value-generating assets such as ideas, software, trained people and customer loyalty, with tradition accounting practice which values only fixed assets. On the end of year report you are much more likely to see a balance sheet entry for a couple of fork-lift trucks that have been written off than an entry for the loss of a highly trained IS team leader, or a software system.

Lending banks have largely shaped the way we value companies and this has involved counting only the dead things.

** If you would like to know more about Butler Group's Strassmann assessment services, please visit the www.ButlerGroup.com Web site or e-mail Jonathan.Stephenson@ButlerGroup.com.