Table of Contents

Introduction *

Nature of the problem *

The Technical Issue *

The Origin of the Problem *

How Big is the Problem? *

The Scope of the Problem *

The Status at Present *

The Process *

Action Plan *

Start Now! *

London FT "Do's and Don'ts" *

Conclusion *

If You Need More Information *

Bibliography *

Web Sites *

International Sites *



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. Some 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.

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.

Nature of the problem

The Technical Issue

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 insurance 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, instead 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 safes 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 hand, 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.

The Origin of the Problem

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 this 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 around 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 Mutual 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 integral component of almost all computer systems and were thus a prime candidate for coding.

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

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 described 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 recommendations.

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 requirement 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 development 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 Model, 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 receive a similar wake-up call?

How Big is the Problem?

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 software 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 modification, 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 developed 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 towards 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 21st 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 productivity 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 most 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 we, 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 50,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), Jones 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 estimated 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 anything.

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 could 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 number 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 currently 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 irrelevant – 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 dry 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 Technology 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 local 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 later, 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 150km 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.

The Scope of the Problem

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:

Class of Software



Legacy applications (developed by the company or packages which were purchased but which cannot be upgraded or modified because there is no source code available or the vendor no longer supports the product.)


Will have to be replaced if affected. Must be evaluated on case by case basis.

Computer control software


Must be evaluated and fixed if necessary.

Data bases


Must be evaluated and fixed if necessary.

Non database files


As for data bases

Data input screens


Must be evaluated and fixed if necessary.

Data output screens (note that this and the next two examples may be symptomatic of incorrect date storage and processing)


Probably can be fixed at leisure, may require training to deal with unintelligible output.

Printed reports


Probably can be fixed at leisure, may require training to deal with unintelligible output.

Forms (cheques, application forms, data input forms, any document which only allows for a six digit date or has the century "19" pre-printed.)


Will have to be changed in time. The input system which processes the data on the form will probably have to be changed. May get by with training. Note that legal documents (e.g. cheques) must be reprinted.

Operating software


Must be evaluated, may require upgrade.

Programming language


Must be evaluated, may require upgrade.

Embedded software (found in chips in motor vehicles, traffic lights, satellites, VCR’s, cameras, aircraft, missiles, telephone systems, time delay safes, air-conditioning and lift systems, BIOS in PC’s, life support systems, in fact any piece of equipment which has a microprocessor.)


If there is a fault, will probably have to be replaced.

End user systems (typically developed by end users using products like Lotus 123, Excel, dBase, Access, etc.)


Must be evaluated and corrected if necessary.

Packages (SAP, BPCS, Access, Quicken, AccPac, Brilliant Accounting, MS Money, etc.)


Must identify whether the version being used is Y2000 compliant, if not, may need to upgrade to compliant version.



Must identify whether the version being used is Y2000 compliant, if not, may need to upgrade to compliant version.



See embedded software.



If the processes or procedures involve dates, they may have to be modified with changes to documentation and concomitant retraining.

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 can 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 well. 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!

The Status at Present

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 IT 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 above. 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 interesting 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 maintenance 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 industry 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.

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.


The Process

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 organisation 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 scope 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:

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 missed.

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.


Importance Index


  1. Personal: private use only
  2. Personal: used by others
  3. Used in controlled environment only (e.g. for training purposes)
  4. Simple workaround possible
  5. Limited use for enterprise decision-making (team level)
  6. Limited use for enterprise decision-making (single location)
  7. Extensive use for enterprise decision-making (cross-function)
  8. Workaround difficult and costly
  9. Major feature not working, can affect enterprise adversely
  10. Correct operation critical to normal function of enterprise

Acceptability Index


  1. Fully compliant with ISO 8601:1988
  2. Cosmetic display problem
  3. 4 digit ambiguous date format ddmmyyyy
  4. 2 digit ambiguous date format yymmdd
  5. 2 digit ambiguous date format mmddyy
  6. Garbled output (e.g. 20010229 is displayed as 20:1/02/29)
  7. Unacceptable, must be replaced (e.g. date resets to earlier date, incorrect leap year, sequencing incorrect, calculation results incorrect, etc.)


