Give yourself a pat on the back for this one. Midnight came on December 31, 1999, and chances are, the worst thing that happened was that your IT systems displayed a few errant report screens that rolled over from 1999 to 19100. Otherwise, your organization stayed open, or reopened for business as usual on Monday, January 3, 2000. So much for Y2K. In the end, it looked like somebody called a war, but nobody came.
By the middle of last year, most of us became pretty bullish on surviving the date change. Before that, however, it looked like Chicken Little was calling the shots. Remember the fears about the lights going out and chaos breaking loose? The myths about long-lost COBOL programmers commanding $100,000 salaries, or the dire warnings that youâ€™d better book Y2K consultant time early, because their rates would skyrocket the longer you waited?
Fast forward to the present. Your systems rolled over with little incident. You didn’t have to worry about finding COBOL programmers or consulting help. Your company probably relied on your services, rather than hiring consultants, because people like you knew best where the date problems were, and knew the business well enough to know which date fixes had to be done, and which ones could pass. Maybe your company deferred some important IT projects, or maybe it accelerated a few long-awaited system replacements.
Congratulations. Your company survived the disease. Now, the question is, will it survive the cure?
For most organizations, Y2K was the moral equivalent of ERP. Y2K projects forced us to take stock of our IT assets, in many cases, for the first time. It drove organizations to clear the cobwebs, identifying what systems were still in use, how they were used, and which ones could be retired. So far, no pain, all gain.
However, the headaches began when your company began scouring those 15 â€“ 20 year old COBOL programs. If your company was lucky, it still had a few of the original developers around. If not, it was time for the sleuth work.
Once the assessments turned to the bedrock systems your company used everyday, it was time to haul out the change management process, because those systems were too big to fix in one shot. It was time for a reality check with users. What parts of the system were most used, and which parts were the least valuable? What workarounds were possible? In what sequence should we fix the parts to minimize disruptions?
With the change management process updated, it was time to dig in. Renovate the code, followed by the never-ending testing. Again, the upside was the opportunity to engage users, whose acceptance was the final test.
The final step was dusting off those contingency plans. Of course, with Y2K work going so well, it was easy to grow complacent, but Y2K was a potential disaster too universal to ignore. Even if your company held up its end of the bargain, what would happen if the power went out, the phones failed, or your business partners began sending corrupt data?
Even the best-prepared organizations had to revisit their contingency plans. A South Florida company, which had plenty of experience planning for hurricane disruptions to headquarters, had to revise its plans because they didnâ€™t adequately factor local processing problems at its regional distribution centers.
In the end, many of us gained a clearer picture of our IT assets. We updated our change management processes, beefed up testing procedures, and hopefully improved overall software quality. We engaged users from planning through final acceptance testing stages. If we were lucky, we had the chance to replace older desktops with new, standardized, more maintainable configurations and accelerate some new enterprise transaction system projects.
According to Gartner Group, we spent $300 â€“ 600 billion worldwide to fix Y2K problems, and if we improved internal practices to boot, the investment should prove worthwhile. Significant pain, but plenty gain.
However, itâ€™s human nature to mobilize for emergencies, then rest on our laurels. If we relax too much, all those updated asset inventories and change management practices could easily fall out of date. Lacking strong follow-through, the Y2K cure could prove worse than the disease.