Getting in gear for the year 2000.

The new millennium represents a potential migraine of mega proportion for associations whose electronic records and systems aren't ready to respond. The good news is, there's still time to prepare.

Imagine this worst-case scenario: Your association management software system is not year 2000 (Y2K) compliant, and when you boot your computer on January 1, 2000, the software system continues to run. What makes this the worst case is that the data in your software system are subsequently corrupted, and you may not discover all the errors until weeks or even months later. By then, your members will have received dues invoices with incorrect amounts, registration confirmations with invalid calculations, or product invoices with inexact totals. Internally, your system will have posted invalid totals to your general ledger, erroneously calculated data within your membership statistics reports, and sent batches of credit card payments to the bank that will have been refused.

At best, a Y2K problem will compromise the internal operation of your association; at worst, this problem will spread to the services you provide to your members and customers. But there's something you can do. By making sure you have an understanding of the millennial threat to business as usual and by taking certain measures, you can minimize the impact on the internal functions of your association and the services you provide to your membership.

The heart of the problem

Disk space was not always as inexpensive as it is today. In the 1980s and earlier, programmers conserved disk space in very creative ways, one of which was to abbreviate the four-digit year to a two-digit year so that "1/1/1982" was represented as "1/1/82." In the computer program logic, programmers embedded the "19" in 1982.

We know that "1/1/82" (1982) is earlier than "1/1/00" (2000), but the computer logic will interpret "1/1/00" as less than "1/1/82." At 12:00:01 on January 1, 2000, systems that are not Y2K compliant will read "January 1, 1900." Any calculations, sort processes, or retrieval logic based on date will be incorrect. This is essentially the heart of the Y2K problem.

Unfortunately, many problems resulting from the millennium change will occur well before the year 2000. Associations that prepare multiple-year budgets are probably already being affected if their software is not Y2K compliant. Similarly, associations that offer multiple-year memberships or preregistration discounts to members and/or exhibitors will also be affected by the year 2000 problem well in advance of the new millennium.

However, the Y2K problem is not only limited to budgeting or registration fees or membership dues. Data in reports that rely on dates for retrieving and sorting records or calculating totals will be incorrect. This will occur in membership statistics, political action committee contributions, orders and subscriptions, claims analyses, and donations reports. Financial transactions will also be incorrectly posted to the general ledger. In the worst case, membership records will be dropped because delete programs based on various dates may be automatically, but inappropriately, executed.

Likewise, back-end databases on which association management software is developed may fail to be Y2K compliant. Third-party software, such as accounting, spreadsheet, and front-end database software may also have problems with the date change. Desktop computers, printers, client-server systems, and network operating software all may lack Y2K compliance.

Who is most vulnerable?

We know that the Y2K problem is coming, and we have an idea of how it will affect associations, but which associations will be the most vulnerable? You are particularly susceptible to a crisis if you

* have legacy association management software (more than two or three years old), especially if the software is not fully and accurately documented;

* purchased association management software in the early to mid-1990s, since much of this software was simply developed from older software code with a graphical user interface (GUI) slapped on the front end;

* have not kept current with new software releases;

* support multiple PC databases rather than one integrated and centralized database throughout the association;

* have interface programs with other PC applications, such as accounting, registration, political action committee programs, and so forth; or

* exchange data with outside organizations, such as fulfillment or mailing-list houses.

Even if you have recently purchased brand new association management software, there is no guarantee that it will be Y2K compliant. (See sidebar, "Six Myths About Year 2000 Compliance.")

How can associations strategically address the Y2K problem? First, assess the resources you have available. A Y2K project cannot be completed on someone's free time. The transition to the year 2000 requires a project leader managing a team that has ownership for the success of the transition.

Assembling your Y2K team

The project leader should have final responsibility for the project plan, budget, deadlines, vendors, and consultants. The project leader should be an association staff member. Other staff members of the Y2K project team should be representatives of key departments, such as membership, meetings, publications, and so forth. These members will have input into prioritizing business requirements.

