Was Y2K a costly non-event?

Many expected catastrophe. In reality, the industry coped well and is now in good shape for the future, writes Bill Goodwin

Two weeks into the new year, and the millennium bug is beginning to look like one of the greatest non-events in history. After dire predictions of global recession, nuclear meltdowns, and food shortages, 1 January was a serious anti-climax.

The backlash has started. In the US, outraged businesses, convinced that they have spent millions fixing a problem they never had, are threatening to sue the pants off their IT suppliers. Computer experts have received death threats from disappointed fanatics. And university professors are accusing software suppliers of make a fast buck by blowing the problem out of proportion.

The truth is that the millennium bug did strike. The safety systems in 10 nuclear power stations across the world failed simultaneously, electrocardiograph machines stopped working, and the US's crucial defence intelligence satellites were out of action for hours.

In any other week any of these failures would have been big news. They seemed trivial only because people, perhaps unsurprisingly given the hype, were expecting problems of apocalyptic proportions.

The story could have been very different if organisations had not taken Y2K so seriously. Over the past three years the UK has spent an estimated £20bn fixing the bug. By the time 1 January came round most problems had been solved, and IT staff were able to mop up the rest over the long bank holiday. But with so few major bug failures hitting the headlines, commentators are seriously questioning whether the problem was not more hype than substance.

Italy and Russia have been wheeled out as examples of countries that spent far less on Y2K, and yet have emerged unscathed. But claims that the Italian government spent only £1.6m on on the bug are misleading. According to GartnerGroup, £1.6m is simply the running costs of Italy's year 2000 co-ordination office. The figure takes no account of the billions spent by government departments and Italian businesses testing, upgrading and replacing equipment and software. Russia, strapped for cash,has genuinely spent far less than the UK, but its work is far from over.

Businesses and government organisations have moved quickly to find manual workarounds to the problem, or in many cases have simply moved the clock back pre-2000. But the equipment is still not compliant and will eventually have to be replaced.

Margaret Beckett, who headed the Government's Y2K work, said this week, "It is not true that some of international partners 'spent next to nothing'.We know from our many contacts in the International Year 2000 Co-operation Centre that a huge amount of work was done across the world, including Russia, Asia, Latin America and Africa."

The key question is whether Britain's top businesses really have spent hundreds of millions solving a problem which never really existed?

IT directors are adamant that the answer is no. "If we had not addressed the Y2K problem the business would have literally stopped," says Bob Hammersley, senior IT services manager at Sainsbury's. "It is clear that the point of sales terminals and crucial elements of the supply chain would have stopped dead if we had just sat back and ignored the problem."

The problems, though, are not yet over. Experts suggest that only 5% of millennium bug problems will actually take place in the first few days of January. The rest will emerge over the course of the year, as different systems look forward to month-ends, year-ends and critical dates such as 29 February and 1 April. There is a danger that IT staff may be tempted to take their eyes off the problem now that 1 January has passed. Unless they stay vigilant, undiscovered errors could cause businesses serious problems.

Management information systems may be particularly at risk, computerservices company, Cap Gemini warns. The bug may strike when programmes start looking back into 1999 or make date calculations involving the year 2000. If businesses are lucky, the systems will simply fail. If they are unlucky they will provide managers with financial analyses that are dangerously wrong.

For organisations that have addressed Y2K none of this should be a realproblem.IT departments should be able to fix the problems as they happen, without having to hire extra staff, or having their programmers on emergency standby. Of course, if they have ignored Y2K, they may wellfindthemselves swamped with so many problems that their businesses could be placed in real danger.

In theory, Y2K should not have just been a case of spending money to stand still. For many organisations the year 2000 programme could generate some significant spin-offs. The problem has forced many organisations to analyse their IT systems in a systematic way for the first time. They have taken the opportunity to rationalise their hardware and their software. And they have a comprehensive inventory of their equipment, which they can use for future planning.

More importantly, organisations have been forced to learn how to manage large, multi-disciplinary projects. This could prove invaluable as businesses gear up to adapt their IT for electronic commerce, or Britain's entry into the euro.

But it would be very easy to let these lessons slip through the net. As GartnerGroup's Andy Kyte points out, most organisations are not learning organisations; they struggle from one crisis to the next, failing to take the lessons on board.

Unless organisations proactively decide to learn from their experience, then the Y2K critics will, at least partially be proved right - it will be an exercise with very few business benefits. Unfortunately, says Kyte: "We don't see that many organisation making fundamental changes to the management of IT on the basis of lessons learned from Y2K."

Danger dates for 2000

14 January: first semi-monthly payday

31 January: first monthly close, first monthly payday

28 February: to ensure the leap year is being properly accounted for

29 February: to ensure the leap year is being properly accounted for

30 February: to ensure that this date in NOT processed (found in some PC applications)

31 February: to ensure that this date in NOT processed (found in some PC applications)

1 March: to ensure date calculations have taken leap year into account

31 March: first quarterly close

3 April: first business day after quarter ends Friday 31 March

5 April - 6 April: this is the first fiscal roll-over following Y2K (for many including the US government)

14 April: last business day for US 199 tax transactions

15 April: 1999 tax filing deadline for US

17 April: first business day after tax filing date with a two-digit month (10/10/)

31 December: 366th day of the year. This could be a problem for systems that use Short Julian days

1 January 2001: first day of the 21st century

This was last published in January 2000

Read more on IT risk management

Join the conversation

1 comment

Send me notifications when other members comment.

Please create a username to comment.

Yes in a way but it needed to be done. The date issue was something that really needed to be fixed but there was no real urgency for years.This forced us to take advantage of new coding practices. The company I worked for hired our 4 programmers ans "temp consultants" to work off hours to do the changes. We came in ahead of schedule and under budget. All went well and no issues after the new year.

Cancel

-ADS BY GOOGLE

SearchCIO

SearchSecurity

SearchNetworking

SearchDataCenter

SearchDataManagement

Close