Y2k Countdown: The Year 2000 Titan: Part Two

• 09/07/1998

Your Y2K Ship: Unsinkable? Unthinkable!

To help your corporate "ship" stay afloat I urge you to be aware of, plan for, and avoid the following five Year 2000 icebergs (Note the "iceberg pitfalls" are all stated in the negative and show practices to be avoided, i.e., new/classic Y2K errors). Conversely, avoiding or practicing the opposite of these errors/areas should not only help you in reaching your Year 2000 remediation goals, but help substantially in a court of law to establish that your company and/or its executives were diligent in remediating the problem, mitigating negative impact and exercising reasonable care and good business judgement.

Unreliable Certifications – "Certification by Survey" with no on-site follow-up is useless and gives false confidence to potential and current users.

Indefinitely Waiting For Vendor Fixes – If your vendor has been habitually late in delivering fixes and upgrades in the past, he/she will be in the future too.

Poor Triage – Even if some systems fixes are deferred, they cannot be deferred indefinitely. They still must be addressed one way or the other before Year 2000.

Wasted Time – Don't agonize over whether and how best to do a fix -- get started now!

No/Poor Contingency Planning -- Surprises will happen and you are dependent on other parties and partners that you may not have much control over. As a result, you need alternatives/contingency plans to buy time when your primary plans fail or are delayed.

No Single Remediation Plan and Standards – Since your problems are enterprisewide, your solutions should be as well (i.e., one integrated plan for remediation and not different non-integrated solutions for different parts of your company).

Underestimation – Be realistic, not optimistic. The bane of the information processing industry is over-optimism and fantasy. Perform a rigorous estimate and identify assumptions and have it challenged by company executives and the board of directors. Then add a contingency factor.

Not Managing Risks – Identify the "Top Ten" risks associated with the project and then fix, track and report them each week. Update this process as necessary.

Starting Too Late – If you start late, you will end late. That's OK as long as you implement interim contingency procedures to get you by (i.e., muddle through) until your other systems are compliant.

"Rosier than Actual" Status Reports -- Don't lie to yourself and others on your progress; if you've fallen behind you are not likely to make it up. Implement alternative interim solutions to buy time.

Under-Verifying and Under-Validating Period Ending Dates – Most errors happen at period ending dates (i.e., week-ends, month-ends, quarter-ends, and year-ends) which, to make matters worse, typically involve more dollars (running total amounts) that have a greater impact on the company. Test the daylights out of these.

Under-Verifying and Under-Validating Special Y2K Dates – Such dates include:

• 12/31/1998 (normal year end.)
• 6/30/1999, 7/1/1999 (Fiscal year cutover.)
• 12/31/1999, 1/1/2000 (Century cutover.)
• 1/1/1999, 9/9/1999 ("Trigger logic" default dates.)
• 2/29/1999, 2/30/1999, 2/31/1999, 3/1/1999, 2/28/2000, 2/29/2000, 2/30/2000, 3/1/2000 (Leap year tests.)
• 2/29/2004 (Leap year.)
• 1/1/2100, 2/29/2001, 1/1/3000 (Not leap years.)
• 4/1/99 (Probable first fiscal year start that goes into next century.)
• 7/1/1999 – 6/30/2000 (Fiscal year end over "time warp.")
• 10/10/2000 (First true 10 character date.)
• 12/31/2000 (366th day of the year.)
• 1/1/2001 (21st Century.)
• 1/1/2002 (Ensure no backwards processing errors.)

Unrealistic Expectations – Define a controllable scope. Only plan for what can be reasonably accomplished in the time remaining based upon resources available and quality of work required. The rest must be accomplished with alternatives.

"Code and Blow" Approach -- Avoid making the fixing too long and cutting the testing too short. Your fixes will introduce new errors and may not fix all of the date problems. AT&T's long-distance service collapsed a few years back when only three lines of code were changed. The QA group said the changes were so insignificant that no re-testing was required.

Shortcut Testing – You must perform tests to assure that the fixes work as expected and that you have not inadvertently created new errors. Functions that worked before that could have accidentally been affected must be re-tested with "regression tests."

