Table of Contents

At midnight on Friday, 31 December 1999, the built in clocks in computers will roll over to 1 January 2000. At least, this is what should happen. Instead, there will be many cases where the date will not roll over correctly. Som e personal computers will report a date of Friday, 4 January 1980. Other computers may report Sunday, 1 January 1900.

As a consequence, an unprecedented number of computer systems will fail (or "crash" as programmers call it), calculate incorrect results, overwrite backup data, cause licences to expire and otherwise cause innumerable unpredictable outcomes.< /P>

Some have likened the effects of the "millennium bug", or Year 2000 Software Problem, to an atomic holocaust, but in all likelihood, it will be more like a world-wide termite plague.

The Year 2000 Software Problem is likely to be the greatest challenge ever faced by the IT (Information Technology) industry. In fact, it is quite likely to be the greatest challenge ever faced by the world economy. Already, the facts are emerging that indicate it to be the largest project ever faced by mankind.

Whilst the nature of the problem is simple to the point of triviality, its size, scope, solution and the immovability of the project end date are likely to show that it will be one of the most complex projects ever undertaken by mankind.

In this paper, we will discuss the nature, size and scope of the problem. We will then discuss the process that is required to fix the problem and conclude with a summary of the critical success factors associated with success.

Because of the scope of the problem domain, simple project management techniques will not be adequate, and it will be necessary to manage the solution as programme at the organisation level, as well as at a national level.

Many calculations in computer systems involve dates. For example, to calculate the age of a person, one would subtract the birth year from this year. Then there are expiry dates (e.g. on a credit card), maturity dates (for an in surance policy), start and end dates (for medical aid membership), transaction dates (for a medical claim, an invoice, a cheque deposit), service period dates (telephone usage, electricity and water consumption), accrual periods (interest received and to pay), and so on.

In most cases, date arithmetic is used to establish the value. The problem is, many, if not most, computer systems store and process dates as a six digit value (ddmmyy) instead of an eight digit value (ddmmccyy). So, 19 May 1997 is stored as 190597, in stead of 19051997. The computer system assumes the century. Because of this, strange things are likely to happen over midnight on 31 December 1999. Unless the computer systems have been fixed, they will simply reset to an older date.

The consequences will range from the irritating to the disastrous. For example, air conditioning in high rise buildings may not be working on Monday, 3 January 2000, because the control system will think that it is Sunday, 6 January 1980. Time delay sa fes in banks will not open (but will have been open on the previous Sunday) for the same reason. Cheques may be rejected as stale, debit and credit interest may have been reversed and been calculated at enormous amounts, and so on.

Is this problem serious? Author and IT guru, Ed Yourdon has reported that one American airline has already taken the decision that they will not have any flights on 1 January 2000. Most financial institutions claim to have the matter well in han d, but a consultant with first hand experience with more than 35 banks and other financial services companies casts a dissenting view of the industry's preparedness. "I'm petrified, " this individual said, "If banks are doing so well, why can't they issue a bank card beyond 1999?" Stock has already been destroyed because computer systems had determined the stock was stale. The Gartner Group predicts that 50% of organisations will not be ready in time.

Computers were not always as powerful and cheap as they are today. For example, when I entered the industry as a computer operator in 1972, my employer ran a bureau that had an IBM 360 model 30 computer. The configuration of thi s machine was 64Kbytes memory, had a card reader as input, an 1100 line per minute line printer and an online disk bank with a capacity of some 40Mbytes. For this, the company paid a monthly rental of R12,000 (in 1972 Rands! This would equate to ar ound R130,000 per month today).

By comparison, the notebook on which I am writing this note has 32Mbytes memory, 2100Mbytes disk, 650Mbytes CD-ROM, a 3 pages per minute laser printer, etc. etc. All of this cost around R20,000. If I had to lease it, it would cost around R800 per month .

The primary method for input then was by way of punched cards. Each column is used to encode one letter or digit, therefore, it is possible to read a maximum of 80 characters into the computer with each card.

Secondly, disk space, or any form of storage space was extremely expensive. In fact, it was not just expensive, the gigabytes and terabytes that are so commonplace today were just not available in those days. Even large organisations like the Old Mutua l would only have had a few hundred megabytes available.

