I’m honored and pleased to have the opportunity to be with you today. When I talk with auditors, I’m normally on the receiving end of the comments, so it’s great to be able to tell you what I think for a change. Obviously, the fact that you’ve chosen to hold your meeting in Denver demonstrates that your organization is well run. I’ve been A Denver resident for three and a half years, and have a convert’s zeal about the city as a great place to both live and visit. I hope you’ve enjoyed your time here.

Whenever I hear that bio read as an introduction, I find myself wondering if I should edit it enough to disguise some of the basic facts. Usually when my training in economics is disclosed, two guys in the back row immediately fall asleep. This number is doubled when the audience has spent the previous evening at the Denver Buffalo Company.

For some reason, there seem to be even more bad jokes about economists than there are about lawyers. One of my former bosses used to periodically remind me that an economist was a numbers person who didn’t have the personality to be an accountant. Another frequent suggestion is that God created economists to make weather forecasters look good. That line was obviously created by someone who had never had to live with the uncertainties of Denver weather.

If it gives you any comfort, I moved out of the Research side of the Federal Reserve into an operations management job a number of years ago. I’m currently serving as the Federal Reserve’s Y2K project leader, working on ensuring that our systems are ready for the century date change, so a very large part of my waking, and, I must confess, occasionally my sleeping hours, has been spent thinking about the year 2000. Today I want to spend some time talking about the current Y2K status of the Federal Reserve, the financial system, and the U.S. economy. Then I’d like to talk about what lessons we’ve learned—or at least should have learned-- from our Y2K efforts. Along the way, I’ll try and give you a few thoughts about what information technology auditors should be worrying about during the remainder of 1999.

The message that you’ll be hearing from me is that while the Y2K problem is serious and large, the Federal Reserve, the U.S. banking system, and the rest of our financial system are in good shape in preparing for the year 2000. I’m also cautiously optimistic about the rest of our economy, and while I expect the time patterns of activity in various sectors of the economy to be affected, I don’t think the Y2K problem is likely to have a major sustained affect on it.

I think that there are some important lessons to be learned from our Y2K efforts, and we should take care to remember them.

The Cost. Let me begin my discussion by noting that while it’s certainly possible to exaggerate the extent of the year 2000 problem, continued attempts to suggest that it’s really a relatively minor problem that has been greatly exaggerated by Y2K consultants demonstrate remarkable ignorance. I have yet to find an organization of any substantial size that has examined it’s own situation and reported that the cost of getting ready for the new century was less than it had expected. The norm has been for initial cost estimates to be raised significantly. For large organizations, cost estimates in the hundreds of millions of dollars are the norm. For the U.S. Federal Government alone, the total is now estimated to exceed $8 billion.

In the Federal Reserve, we’re estimating a cost of $125 million for our project. However, Y2K projects involve so many people, most of whom are already on the payroll, that no organization really knows exactly what it is costing. The largest cost for many organizations may well be the foregone opportunities of introducing new products because programmers are unable to take on any work not connected to the year 2000 project. This opportunity cost is not being factored into anyone’s estimate.

Federal Reserve Governor Kelley estimated last year that the private sector cost of Y2K remedial efforts in the U.S. might be roughly $50 billion. Given the subsequent upward revision of many firms’ public cost disclosures, I’m sure that an estimate made today using the same methodology would give a discernibly higher number.

The Extent of the Problem. So much nonsense has been written about the year 2000, that it’s difficult to accurately describe the full extent of the problem. The best comprehensive assessment that I’ve seen was recently published by Senator Bennett’s Y2k Committee and is available on the Committee’s web site. Although I’m not an expert on either of them, the best information that I have is that pacemakers and automobiles will still be functioning when their owners leave New Year’s Eve parties on the morning of 1/1/00. Vault doors are something that I have more responsibility for, and they are on almost every list I’ve seen of things that may not work after the century rollover. I have, however, after a moderate amount of research, been unable to find anyone who has heard of anyone with a vault door that could possibly be affected by a Y2K problem. They universally use hours, (for example, 62 hours until the door can be opened), not dates, and all the ones I know about have mechanical clocks, not electronic ones.

