Dealing with a New Reality -- A CIO's Action Plan

by Ian S. Hayes

 

In a few short months, we will make the much-heralded entry into the 21st century. This century transition will be like no other due to the famed Year 2000 problem. Whether or not some of the more dire Year 2000 predictions come to pass, we can be certain that the post-Year 2000 landscape for the average Chief Information Officer (CIO) will markedly change.

The past few years have witnessed an unprecedented upheaval in almost every IT organization across the globe as Year 2000 projects consumed enormous amounts of time, effort and budgets. Entering 1999, the largest 1,000 U.S. companies alone were predicting expenditures topping $50 billion for Year 2000 work.1 The U.S. government's budget is expected to exceed $7 billion. What's worse is that the numbers have kept growing, signaling that most companies and their IT departments have struggled to determine the true scope and extent of their Year 2000 problem.

Issues Facing the Post-Year 2000 CIO

The upshot of this situation is that everyone, from schoolchildren to grandmothers to CEOs, are all familiar with the Year 2000 fiasco. IT organizations, formerly consigned to corporate backwaters, have been thrust into the spotlight. Unfortunately for IT, its 15 minutes of fame are not glorious ones. IT has become notorious, yet again, for its shortcomings, shortsightedness and failings.

Where does the CIO figure in all this mess? You can bet that the CIO, as the primary executive responsible for Year 2000 efforts, has focused the majority of his or her time and effort on the project, and justifiably so. The CIO's job security hinges on the success or failure of the project. But as 1999 winds down, and the CIOs lift their noses from the Year 2000 grindstone, what are they likely to find on their plate?

  • A backlog of postponed work. With the majority of IT resources assigned to Year 2000 work for several years, requests for new systems, enhancements and ordinary bug fixes were deferred. Compounding this situation is the "freeze state" that many IT organizations have adopted or will imminently adopt, to avoid fouling Year 2000 efforts with other types of maintenance changes. Add to this the number of delayed or failed correction efforts, such as stalled ERP replacement projects, postponed remediation projects for non-critical applications, and clean-up work for Year 2000 triage and fallout, and our CIO is facing a mountain of work. Sorting through these projects, culling obsolete or redundant items and prioritizing the remainder, will take time and effort.

  • A new crop of legacy applications. For many people, the term "legacy applications" is synonymous with old COBOL programs. In reality, many types of applications, including some newer ones such as neglected client/server applications, fall under the "legacy" umbrella. Many of these systems, in their current state, will not support recent technological advances such as e-commerce or philosophies such as customer relationship management. The Year 2000/COBOL work force does not have the skill set to handle these systems, and new hires all want to work on cutting edge technologies, not the "old" applications written last year. Newly out of vogue languages and environments are also consigned to the legacy scrap heap. The CIO must decide whether to euthanize or upgrade these legacy components.

  • Increased executive scrutiny. If data warehousing and business intelligence technologies were the impetus for elevating our CIO to the executive level, Year 2000 was the catalyst for putting the CIO into the hot seat. As the Year 2000 furor subsides, the CIO can expect an executive backlash. Why? Because our CIO had the distinct pleasure of informing his boss, the CEO, that IT

    • could not identify all of its assets, applications and systems (thus the time and expense to build an inventory),

    • needed tons of money to fix the problem (with no obvious competitive advantages),

    • had to build costly test environments for the fixed systems ("you mean you weren't testing before???"),

    • could not meet the project deadline without the help of outside consultants, and

    • demanded loyalty bonuses to boot!

The Year 2000 debacle has demonstrated to more than one CEO that IT is not a core competence of the company. The CIO can expect tremendous pressure to outsource IT functions to those entities for whom IT is a core competence, particularly the outside consulting firms that have already proven themselves on the Year 2000 project.

  • A new legal environment. It took hardly any time at all for lawyers across the U.S. to realize that Year 2000 was a legal bonanza. The Year 2000 problem has created a new crop of lawyers trained to ferret out and pursue software-related lawsuits, and don't expect them to disappear anytime soon after the year 2000. This new legal climate will exert pressure on not only software companies but all creators of software to perform their craft more diligently and prudently than ever before. Legal liability will loom for those companies whose software fails to meet the legal standards defined by the myriad of expected Year 2000 lawsuits. Internal legal departments will have a greater awareness of IT issues, and will demand that IT adopt more protective measures. The CIO will have to ensure that the IT organization has the proper procedures and safeguards in place to comply with the new legal climate.

  • Employee issues. Treatment of loyal Year 2000 staffers will be an especially sensitive task; if they are handled irresponsibly, what are the chances that anyone will volunteer for the next unglamorous project? Not only will companies have to determine how to reward the loyalists, they will also have to decide how to re-deploy them. Many Year 2000 staffers are well versed in COBOL, but is this a strategic skill for the 21st century? While there is no sign that the demise of COBOL is imminent, most companies will no longer have a need for as many COBOL professionals. The CIO will need a plan to re-deploy and re-train many Year 2000 workers, while taking advantage of those with portable expertise on other strategic endeavors.

