Desert-island castaways could perhaps be excused for never having heard of the millennium bug, but coverage has reached such a level that for anyone else, there is no excuse.
Even if they have only vaguely heard the phrase, and know it has something to do with computers and 2000, everyone should by now have some level of awareness.
But just being aware of the problem is not enough for engineering companies. By this stage they should be well on the way to ensuring that their own systems will not come to a grinding halt, or even spin off into unpredictable behaviour.
There are a number of issues that companies need to be looking at, to make sure that when the new millenium comes, work will be able to continue without a hitch as far as possible.
When the issue was first recognised, many companies assumed that it would just be an IT problem, but as they have investigated the implications, it has become clear that it impacts on almost all aspects of the business. So what is the most effective course of action to follow?
Companies should be checking their own internal systems, and also investigating the extent of their liability for embedded systems that they may have supplied to clients (NCE 2 October 1997). Problems with computer systems could arise when the date changes to 2000 any date-dependent system which stores just the last two digits of the year could crash or shut itself down if it cannot work out what the date is.
It is vital to start with a complete inventory of the hardware, software and operating systems used within the company, stresses Maunsell IT director Roger Wright, who is Y2K project manager for the consultants internal systems.
If you dont know what you have got, how can you carry out an audit? he says. At Maunsell, all IT systems are bought, installed and supported by his department, and software is distributed from a single server at the head office, so this has been a relatively straightforward process. The problem will come in companies which do not keep this level of control over IT, he claims, and where staff may be loading non-compliant software, or each department buying in its own equipment.
Although we think that the problems will be minor, we are not treating it as such, he says. The generally accepted view among IT experts is that the biggest problems will come with so-called legacy systems software which relies on the COBOL programming language, has generally been created for a specific company, and built up over a long period of time. Because computers arrived relatively late into the civil engineering world, this is not likely to be a big issue.
And Wright says that, depending on the type of system being used, the turn of the millennium could be completely irrelevant. Some systems store dates as a certain number of days since a particular date in this case the flashpoint would be when that number reached 9999.
Maunsell has divided its Y2K project into four sections, investigating its technical software, information systems, hardware and operating systems. We have a lot of technical software that has been developed in-house for our own use, he explains. We started making changes to it last year. The company is creating a certificate of compliance for its own software, and is also asking suppliers to produce compliance statements for their products.
Wright is doing everything with reference to the British Computer Society, he says; procedures are taken from the organisations two volume publication Year 2000 practical guide for professionals and business managers which is endorsed by the Engineering Council.
By the end of November this year he hopes to have all the work completed including a live test on a Saturday over part of the network, which will theoretically show up anything that has been missed. If Maunsell can meet this deadline, he says, then by the end of the millennium the computers will already have been through one year change, which should have picked up any glaring problems introduced by the upgrades.
At Ove Arup, Y2K programme manager Simon Fermor confirms that the company has no legacy systems, and says he is not expecting significant problems with in-house systems. The engineering programmes are not date dependent, and the main concerns are fairly trivial such as whether the right date will be printed out on to reports.
Almost a year ago the company started to build up an inventory. We already had an inventory but it was not designed so that we could extract this kind of information, he says. The new listing highlights the most critical items so that they can be prioritised. Advice is also being given to overseas offices about which items need attention.
Contractors have been warned that they could face claims running into millions of pounds on embedded systems that they have supplied on past contracts. At Laing this issue is being addressed as part of the company- wide strategy aimed at dealing with Y2K, which first got off the ground two years ago.
Laing is also following the recommended procedure for reaching compliance creating an inventory, assigning priorities and then setting up a network of managers across the business with responsibility for implementing the changes. Making sure that subsequent activity does not undo work already carried out is an important factor of the programme, as is raising awareness among staff to stress the importance of the procedure.
The contractor does not have a major amount of customised software, something of an advantage in terms of achieving software compliance. In common with other businesses, Laing recognises the need to have its business- critical items complying by the end of this year, to iron out problems before the final countdown.