On the other hand, the problem is extremely widespread in software¾ it’s even common to find a few problems when testing software designed to be Year 2000 compliant. If an organization is lucky, and tries to run software that is not Y2K compliant in the next century, it won’t run at all. If it is unlucky, it will run, but give the wrong answer, perhaps in ways that are not obvious. A letter to a 104 year old woman telling her it’s time to enroll in kindergarten¾ an apparently real example¾ is amusing. Miscalculating the payments to be made on an annuity¾ an example I’ve seen cited, but haven’t verified¾ is not.

Perhaps the most difficult issue to get a handle on is the area of imbedded systems—computer chips are, as you know, everywhere today. They aren’t just in computers¾ they’re in elevators and valves and VCRs and even snow plows. The consensus seems to be that most are OK, but that perhaps two percent are not. The difficulty is finding the two percent. This is a particular problem for complicated manufacturing plants, since many of the devices cannot be tested, at least not in a straightforward fashion.

What all of this means, of course, is that every organization has to take a very close look at its software, computer hardware, and imbedded systems, in order to ascertain what problems exist and then fix them. We are all having to test everything that can possibly be tested. When it comes to vendor supplied products, the order of the day for Y2K staffs is to accept the Ronald Reagan maxim of "Trust, but verify." We all have stories of products that vendors have told us are Y2K ready when testing shows that they are not.

I’d like to spend a few minutes talking about the Federal Reserve’s Century Date Change Project with two objectives in mind. First, to give those of you who are not involved in year 2000 work some idea as to what is involved in it, and second, to let you know how the Federal Reserve is doing.

The Federal Reserve’s progress is important to both the banking industry and the general public, as our systems are at the heart of the United States payment system. In this regard, we are quite different than central banks in most other parts of the world. Because the banking system in the United States has historically been extremely decentralized, the Federal Reserve has, since it’s creation, been actively involved in the payments business. In a typical day, we process two trillion dollars worth of large dollar funds and securities transfers over our Fedwire system, handle 70 million checks, and pay out 95 million Federal Reserve notes. We also run the automated clearinghouse system that handles direct deposits of payroll and Social Security payments, utility bills, and other electronic payments.

The Federal Reserve has been dealing with the Y2K problem since the first Treasury securities with a 2000 maturity date were issued in the 1970’s. In the 1980’s, we centralized our mainframe data processing, and we rewrote our major applications with the year 2000 in mind. We established our formal Century Date Change Project—the term Y2K was not yet in vogue—in 1995.

All Year 2000 projects contain essentially the same set of elements. You begin by creating an awareness of the problem, then do an inventory of components that may be affected by the problem, do an assessment of the components to determine the extent to which you need to make repairs, then remediate the problems, test your systems, and implement the repaired systems.

In the Federal Reserve, we have completed all of these steps for our critical systems—the systems that process payments, and almost all of them for our noncritical systems. The systems that process our payments every day are already year 2000 ready.

We still have lots of work to do, but it’s in the areas of contingency planning and communications with banks and the public, not in fixing systems.

Every objective observer of Y2K preparation in the United States has concluded that the banking system is also well on the way to being ready for the Year 2000. I think that this reflects two aspects of the industry. First, banks are institutions with a tradition of strong controls and a focus on risk management, both of which provide the right culture for focusing on the Y2K problem. Secondly, banking is a highly regulated industry, and the bank regulators are certainly taking this issue seriously.

Every Federally insured depository institution in the United States has had at least two Y2K examinations conducted by its primary Federal regulator. Bank data processors have also been examined. The FDIC reports that 98 percent of the institutions that it insures are making satisfactory progress—"satisfactory" is the best grade that an examiner—or an auditor is willing to give any one. To satisfy its regulator, a bank had to be on track to have all of its critical systems done by the end of June, as well as being on track in contingency planning, customer communication, etc.

