THE CENTURY CHANGED with barely a hint of Y2K-related computer system failures, in spite of all of the media hype and public concern that led up to 1 January 2000. Because the Y2K rollover was almost completely uneventful, some segments of the media as well as some corporate executives have suggested that it was all a big deal over nothing! If they are right, was it because the problem wasn't as bad as we thought? Did we “overkill” the project, spending far more time, money, and resources than we needed to? What was the real value we gained from the project—was it worth the cost? How satisfied are we all now that the job is essentially done? And what did we learn from all of this?
With two tours of duty managing Y2K projects spanning most of the last three years now behind me, I can honestly say that I am grateful that I won't live long enough to do Y3K! Similar sentiments have been echoed from just about everyone else that I have spoken to who worked on Y2K projects, including people who worked with me, and colleagues from other companies.
Why Do Most People Feel This Way? Here's the feedback I've gotten from scores of individuals, across several companies:
D. Allen Young, PMP, is currently a project office manager at a major point-of-sale network, credit and payment services company in Dallas, Texas. He has 22 years of experience in the financial information systems industry, with the last 10 years running project offices, building project management infrastructures, managing project teams, and teaching project management.
Long-Range Benefits of Y2K Efforts
In its first quarter 2000 report, the United States Office of Management and Budget estimated that the U.S. government spent $8.34 billion on Y2K efforts. The Gartner Group has estimated that $300 billion will be expended worldwide. Whether you believe the expenditures were vitally necessary or a waste of resources, ongoing long-term results and improvements in the form of best practices from the efforts to correct a two-digit date field are awfully nice to see.
According to the U.S. Intergovernmental Advisory Board, the enormous investment of money and resources to fix the Y2K problem has resulted in continuous, ongoing, incremental improvements that are becoming best practices that will be beneficial far into the 21st century. Here are some examples.
Maintaining Information Technology Inventories. For many entities, Y2K efforts resulted in the first complete inventories of hardware and software.
Renovating Information Infrastructures. The implementation of better configuration management has improved organizations' underlying information infrastructures.
Forming Interagency Partnerships. While preparing for Y2K events, public agencies worked together to overhaul the coordination and preparation of emergency services, improving the readiness of these agencies to deal with a wide variety of disruptive events.
Improving Project Metrics. Simplification of high-tech environments, advances in software quality and productivity practices, testing, and cost estimating have all provided quantifiable improvements to projects.
Exchanging Data. Widespread use of the Internet allowed diverse organizations to exchange information about their Y2K efforts.
Testing Enterprisewide Procedures. By testing for Y2K compliance across the enterprise, based on business functions, organizations were able to discover and correct integration problems not necessarily related directly to the Y2K problem.
Planning for Business Continuity. Before Y2K preparedness exercises, most organizations had not planned for long- and shortterm business without vital infrastructure services such as electricity, water, and telecommunications. Preparing these business continuity plans encouraged technology staffs and programmatic staffs to interact in a way that seldom occurs in daily business activities.
Elevating the Importance of IT. IT is now viewed as an enabler to transform business processes, as organizations acquire a deeper awareness of the crucial role computer technology plays in the accomplishment of the organization's mission. As a result, cross-functional relationships have been strengthened and greater cooperation on large-scale projects is achieved.
Sidebar prepared by Pat Hinds, staff writer for PMI Publishing Division.
The “Draft.” Most employees were “drafted” into service. They were doing their normal jobs one day, and the next they were swept into the Y2K vortex! Most people preferred doing what they had been doing, rather than Y2K. The Y2K project almost became an imposition to everyone in the company.
The Age of the Dinosaurs Isn't Over Yet. In spite of the move toward client/server and web-based technology in recent years, the largest percentage of the world's computer systems still run older legacy applications. The typical legacy application is written in the COBOL programming language, uses “flat” and virtual storage access method (VSAM) file formats, customer information control system (CICS) online screens, and maybe some ancient assembler language thrown in just for fun! These systems are viewed in the IT world today as “dinosaurs,” and they aren't very sexy or appealing for those moving into the client/server and/or Internet arena. Y2K essentially forced many people back into the Jurassic period! For some older, retired programmers, Y2K was almost a bonanza—a last-hurrah opportunity to take a brief respite from retirement to make a few extra bucks. For the rest of us, it was mostly drudgery.
Time Crunch. Few companies started their Y2K projects well ahead of time. I'd be willing to bet that more than half started at least a year later than they should have. Since the finish date was immovable, this compressed more work into a shorter time period. No company has unlimited resources, and most were trying to operate within a budget, so the horizontal timelines took on a more vertical look (that is, lots of overtime hours). Most contract programmers took advantage of the opportunity to make extra money, while salaried employees often had to put their lives on hold. (In my case, I was preparing to take the PMP exam in January 1999, but was reassigned to Y2K in November 1998—I didn't have time to finish studying and actually take the exam until almost a year later.)
Why Did So Many Firms Start Late? What reasons did they give? I encountered six key rationales for the late starts:
“It's Not Real Business.” Y2K was not viewed as a revenue generator, but rather as a huge expense. Companies that started late frequently didn't consider Y2K the No. 1 priority project until 1999! Interestingly, companies that had enough foresight to start and finish early got the jump on their competitors toward the end of the decade. A few other “early birds” leveraged what they learned about Y2K and sold their Y2K methodologies and tools to other firms.
“New Systems are Compliant by Default.” Companies that had replaced (or were in the process of replacing) their legacy systems assumed that the new systems were already Y2K-compliant (or were being built to be so). Reality has proven that this was not always a valid assumption. Many client/server operating systems, databases and tools were compliant from the vendors, but there was no guarantee that custom application programs would be. Client/server application programmers could still write code and store dates with two-digit years just as easily as their “dinosaur” counterparts—and sometimes did! In fact, I encountered a brand-new system that was written in 1999 that was amazingly not Y2K compliant—used two-digit years when it could have used four—and had to be hastily modified late in the year. (I predict that we won't see the practice of programmers using two-digit years disappear completely until the next generation of computer science college grads hits the job market!)
“We Don't Do Anything With Dates.” Companies with systems that didn't do much in the way of date calculations, and simply passed dates through, believed that Y2K was the other guy's problem. Financial services firms such as banks and insurance companies certainly had more date-related computations, and thus more complexity to deal with. Everyone still had some dates in some of their systems, and not all of them would recognize “00” as valid, or know which century was the correct one, and/or handle year 2000 as a Leap Year. Anyone who sized the effort from a top-down view invariably fell far short of reality.
“Just Outsource It.” Some executives believed that they could use hired guns to fix the problem, and relied on outside contractors to do the work. Unfortunately, the later a firm waited to start, the more expensive it became, because the “sticker price” kept climbing. In some cases, contract firms stopped taking orders past a certain point, either because they already had more than enough business to handle or because they knew there was no way they could deliver a successful outcome within the time remaining on the calendar. Highly touted and automated Y2K tools also typically fell somewhat short of expectations, and caused more manual assessment, renovation, and testing work than had been planned.
“We Know What We Have.” Many firms believed that they had started early enough, only to find that they had not accounted for the time necessary to build an inventory of all of their hardware, software, and facilities components, which was often incomplete or missing entirely. Companies with sound change and configuration management processes and tools had a much easier time; those who didn't spent months just trying to figure out what they had, before they could really get into the assessment phase of the project.
“What, Me Worry?” Some companies did not feel the heat to get started until the boards of directors and executive managers discovered that they could be held personally liable for damages resulting from not performing sufficient Y2K due diligence. In a few cases, federal examiners had to provide the impetus to get the company seriously committed to the endeavor.
It is remarkable that the firms that started late still managed to beat the deadline! There is only one explanation in my opinion: the commitment, dedication, and sacrifice that their employees were willing to make to get the job done! Their companies should highly commend and reward these people!
Other Challenges. Along with a fixed deadline, late starts, and limited resources, there were many other challenges along the way:
Scope. Y2K for many was the ultimate “scope creep” project! Undiscovered components would unexpectedly surface that required assessment for compliance. New business did not stop just because Y2K was in progress. Acquisitions of other companies added more to the already overwhelming Y2K project potpourri. Periodic independent audits and/or federal examinations had to be conducted throughout the project.
Communications. Until the Y2K Disclosure Act was passed, all external disclosures had to be reviewed and approved by legal counsel and/or a corporate communications group. Even internal communications had to be carefully monitored, to minimize any legal exposure.
Cost. Several organizations (for example, The Gartner Group) published cost projections to fix the date problem, ranging anywhere from 50 cents to $1 to $3 per line of code. Early Y2K budgets often tried to use this formula. Unfortunately, the reality for many companies was that it was almost impossible to track costs to this level of detail, and since no one had ever done a Y2K project before, there was little history to help justify the budget numbers. Companies with traditional departmentbased, functional budget and cost accounting systems were also ill-prepared to deal with the sudden need to track project-based costs at an enterprise level.
Reader Service Number 080
Documentation. The old joke that “real programmers don't do documentation” of their applications became much less of a joke and more of a sobering reality for Y2K projects. Companies that initially planned to outsource much of the Y2K work soon realized that this strategy only worked well if clean, accurate, and complete documentation could be provided. Companies without adequate documentation reluctantly had to put their key subject matter experts on the job, which removed them from the revenue-generating projects for long periods of time.
Risk. Y2K essentially forced risk assessments to be done. For a company not used to risk management and the potential bad news they can put in front of top management, it was a real eye-opener—it showed how tolerant the firm was for this practice.
Quality. The real proof was in the testing, which often amounted to at least 50 percent to as much as 80 percent of the total project effort. Not only did all of the renovated components have to be tested, but virtually everything else as well, just to make sure that nothing was missed. Even more importantly in this interconnected world we live in, external testing had to be scheduled with each and every client and third party. One of the clients of my current employer even went so far as to insist on including Y2K test deliverables and test dates in their contract renewal in 1998. If we had not satisfied the client's deliverable and date requirements, the client could have terminated the contract, and my company would have lost significant revenue.
What Did We Get Out of It? We spent a lot of the time, money, and effort. What we got for what we spent can be divided into two categories: expected rewards (which essentially everyone got), and unanticipated benefits.
Expected Rewards. These are what top management and the boards of directors expected. They included little or no lawsuits (the industry projections of a year ago, of post-Y2K legal bills costing double the project costs, will likely never materialize), no lost clients, no disruption of service, no degradation of company good will, and a quick return to the real business at hand.
Unanticipated Benefits. Y2K essentially forced these onto many firms. They included better change and configuration management processes, better help desk procedures, better communications (internal and external), better testing platforms (in some cases, actually creating testing platforms for the first time!), better documentation of applications and systems, improved client relations, and better project management discipline.
Y2K WAS THE ULTIMATE cross-functional, do-more-with-less, immovable deadline project, yet despite the colossal challenges and obstacles we faced, virtually everyone pulled it off! The unanticipated benefits and the rewards were, in my view, well worth the dollars spent, even if they went over budget. After all, this was business survival! Y2K was all guts, no glory if we succeeded, and all blame had we failed. My apologies to the news media that we didn't generate any sensational or explosive news headlines during the Y2K rollover, but it was our job to make sure that we didn't! ■
Reader Service Number 057