Make your own free website on
Recommended Resources Offshore havens, asset protection, global investing and other useful techniques.
The Year 2000 Bookshelf Books to help your evaluate the Y2K problems you face.

Gary North's Y2K Links and Forums - Mirror

Summary and Comments

(feel free to mail this page)




1997-11-18 07:45:36


Procrastination: Then and Now



The problem with virtually all of the "let's get started now" reports is that the same message was being published in 1996 and 1995. Back then, we were told that industry absolutely had to get started right then or else a disaster would overtake the economy. There was no time to waste. Today, we read the same dire warning. This means that either (1) the previous warning was overblown, or (2) this one is too late and is there only for cosmetic purposes, since no magazine will publish "too late" stories; it's bad for advertising revenue. The reader prefers the first option: "If the previous warning was overblown, this one may be, too. Let's wait and see." This leads to more procrastination.

William Ulrich and Ian Hayes have written a book on y2k. In SOFTWARE (Oct. 1997), they sound the same alarm, but add that if everyone gets started Real Soon Now, "we" may make it. Then they add that the rest of the world is way behind the US. If the foreigners don't get y2k fixed, we will go down with them. Nevertheless, if "we" get started now. . . .

My view: It's too late by a decade. But respectable authors simply will not admit this in print. When will they finally admit that we're beyond the point of no return? December 31, 1999?

* * * * * * *

Imagine it's October 1985 and that the IT and business communities have fully grasped the implications of the Year 2000 problem. We have more than 5,052 days to fix the problem. We set standards to ensure that all new systems being built are compliant. IT has time to convert or replace existing systems. We would not even consider windowing, time-boxing, or other Year 2000 shortcuts. Hardware and software requests for new PC, telephony, manufacturing, and other embedded systems all specify compliance requirements and limit future liability to old equipment. Every company easily reaches compliance, so there will be no issues related to supply-chain breakdown, negative customer impacts, or infrastructure collapse. The annual cost of the century date-change upgrade effort is negligible and the problem never graces the cover of Newsweek.

Instead, it is October 1997, and our procrastination has allowed the Year 2000 issue to reach crisis proportions. To quote the SEC task force on the Year 2000, ". . . it is not possible for any entity or collective enterprise to represent that it has achieved complete Year 2000 compliance. The problem is too complex for such a claim to have legitimacy . . ." As of October 1, there were 822 days until January 1, 2000. Companies planning to devote 1999 to testing had 456 days to complete software corrections. Incredibly, many organizations still have not launched full-scale remediation efforts. Shortcuts are commonplace. . . .

Because this problem affects virtually every computer system, the Year 2000 is truly a global issue. Yet, the rest of the world lags the U.S. in awareness and action by six months to a year or more. Skepticism about the reality of the problem is common in the U.K., while concern over the European Monetary Union (EMU) is slowing European response to the problem. Asia and Latin America are even further behind. The bad news is that Year 2000 failures in the rest of the world will impact U.S. corporations. The bright spot is that other countries can learn from our mistakes, which should accelerate awareness.

Why are organizations waiting so long to ramp up Year 2000 projects? Perhaps it's because management considers the solution to be so simple -- until they learn the true nature of the problem. Whatever the reason, organizations must quickly scale up to the point where they can deliver the minimum number of projects needed per quarter to ensure that mission-critical functions remain viable.

Procrastination, whether inadvertent or by design, is preventing organizations from launching more than one or two projects at a time. By the time companies reach full-scale deployment, it may be too late to stabilize mission-critical systems. The reasons behind this delay include analysis paralysis, politics, the fear of mistakes, confusion, lack of budget appropriation, or just ignorance of the effects of the problem. Whatever the reason, delay is no longer acceptable or justifiable to stockholders, constituents, or business partners.


Return to Category: Too_Late

Return to Main Categories

Return to Home Page