As a payments system operator, we get another look at banks, as all banks of any size have on-line connections to the Federal Reserve. About 9,000 of our customers have already tested with us, and all the indications we have are that this testing has gone extremely smoothly. Thus, our testing experience is very consistent with what we are hearing from the regulators.

Turning to the U.S. economy, there is a clear consensus among students of the Y2K problem that the United States is well ahead of the rest of the world in preparing for the Year 2000. The problem was clearly taken more seriously here than in much of the rest of the World, although several other countries, notably Australia, Canada, and the UK appear to be making excellent progress.

Within the United States, large firms appear to be dealing fairly well with problem, but there are obviously great differences across firms. Let me briefly discuss a few significant sectors of our economy.

Last year I was especially concerned about telecommunications, because this industry is absolutely critical to every economic activity. Financial networks, electrical grids, and gas transmission systems all are totally dependent on telecommunication. So is any one who relies on a computer located outside the building where she is working. Because telecommunications employ lots of lawyers, these firms were initially providing very little very little information of any kind. More recently, telecommunication firms appear to have become significantly more forthright. They are now making some pretty strong affirmations about their readiness.

Electrical utilities also appear to be making excellent progress.

The good news about small business is that a lot of it is not totally dependent on computers, and manual alternatives are frequently feasible. More good news is that many small businesses probably still have time to implement most if not all of their Y2K needs. Whether this actually happens remains to be seen, as numerous surveys continue to show many small businesses failing to take steps to protect their businesses from Y2K problems. However, I’m still nervously hopeful that the U.S. small business sector will be adequately prepared for the century date change.

The Federal Government appears to be doing better than might have been expected a year ago. The progress of the Social Security Administration and the Treasury’s Financial Management Service, when combined with the Federal Reserve’s progress make me very confident that Government payments will be going out In January of the Year 2000. Problems at other agencies have been very well documented, however, and some agencies may still be fighting year 2000s problems in the year 2000. However, the news in general on the Federal front seems to be getting progressively better.

It’s been very difficult to perform a good assessment of the current status of state and local governments. Some appear to be making excellent progress, while others, especially at the local level, appear to be far behind. A major concern is the extent to which local governments control critical components of our infrastructure¾ water, public safety, traffic lights, and public transportation, for example. Work presented to Senator Bennett’s committee last week suggest that some cities still have a lot of work to do, with far too many saying that remediation work will stretch well into the fourth quarter of this year.

I don’t pretend to have much first hand knowledge about health care, but Senator Bennett’s report suggested it was the sector lagging the furthest behind on Y2K. The Health Care Financing Administration (HCHA), which pays Medicare and Medicaid bills, has been consistently cited as a laggard among Government agencies.

I need to emphasize that what I know about the rest of the world is all second hand knowledge. Progress on the European Continent was significantly slowed by the need to prepare for the Euro. The programming required for that initiative was substantial, and clearly diverted resources from the Y2K effort, although some firms claimed to be doing both kinds of work simultaneously. Europe appears to have managed the transition to the Euro with a manageable number of problems. This is a favorable indicator, since it reflects well on the status of European information technology efforts and means resources don’t have to be diverted to cleaning up from that transition. The Gartner Group does suggest that some European countries, perhaps most notably Germany, are well behind the U.S.

I’m even less knowledgeable about Asia, Africa, and Latin America, but it’s fairly obvious that Asia, in particular, has had its attention diverted. Reports on Japanese preparedness are very mixed, but improving. Clearly Japan started late, and its financial institutions in particular have numerous other problems to worry about. On the other hand, it’s been suggested that Japan is catching up rapidly and that the Japanese practice of firms buying all of their systems from a single vendor makes system remediation simpler.

The biggest advantage that the Third World has is that much of its business doesn’t rely on computers. Beyond that fact, there is very little room for positive comment.

The bottom line is that much of the world is likely to face major problems. Harder to discern is the impact that this will have on the U.S. In virtually every country, the consensus seems to be that the banking system is ahead of the rest of the world, but banking systems require that infrastructure like telecommunications also be ready.

