Making the Most of the Time That’s Left
No matter what group you claim kinship to, from the Cynics to the Cassandras, all are discovering that, no matter when a Y2K project was initiated, there are more than enough bumps in the road to go around.
Four-hundred and fifty more days and 450 more sleepless nights. That’s it. Then you can either uncork the champagne and join the rest of the world in celebrating the new millennium ... or, if you’ve been neglecting your Year 2000 duties, change your identity and move to Nova Scotia before the lawsuits start flying. Actually, most IT organizations are in between both extremes. With 450 days to go, the Year 2000 project teams have divided into five groups:
The Cynics. Recognizing how much work is really involved with the Year 2000, this group has been telling top management that the Year 2000 is just a myth created by bored IS managers looking for bigger budgets. Top management doesn’t look past the next quarter, so they’ve gotten away with it – so far.
The Procrastinators. They know the Year 2000 is a huge problem, but, hey, don’t they still have 450 days to tackle it? Why mess with COBOL date fields when you can be working on something really important, like Visual Basic, or Java – or the latest version of Myst? The Procrastinators are rooting for Bill Gates. They know there’s a silver bullet out there somewhere – and they’ll still be waiting for it in December 1999.
The Project Mismanagers. They’ve been working feverishly on the Year 2000, but have not bothered to talk to anyone outside of their own department about it. They see the Year 2000 as an IT problem, not a business problem. They don’t seem to have enough resources, so they’ve skipped the inventory process. If they can’t find more COBOL programmers to hire, they may skip the testing phase, too. Hopefully, they’re not missing any source code with date-field references in it.
The Eager Beavers. This awe-inspiring group has technically been Year 2000 compliant since last year and has sent letters to suppliers demanding that they show the same degree of responsibility. They are now scouring the HVAC and security systems for non-compliant embedded chips. By next year, they’ll be sipping champagne and trying to decide which stocks to sell short come December 1999. The Eager Beavers may be gloating, but they’re nervous, too. They know they’ve missed something somewhere and they can only hope it won’t affect a mission critical system.
The Cassandras. The Cassandras are moving into special Year 2000-compliant communities and have planned for everything. They’ll have their own electricity, telephone systems, and food and water supplies, which will require Y2K-compliant satellite hookups, on-site farms and reservoirs, hospitals and more. If they had spent as much time on the Year 2000 as they’ve spent planning their special communities, they would have solved the problem by now.
In spite of their differences, all five groups have one thing in common – regardless of what they do during the next 450 days, the Year 2000 is going to have a dramatic impact on all of them. Whether that impact is good, bad or indifferent will depend greatly on how they spend the next 450 days.
Minimizing Y2K Risk
Regardless of when a Year 2000 project was initiated, it’s likely to be in trouble today. Even IT organizations that were early adapters are discovering that there are plenty of bumps on the path to the new millennium. Some systems that were already fixed may require re-certification. New systems must be tested, debugged and maybe even made Year 2000-compliant themselves. Those shops that started their Year 2000 projects with just enough time to inventory, remediate and test their legacy systems are discovering they have to worry about missing source code, embedded systems, client-server applications, and non-compliant supply chains.
The key today, regardless of whether you’re just beginning your Year 2000 project or you’re as close to compliance as you can be, is to try to minimize your Year 2000 risk. Corporate counsel will appreciate your taking the following steps, and it will help increase your post-Y2K employment potential:
Use Automated Solutions. There’s a dramatic industry-wide shortage of Y2K staff. In most cases, internal staff can’t handle the work alone. However, there’s an arsenal of automated tools that can help any company save time and money, while mitigating its Year 2000 risk.
Whatever can be automated in the Year 2000 compliance process should be, because it will reduce a company’s reliance on people and free up staff to work on other aspects of the project. Inventory scanners and parsers, data repository, data migration, testing and verification, and estimation tools are available to save you time and money.
As an example of how automated tools can save time and money, consider the problem of missing source code. Replacing an application or rewriting code is time consuming and expensive – yet the Year 2000 cannot be fully addressed unless a company reviews every line of its source code.
To determine the time and money saved from recovering source code instead of rewriting it, consider a program with 150,000 lines of code. Assuming the code is written in COBOL, the missing code represents 1,400 function points, based on statistics developed by Capers Jones of Software Productivity Research in Burlington, Mass.
Based on function point analysis, it would require 28,000 hours of effort – about 14 years of work – to recover the code at an estimated cost of $1,252,500. Even if seven programmers were doing the rewriting, they wouldn’t make the Year 2000 deadline. And keep in mind that recovering the source code is just the first step in the process. Using an automated recovery process instead, the code can be recovered within a few months at a fraction of the cost.
While automation is, of course, more efficient and more accurate than human labor, proceed with caution. Some automated tools are better than others. Y2K has created a whole new industry and hundreds of new products. Some work well. Others don’t. Beware of any product that over promises and keep in mind that there is no Y2K silver bullet.
In addition, just because a company has automation tools does not mean its Y2K project can run on automatic pilot. Every organization needs a core team of IS professionals who understand the millennium bug and know what needs to be done to exterminate it.
Assess Risk. Year 2000 damage control begins with an assessment of the business risk to the enterprise. A systems assessment is insufficient. An assessment of risk to the entire business is needed. The organization must take a broad look at how it will be impacted not only by failures of its own systems, but by failures of others’ systems, including suppliers, customers, utilities and government agencies the organization depends on.
Business risk assessment should be performed by business managers, not IT professionals, because they can, for example, place value on a loss in market share that would occur if just-in-time distribution of inventory were interrupted. Business managers, along with lawyers, also need to determine and measure legal risks that may result when obligations are not met and business relationships are strained. Once these risks are estimated, the organization can better prioritize its activities and manage potential crises.
Risks cannot always be easily measured in dollars. Intangible assets, including reputation, brand loyalty, goodwill and market share may also be harmed. Risk assessment will minimize the impact of Year 2000 damages, but keep an appropriate reserve of capital on hand just in case it is needed.
Perform Triage. Every organization needs to separate the possible from the impossible. Most IT organizations are following the triage approach – dividing all applications into three categories: those with minor problems that can be ignored, those with problems that are too immense to handle and a large middle ground of applications that are receiving most of the attention. If an organization is just beginning its Year 2000 project, triage is still applicable and prioritizing is more important than ever, but the segment of applications that will receive the greatest level of attention must be defined more narrowly.
Develop a Contingency Plan. Always prepare for the worst. Determine where manual systems can replace automated systems and where services can be outsourced. For example, security guards can replace security systems. Accounts receivable and other financial functions can be outsourced. Based on anticipated problems, potential vendors should be identified in advance. Once the problems are addressed, these functions can gradually be brought back in house.
The company may also decide to divest some operations and acquire others. In addition to triaging internal information systems, the organization should consider triaging its suppliers and customers, limiting its exposure to non-compliant organizations.
Some tactics can be initiated at the last moment, when the organization hopefully has a good idea of how close it will come to compliance and where its greatest needs are. Others require planning and implementation immediately. Adequate resources, including budgets, trained staff and adequate facilities, should be ready in advance.
Prepare for the Apocalypse. Every organization should begin preparing for life beyond January 1, 2000. It is, of course, best to avoid failure, but if it’s unavoidable, the organization must be prepared to deal with its consequences. Contingency planning is part of the solution, but a crisis management plan must also be developed to address those Year 2000 issues the organization either has no time to address or cannot foresee.
If the organization’s Year 2000 project team is still confined to IT personnel, it should be expanded to include the CEO and other top-level managers, including corporate counsel, and a public relations or crisis communications manager. If the company is publicly held, include an investor relations manager.
Update Your Crisis Communications Plan. Most sizable companies have a crisis communications plan for communicating during difficult times. The plan should be reviewed thoroughly and updated to ensure that it provides an appropriate response in case the organization’s Year 2000 project fails.
At some point, the company’s vice president of public relations and corporate counsel may offer conflicting advice. Legal counsel may suggest, for example, that calls from editors or reporters not be returned. The vice president of public relations, conversely, is likely to want to get any damaging information out expediently, since quick dissemination typically minimizes its impact. The company’s communications will be most effective if a sound strategy is developed before the Year 2000.
The communications strategy should consider all stakeholders who need to be apprised of the company’s Year 2000 status. All individuals or organizations that can affect or be affected by the outcome of the Year 2000 project are stakeholders, including stockholders, employees, unions, customers, suppliers, regulators and vendors. Even media, the community at large, government agencies, and competitors need to be considered. These stakeholders, and many others, will all need to be honestly informed of the outcome of your Year 2000 project. The content of each message, timing, delivery mechanism, response, and follow-up all need to be well thought out and acted upon.
Prepare a legal audit and legal defense. When, not if, Year 2000 projects begin to crumble, lawyers will be ready to step in. The Year 2000-related lawsuits already filed are a precursor to what is expected to be an avalanche of litigation.
Lawyers should be actively involved in the Year 2000 project team, making certain the efforts underway today will withstand the scrutiny of juries tomorrow. It’s much easier and less costly to involve an attorney who can anticipate potential legal problems and seek a business resolution than it is to wait until after 2000 and hire an attorney to defend your company or organization against lawsuits.
Conduct a Legal Audit. Have an attorney review all your software-related agreements. Be certain to have an agreement in place requiring vendors to address their Year 2000 problems. If you have a maintenance agreement with a software vendor that remains in effect beyond January 1, 2000, the vendor may be obligated to absorb the expense of making the software Year 2000 compliant.
A legal audit will help identify potential trouble areas, but a legal defense is also necessary. Consider answers to some of the questions that will have an impact not only on the effectiveness of your Year 2000 project, but on your ability to ward off lawsuits. Have answers to questions, such as:
- Are the best practices being used?
- Has the organization overlooked "black holes" in the Year 2000, such as missing source code?
- Was the most effective and most efficient technology used?
- Will warranties be breached?
- What contracts will be strained (or broken)?
- Is the entire Y2K project well documented?
Answering these questions will help provide a legal defense when it is needed – or may help avoid the need for one. The legal issues surrounding the Year 2000 are especially prickly because there is no precedent for the Year 2000. Don’t let your organization become a test case.
Act Now. While the Year 2000 demands enterprise-wide solutions and the involvement of everyone from corporate counsel to the CEO, it also presents an opportunity for IT to show leadership. The Eager Beavers who guide their companies safely through the Year 2000 are likely to be rewarded for their efforts, just as the Cynics and Procrastinators who do little or nothing may be greeting the millennium with new resumes.
ABOUT THE AUTHOR:
Leland G. Freeman is Vice President, Strategic Relationships for The Source Recovery Company, LLC (Framingham, Mass., and Roswell, Ga.; www.source-recovery.com). In addition to his responsibilities for SRC, he is a frequent lecturer and author on the Year 2000 computer crisis. He can be reached at firstname.lastname@example.org.