You’re not working on the Year 2000 problem because…

• It’s not your problem.
  
  
• You still believe in Santa Claus.
  
  
• You’re using client/server applications.
  
  
• Your company can’t afford it (but it can afford to go under).
  
  
• The New Year’s holiday is always over a long weekend—that should give you enough time to fix the problem.
  
  
• You’re moving to a paper-based office.
  
  
• How could two little digits cause so much trouble?
  
  
• Your horoscope doesn’t mention anything about it.
  
  
• There are no programmers left; they’re all working on the Y2K problem.
  
  
• You have company standards that deal with this sort of thing.
  
  
• You never work over the New Year’s holiday.
  
  
• Your standards and QA wouldn’t allow anything bad to happen.
  
  
• You deleted the Visual Basic code for your applications from your hard disk.
  
  
• You’ll have a support person go in over the weekend just in case.
  
  
• You can’t admit to having released software that doesn’t work properly.
  
  
• You believe that the world will come to an end in 1999.
  
  
• Things are too busy at the moment.
  
  
• Your applications will have been replaced by the year 2000.
  
  
• You don’t use third-party controls.
  
  
• Microsoft will fix the problem.
  
  
• All your software is written by outside vendors, so the Y2K stuff won’t be a problem.
  
  
• Year 2000 problem—what Year 2000 problem?
  
  
• You just can’t be bothered.
  
  
• You hate this company anyway; let them suffer.
  
  
• You get a buzz from all the doom and gloom.
  
  
• The whiz kids are bound to come up with a silver bullet that will fix everything.
  
  
• You’re waiting until your competition starts working on the problem.
  
  
• You’re looking for a new job.
  
  
• Nobody has asked you to look into it yet.
  
  
• All your resources are tied up writing new applications.
  
  
• The Year 2000 crisis should help to strengthen your team awareness.
  
  
• You can’t bear the thought of all that work.
  
  
• It’s all hype.
  
  
• You’ve still got over two years left, so what’s the rush?
  
  
• You’ve always thought that your company relied too much on
  computers anyway.
  
  
• It’s a PC problem; the software won’t be affected.
  
  
• You’re trying to get into a more relaxed lifestyle.
  
  
• You’ll get around to it any day now.
  
  
• You don’t use many dates in your applications.
  
  
• You can’t face telling your manager about the problem.
  
  
• You’re playing it by ear.
  
  
• You’ll be retired before the year 2000.
  
  
• All your applications are brand-new, so it won’t be a problem.
  
  
• You’ve never liked New Year’s Eve parties anyway.
  
  
• The Year 2000 sounds so far in the future.
  
  
• You work only with fancy buzzwords; this problem isn’t attractive enough.
  
  
• It’s just a job.
  
  
• You haven’t heard of this problem, so it can’t be true.
  
  
• You wrote your software and can’t bear to admit it has a problem.
  
  
• If anything goes wrong, you’ll bring in a contractor to fix it.
  
  
• You don’t really need to invoice your customers for a few months.
  
  
• You don’t do maintenance.
  
  
• You’re planning to look into this next year.
  
  
• You believe the Y2K problem has been invented by consultants.

OK, so let’s say that you’ve convinced management that the problem is real, and they have agreed to look into the Y2K issue. The next step is to plan your company’s approach to fixing the problem. No manager will agree to allocate resources to a project unless it has a clearly defined plan that includes cost estimates, staffing requirements, and time constraints.

Having and using a solid plan will help to keep project staff and senior management focused on the tasks at hand. Any issues or slips will be noticed immediately, so the deadline should remain intact. Don’t underestimate the power of planning. In the Year 2000 projects that have been completed so far, estimates suggest that about a fifth of the effort involved was in project management.

At this point, it’s worth mentioning that it’s imperative to appoint a Year 2000 task group or coordinator/project manager at the earliest stage. Attempting to deal with the Year 2000 problem from hundreds of directions not only will duplicate many hours of work but also might impact other divisions of the IS department outside your own. By running the project from a central location, you can group all issues and tasks under one umbrella, even if this means one person overseeing the entire IS department. Also, because the Year 2000 problem affects systems of all origins (mainframe, PC, database, and so on), a central overseer can coordinate any system integration or data sharing that might occur between systems.

In short, don’t try to take on the world by yourself! It’s possible that your Visual Basic applications interact with outside systems. It’s also highly likely that you have no control over these external systems and therefore you are powerless to initiate any Year 2000 tests or changes within these projects. Again, get a coordinator to oversee this interaction.

Because project management is an area that most Visual Basic programmers don’t come across every day, I’ll try to keep the planning issues as simple and straightforward as possible. I could break down the plan into a zillion stages with billions of subtasks, but in the interest of sanity, I’ll take a four-stage approach: analysis, modification, testing, and implementation. At the highest level imaginable, analysis involves figuring out what needs to be done; modification does it; testing ensures that it works; and implementation puts it back into production.

Let’s take a more detailed look at each of these stages.