|
|
The Dangerous Phase
by Ed Meagher
The Y2K Advisor
WWRC - AM570 Business Radio
I was recently asked if I didn't feel better about the Year 2000 (Y2K) computer problem now that "...you hear so much about it in the news." This from a well meaning friend who has had to listen to me endlessly complain over the last three years about the lack of awareness of the problem and the slow progress towards solving or at least mitigating the worst effects of a Y2K meltdown.
I have thought long and hard about that question and whether my partner, Tony Keyes, and I are sufficiently open to changing our viewpoint about where we see this problem heading. Tony and I have been co-hosting an hour-long talk show on an all business news radio station, WWRC, in Washington, D.C. for the last two years called, The Y2K Advisor. We have interviewed over three hundred movers and shakers, thinkers and critics, technicians and managers involved in the Y2K problem/solution. I would venture to say we have the broadest perspective over the greatest period of time of anyone involved in the Y2K issue. We have developed a loyal audience and some degree of respect as a fair and objective voice trying to raise the level of discussion of this critically important topic. So it is especially important for us to keep an open mind towards new solutions, new efforts, new players. We must be prepared to acknowledge progress and be willing to take down our "storm warning" alarms.
So with that in mind I have gone back and reread the hundreds of news stories and reports that have been coming out over the last few months. I have revisited the web sites and rechecked the corporate statements and filings that are available. I have paid special attention to pronouncements coming from governments at all levels and around the world. Like it or not, these governmental entities account for between 30% and 50% of GDP worldwide. The continued effective, efficient operation of these enterprises is critical not only to the well being and safety of the public but also to the health of the economies they support. I have gone back to many of the folks we have interviewed and asked for an update concerning their area of expertise and perhaps more importantly asked their perspective on the progress over time that they perceive. Finally Tony and I have made a special effort to discuss the current Y2K situation with an open mind and willingness to change our point of view. We have agreed to challenge each other's assumptions and perspective. So where are we?
Before I can respond to that we need to consider the context in which we view the various pieces of information. Progress is relative. In a non-time bound situation the Y2K issue would have been treated differently. The first phase would have been assessment. While there are no formulas that I am aware of, the typical assessment consists of a short, initial assessment that results in an estimate of the more detailed assessment that will be required to produce a meaningful project plan. A structured awareness campaign might be launched during the detailed assessment phase to bring all key people up to speed on their expected role. Typically this first phase is not time-constrained and takes as long as it takes to fully assess the situation. It is a truism that care taken in this phase result in a better outcome to a project. A detailed project plan consisting of robust staffing, budget, and program management plans is essential if there is to be any expectation that a complex project will be completed on time, on budget, and fully functional. Tools that allow for highly granular evaluations of progress against plan are indispensable. This requires the identification of key metrics and milestones. At this key junction an effective and efficient remediation phase could have been initiated. With a fairly high degree of accuracy a detailed timeline could be produced and any deviations to plan identified and corrected.
Early in this phase a testing and evaluation phase could have been implemented in order for test managers to learn as the project evolved. Key issues of unit, module, application, system, and end-to-end testing could have been explored and settled. Testing could begin on a unit level almost immediately and progress up the integration ladder. Full-scale end to end testing would begin immediately upon completion of the remediation phase and continue for as long as necessary. Another very important truism is that testing takes as long as testing takes. While it is possible to estimate a test period, in practice testing goes on until the system performs satisfactorily. At this point based on the criticality of the individual system another less well-known phase is usually initiated. This is known as Independent Verification and Validation (IV&V). The premise is that the folks who do the testing are too close to the project. They subconsciously or otherwise want the code to work. Their goal often becomes proving that the system works. The goal of the IV&V team is to break the system, to find it's flaws, to identify its weaknesses before it is put into production. IV&V is usually reserved for mission critical systems. IV&V teams have been known to find critical flaws that have delayed systems for months, years, and in some cases cancelled them entirely.
Next a detailed implementation phase would be planned and implemented to bring remediated systems back online. Concurrent with these activities any issues of training, documentation, and revisions to policies, practices and procedures would be identified and addressed. Finally a comprehensive integration plan would be developed and integration testing and implementation would be phased in over time. This is how any professional would approach any project of this scope and magnitude. The literature if full of stories of projects gone bad as a result of the failure to apply a structured methodology.
The fact that only 14% of large systems development projects are completed on time, on budget, and fully functional is testimony to the difficulty involved in managing these projects and the degree to which many of these established processes are ignored. Depending on size, scope, and complexity the non-time bound Y2K project would have taken anywhere from several months to several years. Well what has actually happened in most Y2K projects? A survey conducted in 1996 indicated that only 11% of companies in the U.S. had actual begun a Year 2000 project by December of 1996 and only 15% considered starting one a high priority. This means that 85% of American firms had a maximum of 36 months to complete a full Y2K project cycle. By the end of 1997 some 60% of U.S. firms reported beginning a Y2K project. This means that fully 40% have given themselves less than 24 months for a full cycle project.
The U.S. Government reported that as of June 1, 1998 over half of the 24 major federal agencies are behind schedule. What this means is that time is the key determinate. Instead of being able to assigning the time required to complete a task, time is assigned as a percentage of the time remaining. So if the project began with 24 months remaining, 10% or 2.4 months might be assigned to the awareness phase. At the end of that time the awareness phase is complete whether it is or not. Same for the assessment phase. Time's up -- the assessment phase is complete. It gets a little more difficult during the remediation phase but various techniques are available here too. Moving systems from critical to non-critical seems to be a favorite tactic. Another tactic involves remediating the simplest code first. But so far most companies and agencies can report that they are on or nearly on schedule.
Even without challenging that assertion there are several issues that remain. What constitutes a non-critical system? Is it that someone has determined that they can survive without it? Or is it that a detailed analysis has been performed and it has been determined that it is not a critical component to any internal process, does not provide or manipulate critical data, and it is not a critical component to any external system or process? Obviously, the latter case requires much more detailed analysis. What is the status of all embedded chips or process controllers? Where in any of the phases have these devices been factored into the equation? All of these questions aside, the fact remains that very few programs have reached the testing phase. Trying to time constrain testing is a recipe for disaster. IV&V is simply a luxury that few can afford. Integration, documentation, and training may simply have to be done on the fly. So even granting the dubious proposition that an entity is "on schedule" through the remediation phase leaves the problem that the toughest, least understood, most time consuming phases remain ahead.
Finally it must be clearly understood that almost all of the progress reported so far has been self-reported. Only a very few have had the luxury of having an independent outside audit of its program [The biggest exception is the General Accounting Office's audits of U.S. Government Agencies and it is very telling that several Federal Agencies have received failing evaluations.] This creates a new and very serious problem. The average Y2K manager is keenly aware that the scale and scope of this problem is only dimly perceived by non-technical corporate management. He or she also knows that explaining the Y2K value proposition is a thankless if not impossible task. ["Let me see if I got this right Bill, I get to spend millions of dollars, I lose all productivity from my MIS shop, and if I am lucky I get to stay in business?"] Ultimately he knows that if he expresses any doubts or is unable to state definitely that everything is on schedule and under control he is probably going to get fired. This almost inevitably leads to the "Amen Chorus" we are hearing.
So where are we? We are at the most dangerous period in this process. Having come through the excruciatingly painful and drawn out awareness raising period we now have reached a point where senior management is being forced to acknowledge that a Y2K problem exists. They are lining up along with key government bureaucrats to state unequivocally that they are on schedule, that everything is going to be fine, and that there is absolutely nothing to worry about. When questioned they revert to name calling such as "fear mongers," "panic merchants," and, worst of all, "profit seekers" to discredit their challengers. The message is clear, "Don't worry, be happy." Sadly, that is exactly what we want to be told. We want to be reassured that something as trivial as dates in a computer can be fixed quickly. We do not want to confront the frightening truth that we have let computers become essential to our well being, our safety, our health, our very way of life.
So we are at a point where we must decide to ask the hard questions or accept the facile assertions of "leaders" who don't understand or can't bring themselves to speak the truth. There is not one shred of evidence, or one success story, that should give anyone the idea that all will be well. Self described progress reports must be seen in the context of who is preparing them and what is being described. Finally, we must not let up the pressure on everyone involved to work around the clock to solve what can be solved and to plan to mitigate the effects of the inevitable failures.