As if these issues weren't enough, our CIO also has to deal with the technological breakthroughs that have transformed, and are transforming, the way that companies do business. The Internet, intranets, extranets, business-to-business systems, ERP, customer relationship management, enterprise application integration, e-commerce, web-based development and more have overtaken traditional ways of doing business and delivering products and services. Our CIO must understand how to harness each new wave of technology not just to support the business, as in the past, but to transform it.

A CIO Action Plan

In the post-2000 world, the CIO certainly has a lot on his or her plate. With the issues above looming on the horizon, the CIO must develop an action plan to address each item, determine short and long-term priorities and strategies, and identify some tactical steps that will begin the process of moving in the right direction. As the CIO composes this action plan, the following four guidelines should be applied.

  1. Learn from Year 2000 experience.

The Year 2000 problem was not a date problem -- it was a massive interface problem requiring cooperative effort among thousands of independent entities. Our applications and systems today are maximally interconnected, both internally and externally, such that a small change in one place can have a widespread ripple effect among hundreds of organizations. Given these interconnections and interdependencies, which will only grow over time, it will become increasingly more difficult to coordinate large-scale changes (EDI upgrades, Euro, ZIP+4, etc.). Yet, the CIO must plan for the inevitable Year 2000-like projects and problems to appear.

There are several positive things that the CIO can do to learn from the Year 2000 experience. First, attack the organizational weaknesses exposed during the Year 2000 project. Many companies suffered from procedural weaknesses in their configuration management and source code control, inadequate test environments and nonexistent inventories, to name a few. Lack of standards and common routines (particularly date routines) exacerbated the problem. Weak project management and estimation skills further hampered companies' ability to manage and track the progress of Year 2000 projects. Act now to address these weaknesses. Re-examine and strengthen environments, tools and procedures to manage and test IT assets; seek and train those individuals having an aptitude for project management.

Second, IT organizations should proactively manage their portfolio of applications and technologies. With the Year 2000, companies waited until disaster time before dealing with a known problem. Don't wait until deficiencies or problems escalate and become so widespread that they are insurmountable. Schedule maintenance, upgrades and renovations as planned activities.

Third, reduce the complexity and risk of IT work by reducing the inventory of IT assets. Year 2000 projects finally provided the impetus for IT organizations to review, discard and catalog their portfolio of applications and technologies. But there is still more to do. For years, obsolete, redundant and unused components had been retained in source code libraries, or remained in production, rather than eliminated for fear that someone might need them. By culling out unnecessary items, and keeping the portfolio scaled down, IT organizations can greatly simply the scoping of future projects.

Finally, reward loyal employees who volunteer to work on projects that are critical to the company, but less glamorous or interesting than others. Recognize and promote Year 2000 volunteers ahead of Year 2000 avoiders. These steadfast employees have in many cases virtually saved their companies from financial ruin. The CIO should also leverage the project management and testing skills honed by Year 2000 team members on future enterprise projects.

  1. Reuse and extend Year 2000 components.