No Independent Quality Assurance Function/Review – The people that fix the systems cannot be the only ones that test it. If the fixers missed something during remediation, they are likely to miss it as well in testing. An independent group (inside or outside of the company) should perform the final tests before going into production.

Poor Contingency Execution – For contingency plans to be effective, they must be executed when critical dates in the primary plans begin to look like they will be missed. Don't wait until it’s too late to execute your contingency plans.

Insufficient Management Understanding/Commitment – Executive management refuses to freeze other business opportunities and displaces/reroutes Y2K resources to other activities.

Iceberg No. 2: Staffing

"Five week wonders" -- Don't hire kids straight out of 3-5 week COBOL training unless you plan to give them more intensive training and manage them closely.

Ineffective Training – Legacy systems are riddled with missing source code and very clever logic intended to fool the computer to process complex systems in the very small memory spaces available 20 to 30 years ago. This is not work for novice programmers.

"Cocky" Staff Holding the Company Hostage – Have an ongoing process to replenish staff – otherwise you may have to pay a king's ransom to avoid being raided.

High Turnover – Turnover can be particularly harmful because of the onrushing Year 2000 deadline. Create an environment that keeps turnover to a minimum.

Uncontrolled Loss of Desirable Staff -- There are many ways to keep your critical staff without busting your salary structures and budgets including. These include: completion/stay bonuses and sign-on bonuses; sabbaticals when project successfully finished; promised training in the newest most exciting technologies after 2000; a work at home policy a few days a week with company paid ISDN lines to employees' homes; etc.

Inability to House New or Needed Staff – When you find new staff, where will you house them? You may need additional bathrooms, water coolers, photocopy machines, facilities, parking, etc.

Salary Structure Disruptions – Simply tripling the salaries of key systems staff and programmers can throw the whole salary structure of the company out of alignment. Make sure you consider any ripple effects of salary revisions else it may cost you much more than you originally considered.

No Post-2000 "SWARM" Team (SoftWare Analysis and ReMediation team) -- The problems will not end on January 1, 2000. Missed errors, missed understandings, missed programs will all surface to create new or deeper problems. Keep your teams intact to isolate, identify and fix these problems as they arise. This team likely will be needed through mid-2001, at the least.

Outsourcing to Software Factories – The history of the last year or so shows that they can be quite expensive to manage and they must be managed quite closely. Plus, software factories are not the silver bullet promised.

Know Your Y2K Fixers -- Especially if you go outside and/or offshore, you may be opening yourself and/or your systems up for possible espionage and terrorism (i.e., with someone putting a virus or back door or time bomb into your applications).

Overlooked Vendor Problems (Including Year 2000 Problems) – Vendors and suppliers have their own Y2K problems. Some may not get paid by their own customers with Y2K problems, or may fix their systems in ways not compatible with your own efforts. Communicate and determine your risk and alternatives.

Succumbing to Schedule Pressure – "The due date's here so we must be done!" If only that were true!

No Project Office or Minimal Cross-Team Communication – You have failed to set up a single, central, enterprisewide resource that will: set up standards for remediation; determine tools to be used (including scanners and parsers); maintain common source code libraries; develop common testing environments and test cases; provide QA services: implement quality control procedures; sign off on modules ready for production; etc.

Inability to Motivate Staff – Your staff is tired of the never-ending project and you haven't yet figured out how to motivate and invigorate them.

Iceberg No. 3: Product

PCs, Midrange, Client/Server, Networks and Telecommunications Systems Ignored -- Hey, it's not only legacy systems that have Year 2000 problems and must be fixed.

Suppliers Not Ready – If your supplier can't get you your products and raw materials who will?

Failing to Reduce Risks of Processing Corrupt Data Received from External Trading Partners – Your systems are perfect, but your trading partners' systems are not. You’re in big trouble unless you can detect errors in data and dates coming from their systems and process them as exceptions.

Relying on Third-Party Certification – Most don't have the time or money to really certify others systems. Review their work carefully to determine the risks to your company, augment the certification and manage the risks.

Embedded Systems Overlooked – The chips used to manage elevators, energy grids, power, traffic signals, automated guided vehicles, medical and lab equipment, smart buildings, heating and air cooling, security systems, telephone PBX systems etc. are all potential candidates for failure. Although most will work just fine because they don't care about the date or they have manual overrides, you must determine what will not be ready/fixed in time and plan for it.

