Apocalypse When

Apocalypse When?

Martyn Thomas

Chairman Emeritus, Praxis Critical Systems
Former Global Director, Year 2000 Services
Deloitte and Touche Consulting Group

Year 2000, a Board level view

Most directors and managers have heard about the "millennium time-bomb". Eighty percent of them understand that it is a problem for older data-processing systems that could cause failures at the end of the century when the two-digit year moves from 99 to 00. Eighty percent of them are wrong. Year 2000 problems span the entire business, from the factory floor to the executive washroom and from the supply chain to product liability. For most companies, resolving their year 2000 issues will either be the largest project they have ever undertaken, or the last.

It is true that year 2000 affects data processing systems, many of which will be older mainframe systems, but this is only the start of the problem. Newer client-server systems are likely to fail. Spreadsheets are likely to fail. Desktop systems of all sorts will need to be checked if they are important to the business and if they are sensitive, in any way at all, to the current date.

In thirty years, microprocessors have penetrated most areas of business life. There are stock control systems (some hand-held, with bar-code readers), automated assembly lines, lift controllers, time-locks, alarms, instruments, credit card readers and security systems. All these and more need to be checked. There is embedded logic in many products, which needs to be checked too.

The finance director will be appalled - these problems are too serious to ignore, but the costs could be enormous and the value to the business seems zero. A UK Government questionnaire asks if companies have set aside 20% of their IT budgets for the next three years to tackle year 2000 issues, yet this will be far too little to cover the costs that many companies will face, and the only benefit is that they will be able to carry on operating as normal into the next century. It is little wonder that so many companies have failed to face the reality yet: in a recent UK survey, only 10% had actually started remedial work.

Year 2000 affects the whole business, the deadline is immovable, and resources are limited in every company. Inevitably, important business investments will have to be delayed or abandoned if the year 2000 project is to be given the resources it needs. In most companies, only the executive committee or the Board can take such decisions. Auditors are already commenting on year 2000 readiness in their reports to audit committees. Soon they will have to start qualifying companies’ accounts. Year 2000 is not an issue that can safely be left to the IT department.

Year 2000 failures are already occurring. Marks and Spencer had problems when a consignment of corned beef arrived that had a shelf life that went beyond 2000 (because a product that expires in, say "02" seems well out of date when the current year is "97"). A pharmaceutical company that packs medicines for dispatch in order of sell-by date found that all "2000" products were dispatched ahead of all "1999" (because "00" is less than "99"). Sites with 999-day expiry dates on backup tapes or other experienced failures on April 7^th this year. Critical hospital equipment and automated assembly lines have failed when tested with next-century dates. Some time locks are known to fail, and to leave bank vaults locked for up to 80 years. The rate of failures will increase as time passes until, on widely quoted Gartner estimates, 80% of date-sensitive systems fail by 1999.

Some failures may be happening unnoticed, because the particular fault is causing incorrect data to be stored silently, creating problems that will come to light later. Programs that use "99" in the date field as an end-of-list marker are a good example of this class of fault; the first genuine 1999 year will stop the processing and all subsequent records will be ignored. This may not be obvious at first, and may trigger other incorrect processing - for example, if goods inwards records are ignored, components may be reordered from suppliers unnecessarily.

Time is short and it may already be too late to implement the best solutions. Even in the simple cases - for example, an accounts system with no look-ahead which has a fail-by date of January 2000 - a prudent company will want to avoid processing a century-end with modified software that has never successfully processed a normal year end. That decision means that the software must be working by January 1999. If the company wants to process a quarter end before risking a year end, the date moves back to October 1998. A typical project needs 50% of the elapsed time for testing, so the new system needs to be ready for testing around Christmas 1997! The work will need extra resources, too: staff with appropriate skills and extra hardware for the development, testing and parallel running (potentially of all the company’s critical systems simultaneously). The cost of these resources is going up; reports from America suggest that contract rates for COBOL programmers have doubled in the past four months. Just when more staff are needed, the permanent team may be tempted to leave.

The view from the boardroom is gloomy: the problem is larger than it seems, very expensive, urgent and, worst of all for the Board, raises issues of liability to shareholders, customers and suppliers if anything goes wrong.

Year 2000, a consultant's view

From the consultant's viewpoint, year 2000 is a combination of a dozen services that are familiar to most consultancies, combined with an unusually large scale, immovable deadlines, and the need for some staff with solid year 2000 expertise - especially in the early phases of the project. A typical year 2000 project will involve surveys and interviews, planning and reporting, package evaluation, supply chain evaluation, forecasting, contract reviews, procurement, change management, disaster recovery planning, large-scale project and programme management, risk management, outsourcing management, systems development, quality management, test planning and management and much more. The list reads like a catalogue of the service lines of any major consultancy.

The biggest challenge is created by the magnitude of the work and the fixed timescales. Carrying out a year 2000 programme for a major multinational needs the skills of a top army staff officer. It feels just like planning a major military campaign.

Planning is key. You will need an inventory of all the year 2000 related issues faced by the business, including its information systems, infrastructure, embedded systems, plant control, environmental systems, products, and external dependencies on suppliers, customers and partners. No company has a reliable inventory; what exists needs to be checked and supplemented. Then a strategy and plan need to be created for each issue. Will this component be replaced, modified, retired or outsourced? What are the cost, timescale and priority? What is the recovery strategy if the ideal solution cannot be achieved? Getting this far will take several weeks, with a substantial team that includes year 2000 experts, industry experts, and specialists in the system technologies.

Then the budgets have to be committed, and the detailed planning needs to be completed and executed. Substantial problems can be expected: few companies can reliably locate the full and guaranteed source code for all their critical systems, and many systems will have been purchased, perhaps from vendors who are no longer supporting that version. Depending on the technical strategies adopted, it may be necessary to modify existing data to work with the modified systems, and to change the sizes of fields on data screens, retrain staff, and of course, test, test, test!

Most consultancies will have a year 2000 methodology, developed in-house or adopted from a supplier, so there is no need to go into more detail here except to emphasise, one more time, that year 2000 is a far wider problem than data processing and that many of the other systems need the skills of electronic engineers, safety engineers, and control systems specialists. Partnerships and teamwork are important.

Finally, be sure to take your own medicine! Are you year 2000 compliant yourself? Have you ever delivered a system that is not compliant, or recommended a package that will fail between now and the end of the century? Are you taking reasonable steps to protect yourselves and your clients? Are you sure?

Contact details: Martyn Thomas: mct@hollylaw.demon.co.uk.