Your current or prospective software vendors will also provide input in terms of the Y2K compliance of their software. There may be representation by multiple vendors, including association management software, accounting, and outside fulfillment houses.

Your Y2K project team is best complemented by an outside consultant who has no vested tie to the software vendors or any of the Y2K conversion tools that you may purchase to fix your software. However, this consultant must be knowledgeable of vendor systems. A good consultant will reduce your risk, cost, and time throughout the project by knowing the right questions to ask; implementing a proven Y2K audit methodology; conducting necessary research and testing; reviewing Y2K compliance from a technical and business perspective; and keeping the project on schedule and within budget.

Finally, your attorney plays a key role by providing a final review of both your acquisition and maintenance agreements to legally ensure that the association management software system you select or upgrade is Y2K compliant.

Plan to play offense

With your team in place, you can now consider two basic approaches to addressing the Y2K problem: 1) develop procedures to work around the problem - a defensive tactic - or 2) play offense by employing a systems approach. Procedural workarounds are worth mentioning only because they represent the last-ditch effort to surviving a Y2K crisis. For example, if your registration program will not be Y2K compliant in time for your annual meeting in 2000, then you may want to consider eliminating preregistration discounts. Warning: Procedural workarounds are intended to stop the system from hemorrhaging - they are not a permanent fix.

A systems approach to the Y2K problem is the only effective means of minimizing the impact of the millennium date change on your association. First, take an inventory of your systems - both hardware and software. Test your association management software to determine where it is most susceptible to the Y2K problem. After you identify these weak links, determine how closely they relate to your business requirements. Ask how these links will affect the internal operations of your association and how they will affect the services you provide to members, customers, prospects, and others in your constituency. Begin to establish priorities to address the most critical areas first.

Next, ask how these weak areas can be most effectively strengthened. For instance, should you repair or replace your current software system? You may want to consider repairing your software system if you have recently purchased the software, if the software is well-documented, and if the vendor has a Y2K "fix" available. Remember, though, that an upgrade option to fix the Y2K problem may mean that you cannot carry forward any customization that the vendor has previously done to meet your specifications.

If your system is not Y2K compliant, you may also choose to consider purchasing a new association management system. Many associations are taking this opportunity to see what capabilities exist in other software packages.

A particular challenge faces those associations that have built their own association management software. Typically, many programmers have had their hands in the development of the software, and the program code is not well documented. Testing for Y2K compliance will be very time consuming. Even though an association can purchase conversion tools that attempt to fix the code, testing your software system for Y2K compliance after executing these tools may take months if your system is complex.

Whether you opt to repair or replace, remember that time is running short and the conversion phase of this transition will be more challenging than any prior conversion. The year 2000 problem poses unique conversion issues. For example, dates may have varying field lengths and formats. In some systems, "99" means the last record and "00" means a null record. While not properly a Y2K problem, remember that the year 2000 is also a leap year. Many software systems were not developed to recognize "2/29/00." Conversion testing will take a significant amount of time to verily Y2K and leap year compliance.

The Y2K countdown

Associations have only one chance to make a successful transition to the year 2000. The date looms with more finality than an association's well-publicized annual meeting. Although the time required for a successful transition will vary for each organization, here are some general guidelines you can follow as you map your own Y2K strategy.

* Conducting an internal audit (taking inventory and testing) of all systems will take approximately two to three months.

* Prioritizing your business requirements that will be affected by the year 2000 problem will take one month.

* Evaluating and finalizing a repair will require about one month. (Keep in mind that repairing some software components and replacing other software modules is also a viable option, although a more complex one to implement.)

* Negotiating an acquisition and maintenance agreement will require approximately two months, although some negotiations do take much longer.

* Designing a new system will require another two months, while at least three to four months should be set aside for conversion and testing.

* Training for a new or upgraded system will take about another month.