Many components of the Year 2000 project, including organizational structures, processes, plans and environments, have value beyond the year 2000. It would be foolhardy and wasteful to discard them. These items can be applied to other projects, or incorporated into routine IT practices where they will continue to produce benefits. Among the most notable and valuable Year 2000 components to retain and reuse are:

  • Program Management Offices -- the organizational structures responsible for managing the diverse people, process and technology resources in the Year 2000 effort. Staffed by people from areas across a company, these managers coordinated the myriad individual projects throughout the enterprise, striving to keep the overall project within budget, on time and with specified functionality. These people are skilled in communications with both internal and external parties, are adept at handling resource issues and have accumulated much knowledge about company operations. These people, and this type of management structure, are invaluable for any type of large-scale, enterprise-wide implementation.

  • Contingency Plans -- the strategies for identifying and coping with anticipated, and unknown, Year 2000 problems or failures that affect the critical company operations. These plans are equally applicable to many other types of "disaster" situations, even when the Year 2000 is not the root cause of the problem. For instance, product recalls, physical disasters and environmental problems are issues that can be addressed by adapting Year 2000 contingency plans. These plans must be kept current, however, to ensure that they are usable when unexpectedly needed.

  • Crisis/Transition Management components -- the structures and procedures for handling and processing Year 2000 problems that actually materialize during the century transition. These components identify the teams of people responsible for detecting, tracking, fixing and escalating problems, and define formal methods to communicate status information to internal and external parties. Although it is probably unnecessary to retain the physical Year 2000 crisis management center, the plans and procedures should be kept intact to ensure that any type of large-scale problem can be dealt with expeditiously.

  • Inventories -- the itemized listing of all IT assets, including applications, environments, desktop components, etc. that were compiled at great cost to guide Year 2000 compliance analysis. In many cases, these inventories also contain information about system dependencies, languages, releases and other pertinent facts. This data is essential in any large-scale implementation, and useful in any type of system analysis task. While it does take time and effort to maintain an up-to-date inventory, it is worth the investment. Otherwise, IT organizations will have to recreate inventory data at the outset of any large-scale project in order to perform scoping and impact analysis tasks, leading to a waste of time and money.

  • Testing procedures, tools and environments -- the components necessary to ensure that remediated applications and systems are century-compliant. Many companies invested the majority of their Year 2000 budgets and time in building more robust testing practices and environments than were previously available. These items are invaluable for any type of IT project, whether a small-scale modification to an existing system or a brand new application, as are the testing skills gained by Year 2000 workers. IT organizations should continue to build upon these solid testing foundations to incrementally improve all facets of testing practices.

  • Documentation practices -- the procedures adopted by Year 2000 teams to track and memorialize project plans, schedules, testing results, etc. IT teams find documentation beneficial to gain familiarity with an application and to create a historical account of changes, enhancements, test scripts, etc. Documentation also has a legal angle. Often instituted at the behest of the legal department to establish a record of a company's due diligence in the event of lawsuits, documentation practices will become more important if a new legal climate of software accountability takes hold in the aftermath of the Year 2000.

  1. Re-examine IT core competencies.

The Year 2000 crisis showed many CEOs that IT is not a core competence. Little wonder when some major companies, at the start of 1999, had spent less than 10% of their Year 2000 budgets!2 Now the CIO will have to take a hard look at his or her IT organization and realistically evaluate its strengths and weaknesses. Any task or function that is not a core competence should be a candidate for outsourcing to other entities who have demonstrated their competence in that area. Outsourcing comes in a palette of options. IT organizations can choose to purchase packaged software instead of developing applications in-house, effectively outsourcing the development to a software package vendor. They can also identify and parcel certain tasks or functions to consulting firms who have skills, methodologies and best practices, i.e. a "core competence," in performing that work. In addition, the CIO should evaluate sourcing alternatives to try to make an immediate and substantial reduction in the Year 2000 deferral backlog.

  1. Prepare for the new legal realities.

If the wave of Year 2000 litigation hits as predicted, the fallout will reshape the way that we build, test and sell software. As courts and lawyers wrangle over legal liability and responsibility in the software realm, they will establish new standards of reasonableness for the software industry. The CIO will have to deal with this new reality by affecting change within his or her IT organization. Clearly, the CIO will have to improve control over software quality through the adoption of new standards for development, and enhanced testing practices and reviews. Project documentation, from schedules to change logs to testing results, will have to be recorded and retained to establish that software practices comply with the new standards and procedures. Legal and risk management departments will require more frequent audits to ensure that the processes are working as planned, and are being followed by IT. Depending on the outcome of the anticipated Year 2000 legal battles, we could even witness requirements such as programmer certification or software development liability insurance.

Conclusion

When our CIO looks back on the Year 2000, it will become apparent that it was more than just the project from hell, it was a forced transition between the old IT regime and the new one. IT will never be the same again. The worse the fallout from the Year 2000 -- the more inconveniences experienced by the public -- the greater the IT backlash and the greater the pressures for IT to change. The successful CIO will take advantage of the Year 2000 to usher in a wave of changes. The others will be swept away by that change. Let's face it, with the complicated and interwoven applications and relationships that exist today, there will be a Year 2000-scale problem sooner than later. Will IT remain in a perpetual mode of crisis? Or will the savvy CIO lead the way to a brighter future?

Footnotes

  1. Source: Triaxsys Research LLC Press Release dated May 5, 1999 containing results of a study of the SEC filings of the 1,000 largest U.S. companies.
  2. Source: Triaxsys Research LLC.