History will tell you that Y2K didn’t cause any of the expected catastrophes. True, the major disaster scenarios envisioned did not take place, but only because a lot of work was done to mitigate the predicted problems, and the damage that did occur was kept mostly out of public view.
The company where I worked in the 1990s was affected by Y2K, though not in the manner we first expected.
At this company, we nurtured a cash cow that I'll dub "The Program." Our main source of profitability came from providing IT services based on a decades-old server system with ancient contracts that, for one reason or another, neither we nor the customers had bothered to update. It had hummed along with surprisingly few problems, especially considering that no upgrades or maintenance were conducted on the machines and programs. Staff explained—only half in jest—that those who knew the whereabouts of entry keys or the actual location of the servers had long retired.
But good organization was not a strong suit at this company. Financial targets received great attention, while anything beyond that fell out of view and concern. For example, the office storage areas were packed with outdated company stationery, brochures nobody used anymore, and computers that were slowly becoming obsolete. Lifecycle management had been invented some years prior, but it wasn’t applied to The Program at all.
The future looms
A few years before the dreaded 2000, every employee received an email: To prepare for Y2K, a “time machine” test lab had been set up. All services provided by the company had to undergo a resilience test. Applications were to be installed on test machines that had their clocks moved forward to Dec. 31, 1999. The applications would then be monitored while the test machines’ clocks would tick over into the year 2000. The applications would thus be thrown over this cliff, and in observing them, we’d learn whether they would fly or crash.
The next time I heard from the test lab was in another email early in 1999. The crew gladly announced it had finished testing pretty much all of the applications and had only encountered minor problems thus far.
However, a company veteran who I had befriended had his ear close to the office grapevine. Some applications hadn’t been fully tested because the process had taken longer than planned. The Program was one of them.
Soon, further news from the grapevine arrived: The Program had been shut down for good at the end of 1998 because contractual laws kept the company liable for any damage arising from use of its services up to until a year after contracts ended. The test was taking longer than planned and still not complete as 1998 was coming to a close. Concerned that The Program would flunk the Y2K test, the company canceled all contractual obligations with every customer that used it.
The irony is that test results for The Program came in soon thereafter—it would’ve had no Y2K problem. At that point, the former customers weren’t interested in signing on again with the company, happily transferring to other places for a better price.
With The Program gone, the company plunged headfirst into a restructuring program that led to most projects and departments being closed or sold off until only a sustainable core business remained. For those of us not in the decision-making process, we can only wonder if the closing of The Program was deliberate. Were services dumped that had no lifecycle management, had slipped beyond maintainability, and would perhaps cause great costs in the future—or was it simply poor prioritization and planning?
In any case, the takeaways are clear: Plan to be ready way ahead of deadlines, especially if they involve one of your best racehorses. It should go without saying: Don’t rely on tools that no one can repair or update when necessary, and be sure to have product lifecycle management in place, including the option of decommissioning systems that are too old for upgrades. Otherwise, you never know when it’ll come back to bite you.