Certification Level


0 -Artefact retired (retired = replaced, discontinued, etc.)

1 - Artefact to be retired (specify date)

2a – Certified by comprehensive testing and independent audit

2b - COTS / GOTS has statement of compliance

3a – Certified by internal testing following a defined process

4 -

8 - COTS / GOTS has qualified statement of compliance

9 - Uncertified


Action Code


  1. none, compliant;
  2. none, workaround to be created (e.g. training, documentation, procedural);
  3. retire;
  4. scheduled as part of new development / package implementation
  5. replace, COTS;
  6. replace, outsource (e.g. via upgrade to latest version);
  7. replace, make;
  8. fix, source good (incl. documentation, etc.);
  9. fix, source bad (extra work required to recreate specs, test cases, etc.);
  10. fix, source unavailable (must be reverse-engineered)


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 maintenance.

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 industry.

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 normalised (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 schemes 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.


Action Plan

Start Now!

Getting ready for the Y2000 will cost what it will cost. This is inevitable.

The only control which managers have is that the earlier they start, the greater the chance is they can limit that final cost. Indian alliance partners, who have a very large Y2000 practice, have warned that whilst they are currently quoting $1 per unit of work, this is likely to rise to around $3 when the work starts in earnest and around $9 per unit next year. The reason is simple economics of supply and demand.

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 repair 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 which 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. The 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 problem 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. There is a need to raise the level into the "business".

The objectives of the SIG are:

London FT "Do's and Don'ts"

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

Do properly evaluate and manage the Year 2000 problem even though it is not necessarily an enormous problem in every computer installation.

Do make a complete inventory of all computer systems (including the hardware, operating software, networks and applications) that help to control such critical activities as security systems, telephone systems, vault-door-locks and anything else that you can think may be controlled electronically using date information.

Do think about electronic data exchanges with customers, suppliers and others - and consider how file format changes may need to be synchronised.

Do address the problem in small, manageable, prioritised chunks and accept the need for bridging technology for the interfaces with other systems.

Do consider the longer term when selecting Year 2000 software tools. Many will have use beyond this project and the broader requirements of the organisation must be considered.

Do look carefully at date inferencing as the way of providing the quickest, lowest cost solution wherever it is practicable.

Do take the opportunity to implement proper software configuration management and change management procedures, if they are not already in place. After all, if you are about to change just about every program you have, then the changes will need to be properly controlled.

Do take advantage of software tools to reduce resource requirements - particularly in the areas of code scanning and testing.

Do use the opportunity to develop good testing procedures and test packs. These will stand you in good stead for the future, especially with the introduction of the euro not far away.

Do plan to complete the Year 2000 project by the end of 1998 so that if you hit the deadline the software will be running "live" for 12 months through weekly, monthly, quarterly and annual cycles before the Year 2000 arrives. If you miss the deadline, then at least you have some degree of contingency.

Don't underestimate the size of the problem which may exist outside the environment directly controlled by IT management - particularly on PCs.

Don't think that you can outsource the whole problem: the technicians and users involved with your applications have a valuable contribution to make to your Year 2000 project - "and we do not believe that it is possible to outsource final testing," says the Bloor Group.

Don't spend too much time examining the options, choosing partners, evaluating software - the clock is ticking and the time to get the job done continues to diminish.

Don’t let the realisation of many of the additional benefits promoted by some vendors get in the way of meeting the underlying Year 2000 project objective.

Don't be talked into believing that it is just as quick to rewrite some systems as it is to correct them - unless perhaps you have lost the source code!

Don't assume that all of your IT suppliers are taking the Year 2000 problem as seriously as you are - check that your suppliers of hardware, systems software and applications packages are going to be ready as well.

Don't set the system date of your 'live machine' forward in order to test post 2000 scenarios. We have heard of many instances in which setting the date back into the twentieth century for testing purposes has confused the operating system and caused many problems.

Don't let the time-scales for the early project phases expand at the expense of testing time, as so often happens on time-sensitive projects.

Don't expect that solutions are going to get any less expensive - demand is likely to outstrip supply, putting upward pressure on the costs.

Don't sit around waiting for 'the silver bullet' - it is not coming.


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 organisation 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.


Elmar Roberg is chairman of the CSSA/PMI Y2000 SIG. He entered into the data processing industry in 1972, starting in operations, moved to programming of accounting machines and the first mini computers and progressed to project management, data processing management and consulting on mainframe and other technologies. Elmar has held positions which have included programmer, systems and business analyst, project manager, development manager, data processing manager and run a small to medium sized consulting company. Since 1989 Elmar has been practising as an independent consultant, networking with other companies in the IT industry. Elmar has been managing projects in a variety of industries for almost 20 years. He has mentored trainee project managers, developed and presented project management courses and developed techniques and methods for planning and controlling projects.

If you would like more information on dealing with the Y2000 Software Problem, you are welcome to contact Elmar on 082 651-5138, or e-mail him at .

The Y2000 SIG holds regular seminars to brief companies about the status of the problem and how to deal with it.



If You Need More Information

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.


Jones, Capers. The Global Economic Impact of the Year 2000 Software Problem. Jan97. Available from This 68 page brochure is in its 5th version. Jones is the most widely quoted metrics specialist.

US General Accounting Office. Year 2000 Computing Crisis: An Assessment Guide. Feb97. Available from This brochure includes a detailed methodology for addressing the Year 2000 problem.

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.

Sandler, Robert. The Year 2000 FAQ. Substantial document containing numerous questions and answers assembled over months. Available from (Peter de Jager’s site).

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.


Web Sites

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.

Links to local service providers will also be made available on the home page as they make themselves known to the SIG. The address of the site will be

In the mean time, Chris Anderson is providing a home page for the SIG at . Note also that Chris has made available a local discussion list. Instructions to join the list are as follows:


To send a message to the list for automatic distribution to all subscribed members of the list, send an email message to

To join the list, send an email message to, with subject blank and the body:

join y2ksasig

To leave the list, send an email message to with subject blank and the body:

leave y2ksasig

If your email address has changed since you joined, you can append your original email address:

leave y2ksasig <old-email-address>

To get a human operator about the list, send a message to

A summary of list processor commands follows:

JOIN <list-name> [<email-address>]

Join or subscribe to the list. A copy of each message sent to the list will be forwarded to the email address given.

DIGEST <list-name> [<email-address>]

Join or subscribe to the list. A single message will be sent each day containing an indexed summary of all the messages that have been sent to the list in the previous 24 hours.

LEAVE <list-name> [<email-address>]

Leave or unsubscribe from the list. If your address has changed since you joined the list, send your original email address.

LIST <list-name> [<order>]

Returns a list of all the email addresses currently on the list. These may be ordered by when they joined (default), alphabetically (ALPHA) or by domain (DOMAIN).

HELP [<list-name>]

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

DIR <list-name> [<email-address>]

If directory services are available for the list, send a listing of all the files that are currently available.

GET <list-name> <file-name> [<email-address>]

Returns the specified file. If the file is an ASCII file, it will be returned as plain text, otherwise it will be MIME encoded.

International Sites

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.







Academic Institution

Year 2000 Information Network


Academic Institution

Durham Systems Management

Excellent British site: Codename Zebra


Academic Institution

YEAR 2000 Project Article

First Published in American Programmer- Feb/1996


Academic Institution

Computer Week Article


Academic Institution

Plugin Datamation

Academic Institution

The Air Force Public Y2K Homepage



Academic Institution

The GSA Year 2000 Information Directory


Academic Institution

The State of CALIFORNIA's D.O.I.T. (Department of Information Technology)

includes RFP MSA-6006



The NASIRE State Search Home Page

Very extensive index to US Government and State Home Pages



The State of Washington's Year 2000 Home Page



Naval Information Systems Management Center's Y2k Home Page



Comlinks Magazine


IBM Year 2000-ready Products: (BIOS related)

PC Hardware Timer Setting



IBM Year 2000-ready Products: (BIOS related)

Desktop PC Hardware



IBM Year 2000-ready Products: (BIOS related)

Commercial PC Desktop hardware



The Good The Bad and the Ugly






The Borland Y2k page




The PC COBOL people




Assessment Toolkit (and Presentations)



Microsoft Year 2000 page



TTUHSC Year 2000 page



Capers Jones

Economic impacts - needs Acrobat reader


Westergaard's The Y2K (Year 2000) Time Bomb



Bozemann Legg Inc - Environmental Computer Consulting

Scanning PC source (under Windows)


TWG Products and the Millenium



Creating Relational test data for Year 2000 Applications




P/390 Solutions - for sample configurations and prices.



Audit Serve Inc.



Technology law



Yahoo Search Engine

Simple option: Type "year 2000" in the search box and search



Princeton Softech



Westergaard - The "Year 2000 Crisis" - Could it be a Hoax?



US Geological Survey

IT Acquisitions Year 2000 Compliance Update



Gartner Group

Interviewing a Year 2000 Service Provider



Information Management Resources Inc

Y2k Services


Systeme Evolutif

If you are looking for generic testing tools





The State of Pennsylvania



IBM VSE and The Year 2000



IBM VSE/ESA Homepage



Neal Laboratories

"Tooling up for the Crisis" (Presentation draft)



Yahoo Year 2000 Section



Pirkle Year 2000:




Search Engine



Washington State



Year 2000 countdown clock for OS/2 PM. (find


IBM : List of Year 2000-Ready key Program Products



Guidelines for Developers




Implications of the Year 2000 on Microsoft products




Help with Year 2000

Netscape World



The State of Pennsylvania



UNISYS: Strategic Services



Y2KInvestor: For the Financially inclined



Bill Cook's Y2K Resource Links



Information Technology Association of America (ITAA) Home Page



HourGlass 2000

comprehensive Date/Time Simulation Software



No frames version



Applied Computer Resources



Computing daylight savings time

Unix code


Computer Societies

IBM AS400 Year 2000 Homepage



ITAA Year 2000 Outlook

Weekly Magazine



ITAA*Year 2000 Certification Program



UK CSSA (Computing Services and Software Assocaiation)

Select the Year 2000 activities button



The Year 2000 Briefcase Guide

Free- Requires online registration



Millenium Times Europe



The Millenium Bomb Book



UK Weblaw (Halberstam Elias & Co - Solicitors)



Computer Law Observer.

For the Galkin article on Y2k see "current issue".



The Guide Associates 2000-Won!


VisualSoft (India)



IT2000:The National Bulletin Board for Year 2000

Under Construction


Randall de Weerd: The Year 2000 Resource


Executive Overview

UMS: University of Colorado



Year 2000 Problems in C



Oracle Rdb and the Year 2000



Year 2000 Bloopers



James Martin



Netscape World






Inter Gravissimas: If you're into Gregorian History



The Calendar Reform Page

For the Technically disposed



"Proposed criteria for Century Compliance"

the Current article at



Bill Cooks Y2k Resource



University of Texas at Austin

Project Planning



Senator Moynihan's Letter to the President

ComLinks Magazine:



IBM Announces VSE/ESA v2r2 Y2k ready to go on December 13 1996



"Tests of PC/user tools in common use"



IBM "The Year 2000 and 2-digit dates: a Guide to Planning and Implementation"

New! Sixth edition



Mcgraw Hill Beta books:

Bryce Ragland "The Year 2000 Problem - solved"



Software Technology Support Centre: Red Page


Journals and Ezines

Bill Cook's Home Page


Journals and Ezines

Bill Cook's Y2K Resource Links


Journals and Ezines

21st Century Nightmare



IBM System User Ezine



Y2K Bookshop



George Girod



DACS: New Millenium



TCSE: Technical Council on Software Engineering



NORCOM Date Routines (COBOL Tools)



A lighthearted look at Calendars



Objectives Inc


Links removed

Jerry S. Odums Year 2000 Info Page


Mainframe: Products

McCabe & Associates: Software Metrics


Mainframe: Systems

IEEE Computer Society

Mainframe: VSE

XPS: Year 2000 tools and solutions (Multilingual !)


Mainframe: VSE

CPSR (Computer Professionals for Social Responsibility)


Midrange: AS/400

Galkin: Negotiating the End of the Millenium


Millenium Madness

Tony Toews


Millenium Madness

Novell Search Engine

Search for Year 2000

Millenium Madness

Novell Search Engine

Search for Year 2000



Search Engine of Search Engines


The Calendar FAQ



CNN: The Year 2000 does not compute



Disney Puppygram



DFW D.A.M.A. Year 2000 Prep Group (Under construction)

Dallas and Fort Worth Chapter Data Administration Management Association



IT Works ("Euro" Site)



The Year 2000 Problem : (Durham)



Software Reegineering



Euro PAge (Dutch)


Project Management

The Hourglass

(Commercial Service - Members only)


Project Planning

Data Dimensions: The Millenium Journal


Search Engine

Han van Doorn


Search Engines



Search Engines

Richard Warden: Software Futures Ltd

Motivation- Fusion Technique- Testing

Search Engines

SCO (Santa Cruz Operation) Xenix Unix and Open server 3.0 Binary Patches

To get latest Y2K compatible fixes see "SLS uod426b: Year 2000 SLS" entry.


Search Engines

Free Licence for SCO Unix (+Media for $19)

Search Engines

Isogon Corp

MVS Tools


Global Software

MVS Tools




Platinum Technology


Micro Focus



MVS Tools


Business 1999: University of Waterloo



University of Waterloo: Year 2000 References



GTE Evolutions



Evolutions Resource Page:



Coopers and Lybrand



Tick Tick Tick (has moved)

(Commercial Site)



Everything 2000



Hawaii State National Library



Project 21st Century



IBM DFSORT's Year 2000 Features



IBM DFSORT's Year 2000 Features



Data Solutions 2000




Target 4 Year 2000 Page (UK)



More Calendar Stuff



Summary of the International Date and Time Notation



Online Calendar Conversions (with C source)




Y2K Pitfalls



IBM System 390: /390 Multiprise 2000


US Government

Software Migrations Limited

Assembler Migration Tools


US Government

Viasoft Bridge 2000


US Government



US Government


Lotus and the Year 2000: A Perspective


US Government

Congressional Report on Y2k (1996 september 27)


US Government

University of Florida

Compliance Definition


US Government

University of Florida Y2k Home Page


US States

State of Florida

Information Resource Commission


US States

State of Florida

Y2k Vendor Compliance


US States

Millenium Milestones

State of FLorida


US States

CIO index to Y2k



US States

Y2k FAQ November 1996



US States

Report to Congress September 10 1996



Vendor Compliance

Is your Enterprise ready?




Jeffrey Fowler



Year 2000 Inventory Management Ltd

Download a demo version



ICL Year 2000 page

Dateproof 2000 services



Software Emancipation Tech

C/C++ Tools - DISCOVER Y2K.



Interview: Jim Brady: CEO of Matridgm

Transcript of radio interview



Millenium Stocks on a Wild Ride

Stocks and Investments



The Year 2000 Problem Defined

Stocks and Investments



Q&A with Zittel CEO Jack King

Stocks and Investments



Buyer Beware witn Millenium Stocks

Stocks and Investments



Zitels Wild Ride

Stocks and Investments



Year 2000 Stock Chart

Stocks and Investments



The Millenium Bug Will Bite You

Chicago Daily Law Bulletin



Zebra (UK) has moved

Year 2000 Info

Legal Guideleines for Millenium Date Change Issues

Tarlo Lyons (UK)


Year 2000 Info

Solving the Year 2000 Computer Date Problem

A Guide and Resource Directory


Year 2000 Info

"Getting Federal Computers Ready for 2000"

US Office of Management and Budget


Year 2000 Info

Tony Keyes on February 6 OMB Report


Year 2000 Info

The CEO's role in IT decisions

Bill Carico


Year 2000 Info

"Take Heart Tainted Ones"

Bill Cariko



Sponsored in part by

Try Me?