In the Federal Reserve, as in other well-managed organizations, we’re through remediating systems, although we do have a few vendor products where we still have to receive the Y2K compliant version, although none of these will be required for us to operate our critical systems. Rather we are spending our time doing contingency planning, event management planning, that is planning for our management of the period when we are actually rolling over to the new year, and communicating with our customers and the public.

While the status of individual organizations, and thus what needs to be done, obviously varies, I’d like to suggest a few things that should be on everyone’s list. I would assume that these are things that you as information technology auditors would want to be looking at.

• Finish implementing Y2K compliant systems in production. If this is not going to be done before the end of September, you should not assume that they will be completed this year, and should have well conceived and tested contingency plans in place in the event they are not. If critical systems are in this category, it’s time to push the panic button. Make sure that senior management is aware of the risks the organization is incurring.
• Make sure that any changes that have been implemented after initial Y2K certification have been thoroughly retested.
• If there are noncritical applications that will be or may be delayed beyond yearend, review them to ensure that they are really noncritical—that is that the primary missions of the organizations may continue without disruption without these applications in use. My own sense is that in most organizations the tendency has been to err on the side of classifying too many applications as "critical," but there is always the possibility that a hard pressed manager has erred in the other direction.
• Prepare, and to the extent possible, test contingency plans for internal and external problems that could occur with the advent of the new year. It’s essential that everyone who’s supposed to do something as part of the implementation of the plan know what it is. Members of senior management frequently are ignored in the contingency planning process—a real problem when they show up looking for something to do.
• Develop an "event management" plan. Plan for all the things that will need to be done at the time of the rollover to the new year. Such steps as "health checks" of computer and building systems, last minute testing of systems between the time the calendar turns and business begins, and communicating with employees, customers, other units of your business, and your customers need to be included. It’s vital that you know who will be doing what when during this period. (I’m afraid a lot of us will be watching bowl games from our communication centers this year.)
• Communicate your Y2K status to employees, customers and the general public. Remember that producing a piece of printed material won’t result in communication unless someone reads it and understands it.
• Review information security controls, and make sure that no one is planning on relaxing them during the Year 2000 rollover period in order to facilitate fixing problems. Since there will be a natural inclination to initially believe systems anomalies are Y2K related, there is a consensus among information security professionals that organizations may be particularly vulnerable to hackers during this period, and there is wide spread speculation that hackers will try and exploit this vulnerability.

This is a very long, but still incomplete list. Information technology auditors may add value to the organizations they audit if they check to see if these steps are being performed.

Let’s me now turn briefly to the likely impact of the Y2K issue on the U. S. Economy. My current job does not mean that I’ve totally forgotten economics. In particular, the widely disseminated view that we are likely to have a recession caused by the year 2000 problem has served to stimulate me to think about the implications of Y2K for the macro economy. One of the great things about this kind of analysis is that we have absolutely no historical experience to go on¾ data on the impact of the rollover to the year 1,000 are too sparse to do any decent modeling of the impact of the rollover to the year 2000. Therefore, since my armchair is as good as any one else’s, I’m willing to take the topic on.

One of the things that I learned back when it was part of my job is what I still take to be the cardinal rule of economic forecasting¾ "Give them a number or give them a date, but don’t ever give them both." The problem that I had back then was having the number right¾ for example, being right on substantial declines in inflation¾ but being ten or fifteen years off on the date. With Y2K, we know the date precisely, but the number is a bit more of a problem. My current judgment is that Y2K is likely to impact the timing of certain types of economic activity, but unlikely to cause a recession.

In thinking about the economy, let’s start with what we know with a fair amount of certainty. One near certainty is that our Year 2000 work is probably putting something of a damper on the economy’s productivity growth. While this suggestion is hard to accept, given the very strong productivity growth that we’re currently seeing, we know that many of the dollars being spent on the Y2K problem are not adding anything to the economy’s productive capacity, but are rather simply allowing us to maintain it in the new century. It thus seems highly probable that we should, other things equal, see additional growth in productivity next year as programmers return to more productive work.