The entire process, done correctly, will average 14 months. This does not include making other arrangements with your suppliers - for example, mailing houses - if their systems are not Y2K compliant. This does not mean that you can wait until November 1998 to start the process. Remember, if you process multiple-year memberships, offer preregistration discounts for meetings, or have a fiscal year that spans two calendar years, you have even less time. Likewise, larger associations with legacy software may need significantly more time if they choose to repair their software and other systems.

Tackling the Y2K problem is not an option, and surviving it will be a challenge to many associations. But with the right team, effective methodology, and the required committed resources, a smooth transition to the year 2000 will give cause to really celebrate the new millennium.

Editor's note: If you haven't yet heard about - or if you're wrangling with - year 2000 technology-related concerns and the potential adverse effects for your association and its business operations, this article is a must read. If you already consider yourself an expert on the subject, by all means let us hear from you. In subsequent issues of ASSOCIATION MANAGEMENT we will cover in greater detail specific issues related to year 2000 compliance, many of which are mentioned in this article. Look for this identifying icon in future issues of ASSOCIATION MANAGEMENT to locate ongoing coverage of year 2000 topics. And send your comments about what you think we should cover - and what you would be willing to write about - to "Year 2000 Editorial," ASSOCIATION MANAGEMENT, ASAE, 1575 I St., N.W., Washington, DC 20005-1168; fax: [phone]; e-mail: [e-mail].

Year 2000 Listserv

You can ask questions of your association colleagues and keep informed of the latest Y2K compliance concerns by signing on to ASAE's newest listserv exchange devoted to this topic. Send an e-mail message to [e-mail].

RELATED ARTICLE: Six Myths About Year 2000 Compliance

When it comes to taking action on year 2000 (Y2K) compliance, don't be lulled by.these popular myths.

Myth 1: My software and hardware are brand new, so they're Y2K compliant.

Reality: Software and hardware recently purchased may not be Y2K compliant. New doesn't necessarily mean compliant.

Myth 2: The vendor who sold me our association management software says it's Y2K compliant, so it must be.

Reality: It may or may not be compliant. Assume that you have the most current version of a vendor's association management software. To meet year 2000 compliance requirements, the back-end database must be Y2K compliant; the vendor's programmers must have used this capability to develop code that is Y2K compliant; all software interfaces must be Y2K compliant; and all third-party software that integrates with the association management software must be Y2K compliant.

If the software is several versions old or was ported from an earlier system, the vendor may not know if the software is Y2K compliant. If the vendor, or your staff, has customized the software, you need to evaluate both the code and the documentation before you can determine whether it's Y2K compliant.

Myth 3: All I have to do is buy the software upgrade.

Reality: This sounds easier than it actually is. First, a Y2K-compliant upgrade must be available. Second, the upgrade must be backward compliant - that is, your data will carry forward to the upgraded software. Third, you may lose some or all of your customization in the upgrade. And fourth, you must still rigorously test the conversion to a Y2K-compliant upgrade.

Myth 4: The screen on my computer shows a four-digit year, so my software must be Y2K compliant.

Reality: How the year is displayed on the screen may be irrelevant to how the date is computed internally. For example, the "19" portion of the year may be hard-coded or the software could base calculations on two-digit year dates and still automatically display a four-digit year on the computer screen.

Myth 5: My information systems personnel can figure it out.

Reality: Hindsight will show lack of chief executive officer involvement, poor project management, and inadequate resources to be major reasons why an association didn't make a successful transition to the year 2000. The Y2K problem is not only a technical problem. It is a management challenge that will have very specific negative results if not effectively addressed.

Myth 6: I can simply download some Y2K fixes from the Internet to solve the problem.

Reality: More fly-by-night consultants will crop up during the next two years than ever before, and they will be hustling solutions that will increase their income by offering you a quick fix. Even a logical fix to the problem - for instance, any date less than "50" is a "2000" date while any date "51" or greater is a "1900" date - won't work in every case. And before you discover the seam, you will have lost both money and valuable time.

Kathleen Krajewski is president of Krajewski and Associates, Inc., Rockville, Maryland. E-mail: kkraje@;[e-mail].