PC Week - What we can learn from Y2K?greenspun.com : LUSENET : TimeBomb 2000 (Y2000) : One Thread
[fair use for educational/research purposes]
What we can learn from Y2K?
Updated 8:39 AM ET
September 27, 1999
By Jeff Moad, PC Week
It's human nature, I suppose, to want to put difficult experiences behind us, to move on as quickly as possible to the promising new thing. I know that's my tendency. When I've been working on a project that didn't turn out as well as I'd hoped or that involved more bumps and bruises than I expected, the last thing I want to do is go back and closely re-examine what happened.
But sometimes taking a hard, retrospective look at how we dealt with -- or failed to deal with -- a major challenge is exactly the right thing to do. I recently heard a radio commercial in which basketball coaching great John Wooden said the best teams are those that make the most mistakes. That's because, he said, making mistakes usually means you're trying new things. (Of course, it could also mean you have crummy players. But that wasn't a problem at UCLA.) The trick is to learn from your mistakes.
If Coach Wooden is right, the information technology profession right now is about to be presented with a great learning opportunity, one that, if taken, could go a long way toward enhancing the role and value of IT at many organizations. Many if not most IT professionals have spent night and day over the past year or two on one of the most demanding, massive and stressful projects they're likely to face in their careers: making sure their organizations' systems are Y2K compliant.
After the last bit of remediation code is tested and deployed -- not too long after Jan. 1, 2000, it is to be hoped -- most IT professionals will probably feel overwhelming relief that they'll never have to think or hear about Y2K again.
The big picture
But putting Y2K aside and moving onto the next big thing too quickly would be a mistake. There's a lot IT managers can learn from the whole Y2K experience -- how the Y2K problem arose in the first place and how technology managers coped (or should have coped) with it. IT managers who learn those lessons will be better prepared to take on the big challenges that are to come, challenges such as helping mold their companies into e-businesses.
There are obviously a lot of programming-specific lessons that IT managers can pull out of the Y2K experience. Always keep source code documentation around, for example. And never assume that a system will only remain in production for a finite period of time.
But there are also some big-picture lessons that everyone -- from IT managers to top corporate executives -- should take away from the Y2K experience. Here are a few that come to mind:
IT projects must be driven by business strategy, not by technology priorities. Developers of the first generations of business systems took the two-digit shortcut that caused the Y2K crisis not because it delivered any significant business benefit. They did it because it was a quick and easy way to save some memory. If the number one priority of these projects had been, from day one, business-driven, it's likely that many companies would have avoided the whole Y2K mess in the first place.
Business management -- even CEOs, COOs and other top business honchos -- must be involved in major IT projects. This point is, obviously, related to the first lesson. But in the era when many systems that turned out to have Y2K-compliance problems were built, most top business executives had virtually no involvement with IT, and they liked it that way. So at many companies, there was little or no direct link between business strategy and IT strategy. Again, technology decisions -- such as whether to use a two-digit year -- were made without much thought for what was right for the business. Now, at least in part thanks to the Y2K experience, it's clear that business and IT strategy must be in lock step. The only sure way for that to happen is for business management to take an active role in IT.
Just as business is now conducted on a global basis, IT strategy must be executed on a global basis. Y2K has perfectly illustrated this point. While many U.S.-based companies have finally succeeded in making their systems Y2K complaint, IT managers must still contend with the fact that, increasingly, their systems are integrated with the systems and networks of overseas partners who may or may not be compliant. So IT strategy, planning and execution are no longer limited to within the four walls of the enterprise, or even the boundaries of the U.S. They are global issues.
Project management must be a core competency of IT. It's easy to imagine that, because Web-era IT projects are often executed in weeks rather than months or years, that project management skills are no longer important. Y2K should be proof that nothing could be further from the truth.
What lessons have you learned from your Y2K experience? Let me know in the talkback below.
I think the real lessons that can be learned wont be known until after the experience is over...
might be fun for IT pros here to visit that talkback : )
-- Michael Taylor (firstname.lastname@example.org), September 27, 1999