Another near certainty is that we’re going to see a certain amount of inventory building in the second half of this year, and that we’re likely to see these inventories drawn down in the first part of 2000. For example, the Federal Reserve has announced that we’re going to have extra money printed this year, in order to be ready in the event that there is an unusually strong demand for currency. As a result, less money than normal will need to be printed in 2000, as the 1999 order will be able to fill some of the normal 2000 needs.

I expect to see similar activity in the private sector. Every electric utility I know of has stated that its coal pile will be larger than normal at the end of 1999. Presumably, they will proceed to shrink those coal piles in 2000. Similarly, manufacturing operation are trying to be a little less dependent on just-in-time deliveries of components than has been the case in recent years. These inventory-building operations are likely to lead to a stronger fourth quarter than would otherwise exist, and probably to a certain amount of weakness in the first quarter of 2000.

Note, however, that we’re going to see offsetting effects in the information technology industries. In the Federal Reserve System, and in other well-managed operations, we’re going to make very few changes in our automated systems in the latter part of this year. Once we get all of our Year 2000 ready systems in production, we really don’t want to make changes that might inadvertently create additional Year 2000 problems. If we do make changes, we’re going to have to thoroughly retest the new or modified systems.

The impact of these information technology moratoriums is likely to be significant. Sales of both computer hardware and software are expected to be very weak in the latter part of this year, as firms wish to avoid changes in their systems during the latter part of 1999—a practice that I would certainly endorse. We can, however, expect to see an acceleration of information technology spending by the second quarter of next year from this reduced level.

It’s conceivable that the positive impact of inventory building and the negative impact of reduced computer spending might be roughly offsetting in their impact on the aggregate economy, but it’s really impossible to say. Even if they are, there will almost certainly be impacts on individual firms, industries, and workers. We aren’t going to see workers moving from Silicon Valley where they make computers to Gillette, Wyoming to mine coal. At any rate, it’s extremely unlikely that this sort of short-term time shifting of expenditures will have a major long run impact on the course of the economy.

The most uncertain risks that we face, however, are probably from abroad. Major Y2k problems abroad could conceivably create problems for some of our export industries, as well as industries dependent on imports. Of course, we’ll also have to be prepared to assure that any Y2K-created financial problems do not disrupt U.S. markets, but the people I talk to who are working on international financial markets are increasingly confident that we will be able to do so.

It may be that our relatively better preparedness will provide major opportunities for U.S. firms operating abroad. While these firms are obviously dependent on local infrastructure, it appears that their preparedness mirrors that of their parents. They may well be much better prepared to serve world markets, and as a result gain relative to foreign competitors.

If Y2K problems abroad were to lead to a recession, and I’d like to stress that I think that at this point a recession is not likely to occur, it might well be very short lived. I don’t think the oil embargo of the 1970’s, which has been suggested as a comparable situation, is a good analogy. That episode was clearly exacerbated by ill-conceived government controls, something that we wouldn’t expect to see in this situation. It seems to me that it would be better to think of Y2K as being more akin to the damage caused by a natural disaster, or in a worst case scenario, a war. Neither automatically leads to a major recession.

Around the world, we are spending hundreds of billions of dollars fixing the Y2K problem. I’m hopeful that a lasting result of this process will be improved management of automated systems. Let me suggest a few of the things that we should have learned as a result of this process, as well as a couple of questions that it has created.

The process of preparing for Y2K has provided great rewards to organizations who have done a good job of managing their software and very heavy penalties to those with a history of sloppy management. I’ve spent my entire management career in a conservative organization with a tradition of good controls, so I was shocked when I learned the extent to which some companies were being hampered by a tradition of poor software management. A number of firms discovered that they were running object code with no source code, or even worse, different source code than what was in production. The absence of source code obviously made remediation difficult, if not impossible.

While no piece of software ever seems to be well enough documented to the next person who has to work on it, some organizations have a management structure that provides for better documentation than do others. This has clearly been a big factor in the cost of remediation.