It was therefore necessary to be very conservative in designing data storage and input. We used all sorts of techniques, like coding large data items, so that "2134" might mean "Westgate Post Office, Roodepoort". Dates are an integr al component of almost all computer systems and were thus a prime candidate for coding.

A number of different coding techniques were developed. For example,

• a six-digit date (where 1 January, 1997 is stored as 010197 – the format may be DDMMYY, MMDDYY or YYMMDD);
• the ordinal date where the sequential day number in a year is stored (where 1 January, 1997 is stored as 97001 – the format is YYDDD); or
• a real number which is the number of days from a base date (in the case of many PC’s this base date is 4 January 1980 – the so-called birthday of the PC). It was reported in Computerworld last year that the GPS satellites would reset to their base dat es 132 days before the end of the millennium on 22 August 1999. These dates work similar to the odometer in your car – when you reach the maximum mileage that the odometer can record, it simply resets to 0.

There are many more formats, but these are probably the most common and are sufficient to illustrate the problem.

This approach, which I call "punch card mentality", appears to have become ingrained and many systems which are being developed today, even after so much has been said about the problem, are still incorporating some of the flawed formats desc ribed above. Not only that, it is my contention that you will find system design courses which still teach the use of these formats.

Regrettably, government-funded bodies, such as the SABS and ISO, which produce standards or recommended practices on this and similar matters, are largely ignored. The SABS does have such a recommended practice: ARP 010-1989. The date of the ARP may appear to be fairly recent. To place it in perspective, note the introduction to the document: "Although ISO Standards and Recommendations in this field have been available since 1971, …". This ARP merely supersedes much older recommendatio ns.

In fact, even today, one will find senior IT staffers who will argue about whether standards have an value at all! The mind boggles.

The Carnegie-Mellon University’s Software Engineering Institute (SEI) has, with US government funding, developed a framework called the "capability maturity model" (CMM), which describes 5 levels of software process maturity. Its research has shown that some 85% of US software "shops" are at level 2 or lower.

Two quotations from SEI aptly describe the problem. Regarding level 1, the SEI says "... the best test is to observe how the organisation behaves in a crisis. If it abandons established procedures and reverts to merely coding and testing, it is likely to be at the Initial Process level. After all, if the techniques and methods are appropriate, they must be used in a crisis, and if they are not appropriate, they should not be used at all."

Regarding level 2, the SEI says "This is such an enormous advance over the Initial Process that the people tend to believe that they have mastered the software problem. They do not realise that their strength stems from prior experience at similar work."

In some ways, the question of why no heed is paid to standards and recommendations is like the issue of morality. Just as one cannot bring about high standards of morality through legislation, so software developers need to be convinced about the r equirement for "built-in" quality before this will automatically take place. Even in organisations that have a "quality culture", quality is a matter of review, rather than a pro-active process.

I have been involved in the business of improving the quality of software for the last decade and I would be surprised if there a handful of organisations in South Africa that actively review and modify their processes to improve the quality of new dev elopment as a matter of course.

Quality in IT is generally a function of the innate ability of the people doing the work. Remove or change the people, and quality will either go up or down, or remain static. Not a happy situation, and South Africa is by no means unique.

Notice the following rather damning statement from a booklet published by the US General Accounting Office "With only a few activities within federal agencies operating above level 1 on the Software Engineering Institute’s Capability Maturity M odel, most information resource management organisations lack the basic policies, tools, and practices necessary to successfully manage a large-scale year-2000 program."

A few decades ago, manufacturing was in a similar state. When manufacturers customers eventually cried "enough!", initiatives were started which ultimately resulted in the ISO 9000 standards. Is it possible that the IT industry is about to re ceive a similar wake-up call?

Most of the focus in articles has been on the cost of correcting the date faults. Then there is typically a statement like "there are only … days to go".

From the next section, it should be clear that the problem is much wider than just software, but I shall restrict myself to the software problem since that is the area where my competence mainly lies. Secondly, there is another facet to software that I believe to be even more important than the cost, namely, the time it takes to fix faulty software.

