y2k countdown: Paths to Successful Year 2000 Projects

One of the key duties of a Y2K project manager is to prioritize the project into business risk segments. To do this demands an understanding of the business and the relationships of all MIS applications that support it. A manager must know which applications are most altered by century dating failures.

The AS/400 has some excellent commands and free PTFs to help you along. Should you proceed down this path to build and debug your own solution as the Year 2000 tool vendors have?

Have you often thought of the alternatives between using manual and automated methods to solve Year 2000 projects? What drives an MIS department toward the decision that manual methods are better? After all, isn’t that the reason for writing programs, applications and other systems – to automate and get it done faster and better?

MIS tells its customers and management that automation and the latest software and hardware is the bridge to a competitive edge. The overall IT trend has been towards packaged software. Why might Year 2000 be different?

It may make some sense to attack the Year 2000 challenge manually, without incurring the cost of a packaged tool or suite of tools. Inventory applications might be a sufficient guide, but they do not measure complexity of code, or tell you the percentage of affected code. Such inventory aids rarely answer the question of how many program file display reports have a date. Nor will inventory level reporting tell you what needs to be changed or how difficult that might be to address.

Larger tasks ought to consider that lines of code is an imperfect measure of project size, one that should be refined after the initial first cut. Estimating features covering complexity and work effort are available in many impact analysis tools.

Some IS professionals are looking for the perfect tool at the perfect price. That just might not be there by each individual’s definition. What should happen is product review and evaluation, perhaps a small or representative pilot. Even a business impact analysis is in order to understand the scope of the problem. Ask yourself the question, "What is my work effort and how must I address the corner office for funding?" Funding must be justified by some easily understood management criteria.

Domains Have Meaning

The sum of the parts individually does not have the same value as the whole. The whole is of greater value! How can that be?

Any analysis should cover as broad a spectrum as possible. A spectrum might be considered a domain width. The wider the width the more it is possible to see the relationships that flow between them. Thus, importance is placed on considering this in your evaluations. Isolation of the parts does not show the inter-unit flow. Let's view two areas for a moment.

MIS domain analysis is done to the system in various levels, yielding differing results. The enterprise domain is at the highest level we can influence, covering all systems and interfaces and interactions to external trading partners. This might include the middleware and client/server talking through common Year 2000 compliant interfaces. One of those key interfaces might be an EIS system.

The next analytical view is at the system level. These are the interactions contained within one box. Then the application level – all actions limited to remain within the application. Next comes interactions that are at the database (file) level and migrate via files across boundaries. Then the program level, which can be either self-contained or the exchanging of date-sensitive data with other programs.

Business domains or sectors will not necessarily remain the same and will likely cross these MIS-defined boundaries. However, it is important to view both business and MIS domains and the intersections. An example is the customer master files, which cross accounts receivable, order entry and more. Look at the general ledger – it does not miss much.


The global domain is the biggest domain of all. Since Year 2000 issues reside within the infrastructures of all businesses, utilities, and public sector organizations, government and private industry must be in sync for success. More than just-in-time practices are at risk. Nothing remains simple when it becomes a worldwide business coordination project.

We have viewed and considered several areas on the surface. This is not all-inclusive by any means and the available features change daily. The ultimate objective is to pass through 2000 intact with a reasonable system and company plan. It does not matter if you have a "phase two" post-Year 2000 plan to completely finish the effort

To do that requires mustering resources, investigating the impact, activating an action plan of due diligence within the organization, its suppliers and customers. That’s not a trivial undertaking. Missing the starting gate, or failing to take advantage of all available aids, can be equivalent to playing Russian roulette with a loaded gun.

Hopefully, we will guide ourselves through the Year 2000 challenges, avoiding disaster by acknowledging its very existence and proactively taking action to control this pervasive monster. Prudent risk management audits IV & V are in order prior to production. More on this next article.

Glenn Ericson is president and founder of Phoenix Consulting LLC, in East Elmhurst, N.Y. He specializes in Year 2000 and risk management issues. Glenn-Ericson@att.net