Shortcuts in Testing – Shortcuts are not allowed unless you have first determined what the risks and impact of failure will be. If your company is willing to accept certain risks (and it should be because it is too expensive to test everything and prevent all Y2K errors) then you may make shortcuts in those identified areas. Knowing which applications to focus on is the key.

Contractor Failure – What if your contractor, vendor or consultant says it’s fixed? Is it? What must you to ascertain readiness?

Leap-Year Miscalculation – There is no such thing as a "super leap-year" (Do you believe that some companies thought there were 30 days in February 2000?). The rule is: If the year is divisible by four it is a leap year unless it is divisible by 100 then its not, unless it’s divisible by 400, then it is a leap year. Thus 2000 is a leap year and 1900 and 2100 are not.

Missed "Pre-2000" Critical Dates – Some industries and companies will fail before Year 2000 such as: insurance companies who will hit the wall on 10/10/98 -- when they first write new policies for the period 1/1/99 to 1/1/00; subscription companies – many of which are already facing problems. What is your critical time frame?

Non-Synchronized with Customers/Suppliers – You can have the perfect solution but it must complement those of your trading partners (i.e., you all must use four digit date expansion, or the same windowing approach, or the same encapsulation procedures, etc. else each system will be Y2K compliant separately but still will not work together unless you create bridges). Also even if you are all using the same solutions, you must all synchronize the date and time you put the new systems into production.

Customers Not Ready – How can you help? Will you loose that business? How can that business be replenished?

Poorly Integrated – You had no standards so your systems have multiple solutions that are not integrated. Gotcha!

Awaiting "Silver Bullet" Solution – Stop it already! The silver bullets died with the Lone Ranger. If you wait until one exists you will fail and you may be sued -- and successfully, too.

Changing Operating Environments – Don't attempt to change your operating environment(s) during the Y2K fix and test. This is no time to drastically upgrade your operating systems, compilers, utilities and communications software unless you must for some other good business reason.

Not Freezing Requirements – Don't attempt to fix, enhance or upgrade applications unless you have to. That will only make it more difficult to isolate errors as to whether the Y2K fixes caused them or the other maintenance.

Iceberg No. 4: Technology

Using New Tools -- New tools have their own coding and logic problems. Also, users can be expected to make mistakes before they learn how to best and appropriately use the tools. Beware, new tools can turn a development project into an R&D project.

Using the Wrong Tools – Using good tools for the wrong purpose will give you the wrong answers and make you think your work in done prematurely.

Using Tools Incorrectly -- Understand the limitations of each tool and tool category. Remember that a scanning tool will only find certain errors but not all of them. What must you do to complete the job?

Using New Vendors – Many new vendors have popped up to take advantage of the Year 2000 panic and shortage of staff. Check background, references and financial stability.

Forgetting that 01/01/99 and 09/09/99 are "Mini Melt-Down" Dates – Old procedures caused programmers to code unknown dates as 01/01/99 and 09/09/99. This then would trigger exception logic not associated with the real dates. When the real 01/01/99 and 09/09/99 hit, these programs will treat those dates as exceptions and not as the current dates.

Using No Tools at All – While all tools have limitations, most will definitely help to accelerate your identification, assessment and remediation tasks. Failure to use these tools is criminal.

Changing Configurations – Remediation services are most effective when performed in a stable environment. Changing/upgrading hardware, networks and systems infrastructure during remediation will only delay and increase testing and risk of failure.

"Analysis Paralysis" – Failing to act prudently and quickly while searching for the best practice or solution.

Encapsulation, Windows, Bit-Fiddling, Four-Digit Century Date, etc. – There are many ways to get to Manhattan…but you must be consistent. Each solution has plusses and minuses: some take longer to implement, some work for shorter periods of time, some are less expensive, some take up more computer resources, etc.

"Not Invented Here" Syndrome – Read, attend conferences, get on the Internet and go to industry Y2K special interest group meetings. Don't reinvent the wheel. It doesn't matter where or who invented it. If it works, use it.