Put simply, it’s like being told to go and find every reference to a date in every publication in the UNISA library (one of the largest in Africa), verify that ambiguity of the date format will not cause a problem, and if it will, correct it. And even this analogy is inadequate, since computer software must still be tested, after the changes have been made.

Hardware is relatively easy to fix: one simply replaces it. The time involved is fairly limited. However, if for example, it is necessary to change operating systems as a consequence (i.e. the software), there may be retraining involved and other softw are may have to be replaced as well, which might result in retraining, again, in addition to resulting business process changes.

Secondly, hardware fault fixing can typically be done in parallel. It is possible to identify the fault once, manufacture a replacement for the offending part, ship this part to all users of the product and have them, or qualified persons, replace the part.

Software fault fixing, on the other hand, is typically a sequential process which involves finding the offending components, determining how they may be fixed, making changes and then testing that the changes were successful in solving the problem.

In itself, this may not seem to be a major problem. Until one realises that most software is non-standard. Most software in use today was either custom written, or in cases of mainframe commercial software, may have been subjected to extensive modifica tion, adaptation or customisation. So for instance, the purchase price of the "vanilla package" often represents less than half of the cost of installation.

And then, bug fixing is a hit-and-miss activity. Jones reports that for every 100 bugs fixed, 7 new ones are typically injected into the "fixed" application.

Add to this the fact that, many large organisations have core applications that are more than 10 years old. In fact, some of the most critical applications in these organisations may be between 15 and 20 years old. What’s more, they were develop ed during a time when conventional wisdom said that software applications should be created to last only 3 to 5 years! Remember, this was the time when arbitrary "built in obsolescence" had not yet been shown conclusively to be as destructive as it eventually was.

It has been reported that the cost to the global economy will be between $300bn - $600bn (Gartner Group). Alternatively, £500 - £1,000 for each employee in the organisation (British Computer Society). British Telecom has reportedly budgeted £100m towar ds dealing with the problem.

On 30 July 1996 the Chairman of the Subcommittee on Government Management, Information and Technology, US Congress, released findings of a survey which the subcommittee had conducted. The Chairman in his report stated, "Even with this information, an outline forms, which portrays a Federal government unable to meet the challenges of the 21^st century because of a lack of awareness and preparedness."

"NASA, one of the most innovative, advanced and computer dependent agencies in the Federal government, has not prepared a plan to solve the problem and does not anticipate having a plan completed until March 1997 – this leaves less than a year to inventory, and fix systems."

A half-year later, there appears to be just as much confusion as to what the real status is and what it will cost, with estimated ranging from a low (!) of $2,3bn to as much as $30bn for the Federal government.

One of the most respected IT industry analysts is Capers Jones. His company has been collecting data for more than 10 years and has assembled information on more than 6000 projects ranging from tiny to enormous. Amongst other things, he has published p roductivity levels for a variety of software activities. His company also conducts international IT surveys.

As the reader may be aware, it is very difficult to find a universal measure for software (for example, we may measure assets in terms of value, raw material in terms of mass, liquid in terms of litres, and so on). In the past, lines of code was the mo st common measure used, but this measure is flawed at best, since the type of language and programmer style greatly influences the number of lines produced, and it gives no indication of value.

More recently, a measure called function points has been developed as an attempt to resolve the difficulties associated with lines of code and to reflect the value of software to its owner. Whilst this measure is not perfect, it is certainly the best w e, as an industry, have come up with to date.

For the purposes of comparison, one function point equates roughly to 100 lines of Cobol code (or 10 lines of a Lotus 123 macro). A typical commercial application would be around 1,000 function points. The Windows 95 operating system is approximately 5 0,000 function points. The core applications of a medium sized South African company would be around 100,000 - 200,000 function points.

Jones’ estimates the portfolio of South African applications to be around 56m function points (compare to 1,5bn for the USA and 7+bn world-wide). Based on an impact rate of 9,5% (which Jones agrees is questionable, but a reasonable starting place), Jon es extrapolates the total effort required to repair Y2000 non-compliant software to be around 300,000 person months. (This is approximately 3.5% of the US effort.)

Jones estimated a South African complement of 75,000 IT professionals and a burdened annual salary of $7,600 per person. Local figures are not easy to obtain, but they indicate that the numbers are not way out. Based on these figures, Jones has estimat ed a cost to the economy of around $2,5bn. This then was the basis of a cost estimate of between R4bn to R10bn, which has been quoted in the press.

