MANY PEOPLE BELIEVE that Y2K is a technical problem. But, in reality, Y2K presents a logistical and management problem. What makes the Y2K effort such a large concern is the size of the “maintenance release” that must take place, the virtually immovable deadline, and the cost of failing to make a business Y2K-compliant.
What does compliance mean? A good definition comes from the British Standards Institute (DISC PD2000): “Year 2000 conformity (compliance) shall mean that neither performance nor functionality is affected by dates prior to, during and after the Year 2000.” Simply put, if it works now, it had better work on and after 1 January 2000.
To fully understand the magnitude, take a look at the projected costs:
■ As of September 1997, the Office of Management and Budget (OMB) expected to boost its estimate of the federal government's total outlay for Y2K fixes to approximately $3.8 billion.
■ Y2K expert and author William Ulrich says that costs for the United States and Europe combined are estimated in excess of $600 billion.
■ The first major study of Y2K's impact on Hong Kong indicated that they might have to spend $1.3 billion to correct the “millennium bug.”
■ In September 1997, the Financial Times estimated that the projected cost for eliminating the Y2K bomb worldwide was at $1.5 trillion.
There are also indirect costs, both quantifiable and nonquantifiable, attached to this global problem.
A rather startling example of a quantifiable indirect cost are the lawsuits expected to arise from Y2K failures, which may range anywhere from $1 trillion to $3 trillion, according to the Denver Post (10 Sept. 1997).
What are some of the nonquantifiable impacts of this “time bomb”? As an example, the consultancy Corporation 2000 argues that, without corrective action, there will be a cut of 50 percent in New York's electricity supply between 1 January and 10 January 2000.
In addition, many modern appliances are time- and date-driven, making use of computer chip technology. These all have the potential to fail on 1/1/2000. According to a source at a major manufacturer of thermostats, there are “millions and millions” of thermostats presently in use, programmed to perform tasks based on the date and time. These devices are not Y2K-compliant and will fail with the change of the century.
In short, Y2K is the largest problem faced to date by the Information Technology (IT) sector of the world's business community. It should not, however, become larger than life. It is nothing more than a behemoth form of something that is familiar to all of us. It has a set end date, and definite deliverables. It will consume resources and produce an end product. Along the way there will be times of confidence and euphoria, surrounding times of pure panic. These are the characteristics of a project. Admittedly, in scope, in numbers of resources needed, in dollars to be spent, and in the downside cost, Y2K is the biggest project the vast majority of us have yet to see. The fact that this project has a virtually unmovable end date magnifies the need for project management.
A Plan of Attack
How does a project manager attack a megaproject such as Y2K? The starting point is the same as for any other project. Break down the effort into logical segments of work. Then decompose these phases into summary and subtasks.
The major phases for Year 2000 are not much different from the phases for any Information Technology project: Assessment, Planning, Renovating, Testing, Implementation, Post-implementation Support.
To aid in this breakdown of tasks, a number of Y2K methodologies are available and the array of tools and vendors increases daily. Different methodologies may group two of the phases together or split one or more up in some manner. No matter the grouping of the phases, the necessary work remains the same.
Assessment. First, the organization sizes up the problem. The focal point in the analysis stage is: How many times do I actually use dates, in what formats are these dates, and what functions do they accomplish? Are dates used for validation or as part of a calculation? Are they used to perform sorts, or as the record key for file storage? The answer to these questions determines not only how large a problem exists but also the best strategy to address the problem.
There are mainframe and client/server tools available to aid in a wide spectrum of the needed activities. The most common capture some of the basic information, such as date pervasity (how many times dates are used in the code). The tools are a great time saver in at least telling the analyst where to look.
If the desire is to automate this process as much as possible, there are tools on the market that will do more than just locate the primary information. Most efforts are a combination of automated and manual work. Depending on the size and complexity of the systems, the project manager must decide which is the most cost-efficient method.
During this phase, expect to discover applications believed to be Y2K-compliant. No matter how strong the conviction that these programs are compliant, and how logical the basis for this belief, test these applications. At a minimum, confirm that when using dates after 12/31/99, the results are as expected. More extensive testing of these “compliant” applications will lead to a greater comfort level.
Assess processes outside the Information Technology area. The two major non-IT processes in most business organizations are manual processing and end-user computing.
In the vast majority of organizations, manual intervention and end-user computing activities take place at the input and/or output side of the systems processing. An example of input side manual processing is non-automated inputting into a computer application (either mainframe or PC). If dates are part of this process, these dates will have to be in the Y2K-compliant format acceptable to the renovated computer system. Methods, procedures and training need to be changed to reflect the new input date formats.
One example of end-user computing is downloading the outputs from IT processing into a PC. Once loaded, users employ either shrink-wrapped programs (Lotus 1-2-3, EXCEL, MS Access, etc.), third-party vendor programs, or homegrown applications to manipulate or report this information in some format. In many cases, the people managing the Y2K effort are unaware of the “end-user computing” applications being utilized, and chances are the software sitting on the desktop computer or LAN server is not Y2K-compliant. The problems this may cause after the century change may be large business processing impacts or merely small aggravations. In any case, to avoid these troubles, identify the end-user computing packages as soon as possible.
A good method of identifying the manual processes and discovering the elusive enduser computing applications is creation of business flows. Diagram out all the processes used by an organization. Any interactions with automated activities, any loading of output to desktop computers, should appear on these flows. Also conduct a simple end-user computing survey, asking people what packages are on their individual PCs and how these packages support their normal business activities.
Task team members with contacting third-party vendors and finding out if and when packages will be Y2K-compliant. Identify possible risks, and form mitigation plans around this information. The recommendation is that all third-party software be validated on site, using in-house testing environments. This can avoid unpleasant surprises in the future.
One output from this stage is a high-level cost estimate, including not only the resource costs but also any incremental infrastructure costs caused by Y2K.
Planning. The assessment phase identifies the what and planning determines and documents the how, when, and who accomplishes the tasks. The phase deliverables should include some type of risk-mitigation table, requirements for any additional IT infrastructure, and a project plan.
Before creating the project plan that includes durations, document decisions regarding how to accomplish the Y2K renovation for each individual process (computer and manual). How will operating environments be updated and verified? Also identify any need to construct temporary translation codes for interfaces, called bridges (changing between four- and two-digit years). These bridges may be permanent or temporary. Most bridges exist because an interface is temporarily out of sync. When the synchronization takes place, the bridge, which is additional processing, should be removed. Part of the project plan should address the retiring of these temporary bridges.
Make and document decisions regarding testing strategy. Once the team completes all these decisions, a basis for estimating durations for related tasks exists. With the additional information captured during this phase, refine the cost estimates.
The major deliverable from this stage is the project plan itself. There are many methods for accomplishing the creation of a plan. I prefer what I call the “yellow sticky” method, in which the entire team brainstorms the necessary tasks to accomplish the objective and records them on self-stick removable notes. When it appears that the team has completed all the thoughts regarding the tasks needed for this objective, stick the tasks up on the wall and ask for estimates of how long each individual task should take. Record this duration on the “sticky.” If the duration for an individual task exceeds your “comfort zone,” break down that task into two or more tasks. The rule I employ is no durations over 10 days, with five-day durations being preferable. When accomplished, do some precedence diagramming. Start rearranging the tasks in the order in which they should take place. Ask the question, “In order to do a specific task, what, if anything, must first take place?” Record the relationship between the tasks (start-to-start, finish-to-start, finish-to-finish). Identify what tasks can take place in parallel. This will provide the different paths through the project. What you are creating here is a type of real-time PERT diagram.
When this exercise is complete, the team can review what is on the wall, looking for missing tasks, or tasks to further decompose. Finally, ask who should be the owner of each of the individual tasks. Record that also on the self-stick note. It would then be efficient to have someone take what is on the wall and input it into whatever project management software package is being used. Make sure to record the precedence among the different major objectives as well as between the tasks. This will give you an excellent baseline project plan, including your initial critical path. The result is a basis for revisiting and completing a reality check on the initial budget figures and the project timeline.
Renovating. This phase may be called renovation, execution, coding, process revisions, remediation, or one of a myriad of other names. The team starts to execute and manage to the plan—this phrase is key. So many organizations are excellent at analysis and creating plans but do not use them once the renovation work starts.
As work progresses, testing the assumptions, the project's working basis moves from supposition to reality. This results in some readjustments to the plan. Start and end dates will change; tasks will be added and deleted. Record these changes and continue on with managing to the updated plan. In this sense, Y2K is no different from any other large project.
While doing the necessary coding changes, manage how these renovations are being done across the entire business organization. The two major methods are data interpretation, also known as windowing, and date field expansion. Basically, windowing is using code logic to tell the computer that, if the two-digit year date is xx or higher treat this year as a 1900 date; if lower treat it as a 2000 year date.
Date field expansion is just that. Expand the year field from two to four digits, and store the entire year. To keep the amount of work at the point of interfaces (bridging) down to a minimum, it is paramount that one method be chosen as the standard, and adhered to whenever possible. It falls upon the project manager to drive this standardization method. Most business organizations recognize data interpretation, or windowing, as the least-cost, lowest-risk method. Date expansion, although the most obvious choice for attacking the problem, can lead to many hidden problems. Going forward, for all new development, date expansion is the recommended way to proceed. For legacy systems, there may be no justification for the cost and risk of date field expansion.
Testing. A number of different types of tests can be applied to Y2K changes. At a minimum, the stages of testing needed are:
■ Baseline testing of the current code in the current environment
■ Renovated code testing in current environment with current (non-Year 2000) dates
■ Renovated code testing in current environment with dates that reflect the century change
■ Renovated code testing in a Year 2000-compliant environment with Year 2000 dates.
For all testing, isolate the test environment. Have this system firewalled from the production environment. Remember, to fully test these changes, system clocks will have to be forwarded to 2000. This can cause strange and unpleasant events, as a large bank in New York found when the developers decided to test their Y2K updates in their production environment. As a result, for a short period of time, vast amounts of money were deposited in accounts. Though the problem was caught in short order, a large amount of negative publicity surrounded the incident.
The purpose of the “current code in the current environment” test is to create baseline results for comparison against the results of the testing of the renovated code. To do this correctly, make sure that there are no “contaminating” factors in the environment. Capture and document the results from this test.
Replace the current code in the test environment with the Year 2000 renovated code. Execute the same input and scripts used to create the baseline. The code should contain no changes other than those needed to make the application Year 2000-compliant. Upon completion of the test, compare the results against the baseline testing. There should be no unexpected variations in the end results.
Next, run the Year 2000 dates through the renovated code. At a minimum, check December 31, 1999, January 1, 2000, and the first workday of the year. Also make sure that the system recognizes the Year 2000 as a leap year and accepts February 29 as a valid date. If any type of special periodic processing is included in the renovated code (weekly, biweekly, monthly, quarterly, semiannually, or annually), test the first date for each period to ensure that this functionality is operating correctly. Keep the scripts, inputs and outputs from this test stage to use in the next and final testing stage.
The final testing stage is to take the renovated code and run it in an environment where all aspects of the environment (operating systems, files, interfaces, control cards, etc) are Year 2000-compliant. Compare the outputs to those from the prior test. They should be reconcilable.
Implementation. The next phase is the implementation of the renovated and/or validated code into the production environment. For this, follow the current version control procedures.
Post-implementation. Good project management dictates that there are still activities that must take place after the code installation. These include:
■ After installing the code in production, there will be a need for some help desk support for the applications. The period of time necessary for this support is specific to each individual application.
■ Verify the installation or at least make sure that the subject matter experts and major players are present during testing of the Y2K-compliant code at all disaster recovery sites. Most business organizations have contracted for outside contingency sites to mitigate possible disasters at processing centers. Set up processes to guarantee the sending of copies of the renovated applications to the contingency sites. It would be advantageous to retest the code in the disaster recovery site.
■ As part of contingency planning, a detailed Emergency Back-Out Plan should exist. Direct every effort within the allowable timeframe to keeping the Year 2000 code and operating system components in production. A back-out of code must be a last resort activity.
■ Monitor performance in the renovated environments to validate no adverse impacts upon the batch windows. This is most appropriate where large numbers of bridges were constructed. This monitoring will indicate where there is a need for performance tuning.
■ Create and adhere to plans for the retirement of temporary bridges and remove them as soon as possible. This is additional executable code that may have impacts upon processing time. Coordination between the receiving and sending areas for interfaces is extremely important to facilitate this activity.
■ Update all methods and procedures to reflect any Y2K changes.
■ Conduct a post-implementation review and gather lessons learned.
PROJECT MANAGERS HAVE a lot to contribute to and learn from Y2K efforts. View these projects as the catapults that will launch not only the business systems but also project management itself into the next century. ■
Harry B. Hart, PMP, is with KPMG's Year 2000 Practice. He has spent the last two years at client sites, assisting in the establishing of Program Management Offices to deal with the multiple aspects of the Y2K issue.