Testing on Similar but Different Configurations – If you must use outside hardware to test your systems (because you are already running near capacity) then take into account the difference in the configurations (i.e., the channels, disk drives, version of the OS, utilities, etc.)

Forgetting the Telecommunication and Network Parts of the System -- When the pagers went out in Los Angeles a few months ago, the city almost came to a halt. Just think what will happen if telephones, networks (including the Internet) and fax machines all ceased to work for you in 2000. What are your options, and backup plans?

Trying to Implement Year 2000 Compliance Systems without Allowing Appropriate Training for Use of New Technologies – New technologies, tricks, methods, software and tools are all tricky and require a leaning curve and a debugging curve. Try as you might, failing to plan for these curves will only put you further behind.

Iceberg No. 5: Legal

Improper Disclosure – Proper disclosure is not required by law. Under- or misleading disclosure in financial statements, insurance applications, merger and acquisition representations, 10Ks and 10Qs, etc. can all come back to haunt you. Over-disclosure can hurt as well.

Merger and Acquisition Nightmares – How are you going to assure yourselves that the company you are merging with or acquiring is, in fact, Year 2000 compliant. To what extent can you rely upon their warranties and representations? To what extent will you perform your own due diligence?

Tolling Statute of Limitation Agreements -- When will warranties, insurance and statutes of limitation begin to run – at the time of purchase or implementation? At the time the first defect was encountered? Or at some other time? How can you protect your rights as time continues to run out?

Express and Implied Contractual Warranties – How are you protected within your older existing contracts? Where are you most liable? What can be done to minimize risk now and in the future?

Compliance Commitments -- What is the level of readiness of your trading partners? What is their level of commitment? Investment? What dates and guarantees are they willing and able to give you? What are their contingency plans? How does the answers to the above impact/change your own position and plans?

Poor Paper Trail – Document your efforts to identify and remediate the problem. [At least consider keeping the items listed in "The Year 2000 Paper Trail" by Warren S. Reid originally published in the Enterprise Systems Journal, July, 1998, www.esj.com.]

Numerous Plaintiffs—Anyone and everyone can sue: users, suppliers, customers, shareholders, regulators, injured parties.

New Board Liabilities – Boards will be held responsible for Year 2000 caused business failure. In the past computer glitches only meant that the CIO or CFO would be reprimanded.

Improper Use of Experts – Using experts too little or too late will not help show due diligence and informed decision-making. This leaves not-especially-computer-savvy Board members exposed to lawsuits.

"Killer" Minutes – Sparse Board Minutes regarding Year 2000 discussions and decisions may not be enough to show due diligence and informed business judgement.

"Deadly" E-mails – Some people say, "It is impossible to erase an e-mail (for sure) once it has been sent." Make sure you have an enforced data retention and creation policy. Stop disgruntled employees from spreading untruths.

Not Managing Risks – All large projects have risks. What are the risks in your organization: Not enough staff, time or money? Changing regulations? Outsourcer problems? Vendors going out of business? No source code? Use of obscure languages? An abnormal reliance on a few key customers, suppliers or contracts? High staff turnover? The Euro conversion? Changing from legacy to client/server architecture? And how will you monitor, manage and mitigate each of these?

Arbitrarily Low Budgets -- Compare your budgets to similar companies in your industry and to industry studies. If you are way under, find out why?

Poor Contracts on New Systems and Remedies -- There is no acceptable reason for failing to include proper Year 2000 provisions in all of your new or updated contracts. Don't make the same mistakes all over again.

No Established Documentation/Retention Policy – Define and implement smart and consistent rules for keeping, filing and destroying documents relating to the Year 2000 efforts.

Poor Risk Management – In such cases you have identified the risks but have not budgeted, documented, staffed and recognized alternatives for when the risks manifest themselves into reality.

A Final Thought

One final admonition is in order. I realize that each organization and course plotted will be somewhat different depending upon current position, resources, and destination/goals. Some of you will move like warships; others like cruise ships; and yet others like tall ships. But these icebergs have been there for some time. Be alert, chart your course, commission a captain, procure and train a crew, gather the necessary resources, manage risks, have a backup plan and steer clear.

Bon Voyage!