Where possible, I have attempted to verify Jones’ figures with other statistics, some my own, others from local bodies. Whilst there is the possibility for fairly large margins of error, it is my opinion that Jones’ approach is conservative, if anythin g.

Jones’ analysis has led him to conclude further that there was a real possibility that litigation, because of non-compliance when this had been promised or a lack of "due diligence", could result in the failure of many organisations which cou ld otherwise have survive. Jones has forecast that US litigation could exceed $100bn, forcing the closure of many otherwise sound organisations.

Ultimately, Jones predicts the real possibility that one or two Fortune 500 companies and between 1,500 and 2,100 medium sized US companies could fail, with the possibility of millions joining the ranks of the unemployed. "This is a significant nu mber and it is an open question as to whether the impact of the year 2000 problem is severe enough to trigger a recession."

Since no sector of the economy is exempt, these costs will be borne by ever citizen. Some states in the USA have already introduced special taxes to cover the correction costs. One US insurance company has reported that they will be spending 4 - 5c per share in 1997 on Y2000 work.

In the case of the European community, the size of the problem is approximately 90% of the US. However, the reader is probably aware that the EU has an additional deadline, in that all EU countries must be ready for a common currency in 1999. This is c urrently distracting EU companies and governments from the threats of the Y2000 problem.

This is changing and we have started feeling some of the effects: the rate at which foreign companies are recruiting SA IT professionals has been stepped up (one is offering between R6,000 to R15,000 per week for assignments in the UK). Whilst some of the offerings are questionable, we have knowledge of people being offered £1,000 per week.

Then there is the problem of how technology affects the economy. The following quotation from MIT Technology Review does not relate to a failure as a consequence of Y2000 non-compliance, but the fact is that the reason for the failure to supply is irre levant – it could just as easily have been a computer failure which resulted in disruption of supplies.

"Last March, when workers at two Dayton, Ohio, brake factories went on strike, the ensuing paralysis of General Motors plants across North America drove home a point that Stanley Gershwin has been trying to make for years: random disruptions, even minor ones, can propagate across a manufacturing system, causing massive headaches. The strike at the brake plants - in protest against GM’s practice of buying from non-union sources - caused the automaker’s deliberately lean inventories of brakes to dr y up quickly. More than 177,000 GM workers were laid off. Parts suppliers, idled by the shutdowns, laid off tens of thousands more. By the end of the 16-day strike, economists were putting the cost to US productivity at $5-7 billion." MIT Technol ogy Review, May 1996, p14.

This example is taken from the manufacturing industry, but what if a significant number of small clients of a bank should fail, because they cannot clear their debtors’ books? Or if a medical aid administrator can’t pay doctors and hospitals? Or if loc al authorities cannot collect water and electricity accounts because the statements are significantly wrong? What if all of these occur at the same time?

On 10 November 1997, I returned home from attending a Year 2000 Conference in Toronto, Canada. That afternoon, we experienced the worst hailstorm on the West Rand (where I live) in thirty years (as long as I have been living in the area). Half a year l ater, glaziers and handy men have still not repaired the damage in all the houses around us (including my own).

In fact, it was more than three weeks before they came to fix the broken tiles on the roof. As a consequence, rain over the intervening period caused additional damage to ceilings in my home. The repair man was actually from a town which is more than 1 50km away!

There just weren’t enough handy men to go around – after all, most of them were busy with routine work anyway.

The Year 2000 Problem is not that different. Almost all available programming personnel are tied up in "routine" work. Organisations that were not able to fix all the problems in their software will find that they will just have to wait until programmers can "get around to them".

In the mean time, the residual damage will build up.

As mentioned above, whilst older application systems are most at risk, the problem is much more pervasive than first seems. Ultimately, all of the cases where the date cannot be handled effectively will have to be corrected, but not all are of equal priority.

The classes of software that are affected include:

As one can see from the above list, almost every type of technology is potentially affected. The diversity of the scope suggests that it will not be possible to have one project to address all the different aspects of the scope. Neither ca n one apply one technique to all, or a single skill type.