In general, deferring software maintenance has the same kind of consequences as does deferring building maintenance—higher costs when you finally get to it. Y2K has forced us to get to it.

All of this is to say that if organizations had all maintained their systems the way their auditors tell them to, we’d have been a lot better off.

Most organizations have a certain amount of tension between information technology management and business unit management concerning the appropriate degree of standardization of hardware and software in the organization. IT management sees the extent to which it could do it’s job easier and cheaper with a high degree of standardization, while business units focus on their own flexibility and costs. In general, the degree of standardization that exists in an organization has translated directly into the cost of the Y2K project. Those organizations that have applications that are unknown to central IT management are in danger of discovering next January that some critical process has been disrupted by a noncompliant system that was unknown to the Y2K project staff. In general, the Federal Reserve has a high degree of standardization, but where we do not—for example in our multiple E Mail systems, we’ve had to go through far more elaborate processes to make sure we were ready.

Overall, I’m cautiously optimistic that our Y2K experience may lead to better management of automated systems. As a result of the process, we have a base of information on our systems that is better than we have ever had before. And I think we’ve learned, hopefully permanently, the benefits of managing software the way the textbooks and the auditors say we should.

Complaining about lawyers is a long and honored tradition. You probably all know that Shakespeare said "First, kill all the lawyers," although you may belong to the school that thinks that he only said it because they didn’t have accountants back then. I think that a lot of what we blame on lawyers is actually a result of the litigious nature of the American public. There is, however, absolutely no question that lawyers have significantly hindered the Y2K efforts of all organizations.

One of the things that all of us required was information on the status of our vendors and their products. Unfortunately, most organizations were simultaneously asking for lots of information and refusing to provide much information on their own products because their lawyers were afraid it would create liability. While this may have been good legal advice, as well as satisfying the lawyers’ natural inclination to not say anything, in the aggregate this advice significantly increased the societal risk that we would incur major Y2K problems.

Trial lawyers argue that nothing should be done to reduce Y2K liability because the possibility that a firm will be sued gives it an incentive to fix its products and thus improves Y2K preparedness. This may be a defensible position, but no case can be made that withholding information on the status of products improves Y2K preparedness.

For example, in the Federal Reserve, we had an urgent need to understand the Y2K status of our telecommunication vendors, but for a significant period of time, they refused to provide us with much information. Eventually, pressure from the FCC, which was largely generated by large banks and the Federal Reserve, and Federal legislation that made it clear that information provided in good faith would not create liability, loosened the information strings.

In the interest of fairness, I don’t think I can totally exclude your profession either. People I talk to who are managing Year 2000 projects are in fundamental agreement that their auditors missed this issue. Whether we’re talking about internal auditors, or external ones, the norm was for auditors to be rather late in picking up on the Y2K issue. In the organizations I’m familiar with, the Y2K project was well underway before the auditors understood its importance. I’m not an auditor, but I think that you should be pondering the question, which may go well beyond the Y2K issue, as to why your profession is better at spoting small problems than big ones.

I know that the Federal Reserve will be as ready for the year 2000 as it’s possible for us to get, and I’m also extremely confident about Banking and the rest of the financial system. My reading on the U.S. economy in general is that we’re doing an excellent job of preparing for this unprecedented event.

Economic forecasting¾ at least by those who do it for a living¾ combines art and science. Trying to forecast the impact of the transition to a new century clearly involves more than the usual amount of art. The task is complicated by the fact that the more the prophets of major problems gain public attention, the more likely it is that organizations will perform heroic feats to prove them wrong. The extreme manifestation of this paradox would be if we threw a millennium party and nothing went wrong. I’m not ready to predict such an eventuality, but I think it’s a lot more likely than that we’ll have major Y2K disruptions in the United States.

I’m expecting to see that a lasting benefit of the Y2K experience will be better management of our automated systems than has been the case in the past. You can play a valuable role by expecting this kind of management as you audit those of us blessed with your presence.