Most organisations will need to establish a number of parallel projects. In most organisations, skills will have to be drawn from business as well as technical areas, and in all likelihood, there will be a need for outside resources as we ll. We are thus looking at programme management at a level that few organisations have ever successfully accomplished.

Since the problem is not limited to organisations but to the economy as a whole, this is a case of hanging together, or we will all hang separately!

Our major concern at this time is the contradictions that are evident in surveys which are being conducted with regards to Y2000 readiness which indicate that the matter is not being taken seriously enough.

For example, according to a South African survey of 200 respondents conducted late last year, 84% believed they are "fully aware of the problem", yet only 38% had someone at board level responsible for monitoring the issue, and only 39% had I T teams focused on the Y2000. This last figure is interesting if the reader considers that 72% of MD’s said their companies have identified the risks to the business. Only 20% had a project manager who devoted more than 90% of his time to the problem. 52% of IT managers felt that most of their older systems would fail, yet only 19% included the cost of corrections in their annual budgets.

The same organisation will at once report having the matter well under control, that they are spending R300m to fix the problem and are planning to have completed testing by the middle of 1998. Then, another officer of the same organisation will claim that they do not have a Y2000 problem, since the matter was resolved ten years ago, and every application implemented since then is compliant. The first statement was made in a public television programme, the second in response to the survey mentioned ab ove. Who does one believe? Considering that the organisation concerned is providing an essential service, this is very worrying.

The Computer Society and PMI Y2000 SIG is at present conducting a low-key survey. Whilst there are not sufficient responses in as yet to be a representative sample, what we have received indicate that the situation has not really changed. An interestin g opinion that is being expressed is that the problem is similar to the changeover to VAT (from GST). The feeling is that a lot of noise is being made about problems that will ultimately turn into nothing beyond a hiccup in the admittedly heavy maintenanc e workload.

I participated in the changeover to VAT and can say with confidence that there are many factors that make a comparison untenable:

A current international survey indicates that 30% of respondents have not yet started to do an impact assessment, only 18% have completed the assessment. In spite if this low figure, 63% felt that "executive management is aware of the real risks".

Hard data is still very sketchy in South Africa at present. In other countries, almost without exception, the pattern is emerging that the problem is almost always larger than was first thought.

The IT "brain drain" bears another mention. According to data assembled from the IT User Council and recruiting organisations, it appears that we are losing roughly 2,000 people each year. There are however only around 500 entering the indust ry each year. This leaves a shortfall of around 1,500 per annum. They are not being reflected in official statistics because most of the departures are on contracts and thus theoretically they are not emigrants. The problem is that they do not come back.< /P>

Crime is most often given as the reason for the move overseas. I must tell you that I think the motivation is a lot more basic than that – money. By all accounts, this will become worse.

This paper has been concentrating mainly on the problem and I feel I should spend some time summarising the process involved in the solution. The methodology is generic and every organi sation will have to pass through similar stages.

Underpinning the process is effective project management. It is in this area where the IT industry has been the least successful. After many years, it is still commonplace for the average project to be completed late and over budget, with a reduced sco pe and more often than not appalling quality.

Compound this problem with the need for not just "simple" project management, but the average institution will require programme management skills. This is a subject which hardly anyone in the IT industry even understands the basics of . Secondly, it should be clear from what I have written so far, that risk management is not just crucial, but critical to success, since most institutions will need to take risks if they are to finish on time.

The process is a typical software maintenance process, with the following distinctives:

• The Discovery involves making an inventory of every component that the organisation owns, that might be affected by dates (for example, in the case of a local authority, this would include all the traffic lights, the water and electricity suppl y mechanism, as well as the obvious components like the collections software application). This is not a trivial task. For example, Bank Boston on the basis of work already done, discovered that they would require 240 weeks to complete the inventory. Sinc e this was obviously unacceptable, they had to refine their approach to bring down the effort from 2 weeks per application to 2 days. They have shown that this is possible, but it takes time to get to that point.
  
  If one adds this time to the typical nine months that it seems to take from when an institution first starts discussing the problem until the discovery is fully underway, I think one starts to see the time problem which we have.
  
  A matter of concern is the time left. Many organisations may no longer have the time for luxury of a comprehensive inventory. What they may have to do is to do a top down risk analysis and manage the programme with the risk analysis as the basis.
  
  Questions which would be asked include: "What functions would prevent the enterprise from continuing to be a going concern if they are not fixed?" "What functions can we live without?" "What functions can be (relatively) easily be replaced, or supplemented by contingency procedures?"

• During the Strategy Phase, major risk assessment must take place and a macro plan must be created. During this phase fail-safe dates must be established. You are probably aware of the concept of project milestones. Here we are dealing wi th more than milestones. These are dates by when certain objectives must have been achieved, and if they have not, then alternative back-up plans must be implemented – quite possibly in parallel with the original plan. (Obviously at potentially enormous c ost to the institution concerned.)

• From this point onwards, it is quite likely that many parallel projects will get underway. This is quite likely to place a tremendous strain on resources and management – which is why programme management is a requirement. Each of the projects will ne ed to go through an Assessment Phase where every component is evaluated to establish whether changes are required, as well as to create a design for the changes. After that, the changes must be effected. These two phases can be significantly suppor ted by tools – to find date instances and to assist with making the changes. This work can be done off-site, for example by a "software factory".

• Then follows one of the most difficult phases: Verification and Validation. Individual systems need to be tested and they need to be tested together (integration testing). It is unlikely that tools would be able to assist a great deal, nor can this testing be done off-site. This means that a great strain will be placed on the infrastructure and resources of the institution.

• Finally, the changes will need to transferred to production which may involve changing procedures, documentation, staff training and so on. These tasks make up the Implementation.

We have shown the process as "up the ladder and down again" because of the requirement to do verification and validation. Conversion must be validated against the assessment. Testing, or the major verification and validation exercise must be validated against the strategy, to ensure that the strategy was correct and to adapt the strategy to take account of lessons learned. Finally, the implementation must be checked against the outputs of the discovery to ensure that nothing critical is misse d.

It is useful to classify the objects considered. This is especially true because of the great number of objects that need to be managed. The table below describes some of the classification schemes that could be used.

The cornerstone is quality, since this is one case where there won’t be time to do it again. The "Best Practices" summarised above should be considered very seriously by any organisation involved in software development or mainte nance.

A highly recommended book is "Rapid Development: Taming Wild Software Schedules" by Steve McConnell (Microsoft Press). McConnell summarises many of the best ideas that have been put forward by the "alte männer" of the IT indust ry.

The expensing of costs will be approximately as follows:

Discovery: 10% to 50% of total costs

Fixing: 15% to 30%

Testing: 10% to 30%

Regression testing the application portfolio: 20% to 50%

In addition to this, project management costs could be as much as 25% on top of the total costs.

One of the difficulties Y2000 project managers face is being able to estimate the amount of effort and time. There just isn't sufficient empirical data around. The matter is further complicated by the fact that the data that is being reported is not no rmalised (i.e. it is difficult to compare because one is often dealing with apples and pears). Galileo said that one could not manage the invisible. One needs to first make the area being managed tangible. We would like to recommend some classification sc hemes which are being developed with a view to defining parameters to the problem as well ahs being able to collect normalised data which may be used in programme / project planning and tracking.

A useful way of tracking progress and costs is the "earned value" technique that has been in use by non-IT project managers for some time now.

The costs are frightening. They are causing a state of denial amongst many managers. Institutions should then not believe the figures, but at least do a short high level assessment to establish for them that they do not have a problem. (I believe that the contrary will become evident.)

This is the very least they should do.

The main thing is this should be done without delay.

However, of greater concern is the issue of time. Capers Jones has proposed the percentage of Y2000 repairs that will be completed based on start year and the use or non-use of automated search procedures. Note that start year implies year in which rep air begins, not when investigation into the problem begins! Secondly, the tools are already at a premium with the norm being around $50,000 per module and a typical institution would require 3 – 5 modules.

The die is already cast.

Government is one of the sectors in the economy that is most at risk. We may not delay action. Nor is the risk limited to government. Every sector of the economy is almost equally affected and at risk, including NGO’s, religious institutions, charities , etc.

Unfortunately, government appears to be dragging its heels: a tender seeking to compile a panel of IT expertise closed on 28 February 1997, but was only "awarded" at the end of April / beginning of May 1997. Whilst we are aware of the difficulties whic h government is experiencing at this time and we do not wish to appear unnecessarily critical, we would like to raise it as a concern.

If government fails to become Y2000 compliant in time, there will be no winners, only losers. There can be no talk of "gaining competitive advantage, or any other modish concept.

Since the problem is across the board and in essence, very simple, much energy can be lost in developing "unique" or "special" solutions. It would be far better if common management issues could be centralised and made available to all.

Some of these common management issues include:

National awareness is still a major problem. Even if the implications of the Y2000 problem on the economy are only a fraction of what has been estimated, they still represent one of the greatest challenges South Africa has faced. Th e media does not reflect this. Most reporting is limited to the technical press, and if it does make it into the business press, it is limited to the technology section.

We believe that it is only when major political and business leaders start making consistent and regular public statements with regards to the problem, that this situation will change. We need to change the perception that this is an "interesting probl em which affects computer systems". Rather, it is an economic problem that could affect every citizen of the country, if it is not properly dealt with.

The Computer Society of SA and Project Management Institute of SA have launched a joint SIG (Special Interest Group) to address the Y2000 problem. Whilst there is a great deal of interest, the current members are mainly from a technical background. The re is a need to raise the level into the "business".

The objectives of the SIG are:

In closing, I would like to repeat the good advice given by the London Financial Times.

The Y2000 Software Problem will not go away, neither can the end date be delayed. If action is not taken immediately, the result will be uncontrolled and unmanaged activity. Organisations will find themselves fixing things that don't need to be fixed and missing critical issues that must be fixed.

The end result will be that all of us are losers. There will be no winners.

Our appeal is not that organisations wheel in 200 consultants, or buy gee-whiz tools, or replace all their applications with packages. We ask merely that every organisation do a high level assessment of the potential problem. If it turns out that the o rganisation has not Y2000 software problem, marvellous!

The chances are, though, that this will not be what it will find. What then?

Like the Comrades Marathon, it will only be those who start in time, and who pace themselves effectively, who will finish before the last gun is fired.

Ignore the problem at your peril. Unlike the Comrades Marathon, it won’t be a gun that is fired if you don’t make it. It may be you.

A number of organisations have emerged to focus specifically on the Y2000 problem. In addition, most IT consulting firms and software houses have extended their services to address the Y2000 problem specifically.

Visit the Y2000 SIG homepage (see below) to obtain a comprehensive listing of organisations that can assist with dealing with the Y2000 software problem.

If you do not have access to e-mail, you are welcome to contact the author on the number given above or at fax (11) 807-3249.

ICL. Year 2000 Guide. Overview of the problem, together with a generic methodology. Discussion of implications for ICL products. Available from ICL.

IBM. The Year 2000 and 2-Digit Dates: A Guide for Planning and Implementation. One of the most comprehensive guides available for free. Can be downloaded from IBM’s home page. Contains the most comprehensive list of IBM products.

Aranoff, Howard & Graham, Stanley. A Testing-Centric Approach to Year 2000 Project Management. 1997. Discussion of testing approaches.

US Airforce. Best Practices. Year 2000 methodology.

Martin, Robert. Dealing with Dates: Solutions for the Year 2000. IEEE Computer, March 1997.

Ragland, Bryce. The Year 2000 Problem Solver: A Five Step Disaster Prevention Plan. McGraw-Hill. 1997.

Ulrich, William, & Hayes, Ian. The Year 2000 Software Crisis: Challenge of the Century. Yourdon Press. 1997.

McConnell, Steve. Code Complete: A Practical Handbook of Software Construction. Redmond: Microsoft Press, 1993.

McConnell, Steve. Rapid Development: Taming Wild Software Schedules. Redmond: Microsoft Press, 1996.

Local Sites: The CSSA / PMI Y2000 SIG is currently constructing a site which will bring together local information, as well as provide hot links to interesting overseas sites.

Provide help about the list server or about the specified list.

Note that the addresses change from time to time as webmasters re-arrange their sites.

Before downloading any "free" software, be certain that it is coming from a reputable site. There have been numerous cases of viruses being sent under the guise of "useful" software.