Strategic Management of Information and Communication Technology: The United States Air Force Experience with Y2K (2007)

The previous chapter presented complexities associated with information and communication technology (ICT) systems in general, and within the United States Air Force (hereafter simply USAF, or Air Force) in particular. It also presented an overview of the Year 2000 (Y2K) problem and response efforts. This chapter and the two that follow bring these areas together by looking at the Air Force Y2K experience as a source of information for improving the operational and strategic management of complex and critical ICT systems. This chapter focuses on ICT management challenges stemming from system complexities. Chapter 3 focuses on organizational issues, particularly the role of organizational entities in the establishment and execution of ICT management strategies. Chapter 4 focuses on risk, response, and security issues. As will be seen, there is critical linkage across these three areas of “lessons learned.”

On the surface, the whole Y2K story seems incredible: Between 1995 and 2000, a problem about assumed century digits in date representation came to be seen as the most significant challenge facing many, if not most, organizations in the world. For many people in the Air Force, it became “the #1 thing we’ve got going” (AFCA). Even more surprisingly (and far less well known) was that the problem with century digits ultimately taught those who worked on it more about their overall organizational operation than about their technology.

What follows is a discussion of the lessons learned by people and organizations as they attempted to address Y2K within the context of general ICT system complexities. These lessons are relevant to the ongoing management of other current and future ICT problems and opportunities.

The magnitude of the Y2K response was greatly increased by less than optimal efforts to manage the situation. Y2K represented a class of ICT issues that go beyond the functional management of individual systems or localized clusters of technology. Thus, traditional localized management strategies were often defeated not only by the particular pressures of the problem at hand but also by the intermingling of that problem with other ongoing pressures stemming from the increasing complexity of and reliance on ICT systems.

It was difficult to break down Y2K activities into clearly bounded efforts under local control. The interdependency of ICT elements and the varying roles of ICT in achieving organizational missions meant that no single group could fully control the

issues. Enterprise-wide perspectives and nontechnical environmental impacts had to be considered. ICT managers recognized that these challenges were not unique and that the difficulties of Y2K management were symptoms of difficulties with the ongoing management of ICT: “These problems were not unique to Y2K. …They exist as part of the normal information technology day-to-day business. …We were doing business as usual, but we need to come up with a better business as usual” (AMC/HQ).

The ICT infrastructure of a large modern organization is extremely complex. The more an organization relies on information within that infrastructure to achieve its mission, the more complex its management task. In simple terms, a complex system is one in which the whole is greater than the sum of its parts. Traditional management strategies assume that the systems being managed can be broken down into discrete component parts and clear, causal relationships among those parts. However, this assumption is no longer valid for systems that have reached a sufficient complexity. “Compared to the analytical procedure of classical science with resolution into component elements and one-way or linear causality as basic category, the investigation of organized wholes of many variables requires new categories of interaction, transaction, organization, teleology, etc., …” (IEEE 1999).

Neither ICT systems nor the organizations within which they reside are closed systems; in other words, they cannot be understood and managed independent of their interactions with other systems and, particularly, with their environment. “To conceptualize an organization as an open system is to emphasize the importance of its environment, upon which the maintenance, survival, and growth of an open system depend” (Malhotra 1999).

Under the pressures of Y2K, the need to manage ICT systems as organized wholes was even stronger than during periods of business as usual. In addition to the general complexity of ICT systems, Y2K brought into play two additional major complicating factors. First was the perception that everyone would be impacted in the same way and at the same time. “During Y2K we were doing so much sharing because we had a common enemy and a common deadline” (MITRE). Second was the perception of a specific, fixed deadline for the effort. “Y2K was different. …We had a compressed time; we had some milestones that weren’t going to change or move and [they were] related to coding and dates and what the impact would be if we didn’t fix those problems embedded within the code. Out of that we’ve learned so much more about the way we really do business and rely on one another” (AFY2KO).

The perceived combination of a common enemy and a common deadline contributed to an increased awareness of the interdependencies and shared responsibilities of the various ICT efforts across an organization. (Additional elements of the Y2K experience that contributed to this awareness are discussed below.) This in turn helped foster the idea that these functional elements of the Y2K effort needed to be brought together under a single, more encompassing management perspective, at least for the duration of the effort.

Y2K helped teach organizations that ICT management was not a piecemeal effort. Under the added stresses of the Y2K situation, the limitations of focusing on localized clusters of technology became more evident. As efforts to respond to Y2K within business-as-usual management practices were found to be insufficient or impractical, new

strategies and tactics arose that were more representative of the complex, interdependent aspects of ICT systems.

The following lessons discuss many of the shifts away from traditional information technology (IT) management that were instigated or emphasized by the Y2K experience. Chapter 3 explores these shifts further in terms of specific organizational entities and roles.

During Y2K, breakdowns in traditional management of the situation began at the most basic, definitional levels. Efforts to decompose the Y2K problem and organizational responses into discrete components were largely unsuccessful. As a result, attempts to carry out a Y2K response strategy based on classification and stratification of ICT systems and problems, though not without some benefit, generally had minimal impact on frontline response activities. Difficulties in breaking down the problem stemmed not only from technical complexities but also from conflicting multiple perspectives and the impacts of nontechnical environments.

At different times during the Y2K response process, most organizations made efforts to stratify the various potential problems according to such identified criteria as criticality to mission, likelihood of occurrence (see the discussion of risk in Chapter 4), local conditions, and optimal response strategies. For example, a common component of strategies for dealing with Y2K (or any widespread threat that taxes available resources) was an attempt to classify systems by their criticality to the organizational mission and then focus efforts on those systems deemed most critical. In the Air Force, this “triage” strategy led to central guidance asking units to classify systems into categories C1, for most critical, through C4, for least critical. “Air Force Core Capabilities form[ed] the basis for determining critical missions and functions” (USAF 1999b), but complexities like those discussed in Section 1.1 meant that the translation from critical missions and functions to critical systems was not straightforward. As a result, Air Force Y2K activities found it difficult to tailor their response tactics to individual classes of Y2K problems or to local environments. Instead, Y2K was treated as a generic threat rather than what it was—a set of specific interdependent threats, each with varying factors of risk and impact and each best addressed using varying response tactics. “I’ve been doing this job for two and a half years. The Y2K orders have been…consistently ‘check everything’ with no real shift” (374^th OG).

There were benefits from efforts to classify systems and problems, particularly at the most critical, “thin line”¹ level, as well as in focusing people’s attention on organizational aspects of the Y2K situation. However, as a guide for the overall Y2K response activities, these classification efforts generally proved ineffective.

The lack of problem stratification was particularly felt in the complex logistics area.

At times, this lack of problem stratification could be extremely frustrating, especially given the effort put into classification.

Why did efforts to stratify Y2K systems and problems have limited impact? Air Force efforts to categorize systems by their mission criticality were hampered by both technical and nontechnical factors. On the technical side, system complexities made it difficult to isolate ownership and roles of specific system features and elements. This complicated the task of determining both responsibility for and criticality of systems. Many were concerned about fragmentation of management responsibility. “What if we had had a bunch of Y2K failures? What kind of finger-pointing would have gone on initially between saying ‘Oh, that was an application problem. No, that was an operating system problem. No, that was a hardware problem’” (MSG).

Even more significant, however, were the nontechnical factors. With the lack of clear technical criteria, political, financial, and other systems that composed the ICT environment became central to the definition of mission critical.

System criticality could not be assessed using purely technical or mechanistic means. Even as ICT complexity made it difficult to identify the boundaries and roles of any given system, the interplay between technical systems and their nontechnical environments dynamically affected basic definitions, such as the notion of what constituted a mission-critical system.

Similar to the difficulties in clarifying the definition of mission-critical systems were key definitional uncertainties surrounding the concept of “Y2K compliant.” In other words, how was anyone to know when a system was okay or had been fixed? The certification of a system as Y2K compliant was seen as an essential step in the overall Y2K remediation effort, and the media used this phrase incessantly. Yet, despite its perceived importance and wide use, the interplay of multiple systems and perspectives made it extremely difficult to define and apply this critical concept.

Why was it so difficult to recognize the behavior of a system that was free of Y2K problems? Remember, compliance is not an abstract idea but, rather, is about complying with something (that is, a guideline or standard). Yet most people, particularly the media, used the phrase “Y2K compliant” simply to mean “fixed,” without any notion of the guideline being met. The people responsible for certifying systems, however, required more precise definitions and test procedures for determining Y2K compliance. Specifically, they needed a clearly specified, testable definition of the desired behavior; a specified period of time (that is, range of dates) over which this behavior needed to occur; and specified conditions under which this behavior could be expected.

In the United States the most common definitions of Y2K compliance were adopted from language in the Federal Acquisition Requirements (FAR). Under FAR compliance, the desired behavior was “able to accurately process date/time data”; the period of time was “from, into, and between the twentieth and twenty-first centuries, and the years 1999 and 2000 and leap year calculations”; and the conditions were “to the extent that other information technology, used in combination with the information technology being acquired, properly exchanges date/time data with it” (FAC 1997). While this language was useful from an acquisitions perspective, definitions of Y2K compliance adopted from the FAR were not very useful for the testing and certification of systems. Acquisition is a critical ICT activity and organizational component, but it is only one of many perspectives that must be balanced in the management of ICT.

First, the FAR definition of desired behavior relied on such words as “accurately” and “properly,” which were not sufficiently defined for use in testing and certification. Did “accurately process” mean “give correct answers” or “not break down”? ICT systems often give incorrect answers and often break down, independent of any Y2K issues. These vague words may have been useful in government contractual agreements, perhaps allowing for broad interpretation between parties, but they were not useful to ICT professionals seeking to test system behavior.

Second, the FAR language on the time period, while vague, could be interpreted as requiring systems to accurately process for two centuries (1901–2100). Again, this broad coverage may have made sense from an acquisitions perspective, but it made little sense from a technical one. The most common operating systems of that time could not meet this requirement, with the operating range of Windows beginning on January 1, 1980, and the operating range of UNIX ending January 19, 2038.

Third, the conditions under which accurate processing was expected to occur included “proper” date exchange with “the information technology being acquired.” Again, the language was too broad to support specific testing. Even more important was the assumption that the technology under consideration was being acquired. This certainly made sense within the context of the FAR, but when this language was adopted in general definitions of Y2K compliance, it contributed to misunderstandings. Y2K was often seen to be primarily about modernization (that is, acquisition), when in most cases it was about maintenance (that is, keeping existing ICT functioning in a predictable manner). This is another example of how the multiple perspectives of people involved with ICT complicated not only the resolution of Y2K problems but also the understanding of the problems to be addressed.

Particularly during its early stages, Y2K was more about understanding the problem than addressing it. And throughout the dynamic Y2K experience, definitional complexities stemming from localized, loosely coordinated management strategies continued to make it very difficult for organizations to establish and apply precise problem definition and stratification. For these and other related reasons, there tended to be a generic, relatively uniform response to anything labeled as Y2K, even though Y2K consisted of a set of nonuniform problems occurring within nonuniform environments. Hence, Y2K helped teach organizations that even at the definitional level, ICT management can be more about balancing multiple perspectives and environmental impacts than it is about precise technical specifications.

In addition to definitional issues, Y2K highlighted other ICT complexities that challenged existing management practices. Many of these called for a shift in ICT management focus from hardware and software to data, knowledge, and organizational goals. It is not surprising that traditional IT professionals and the organizations they work for see hardware and software as the central elements of their systems. These IT professionals come from an educational and training background where the difficult subject of computing (namely, hardware and software) has been their primary element of concern. This knowledge is critical, but people involved in Y2K remediation efforts found they could not limit their activities to issues involving computers, communication devices, operating environments, and application software (see Section 2.3.2.2.). Increasingly over the course of their Y2K experience, these people were called on to address issues involving the generation, capture, manipulation, sharing, and use of data and knowledge in the pursuit of organizational missions.

From the computer-centric perspective of traditional IT professionals, the operational use of data is separate from the system that is their primary concern: “Within AMC [mobility command] the SC [communications] organization actually does the command and control systems. We develop them; we operate them; we maintain them. We’re not the ones who put the data in…we have an operational organization” (AMC/SCA). From this perspective, data simply “feed” the system. But Y2K reminded

us that data are more than numbers being eaten, crunched, and spit out by hardware and software.

Many complications in the Y2K remediation effort stemmed from the fact that data exist within a database and that databases do many things. Of course, databases specify data formats, which was a central aspect of the Y2K problem.² However, databases are also a compilation of the data types an organization considers worth capturing and specifying. In other words, databases represent the entities of interest to the organizations that use them. Databases also represent the relationships among those entities. They represent the questions that an organization wants to be able to answer and how they go about answering them. In the largest sense, a well-constructed database represents how an organization views the world and how it conducts its business.³

Over the course of Y2K, it became clear that changes made to hardware and software generally did not address the central Y2K data and database issues. Early on, Y2K was often viewed as a technology modernization issue involving older mainframes and legacy software created decades earlier. The problem was “a vestige from the bygone times of computer technology, when memory was expensive” (USA Today 1997). But organizations that took on Y2K within the context of general efforts to modernize technology found themselves facing two highly intractable and only loosely related problems. Arthur Gross, then Chief Information Officer (CIO) of the Internal Revenue Service, said that combining Y2K and modernization efforts reminded him of the scene in the movie Butch Cassidy and the Sundance Kid when Butch and Sundance find themselves trapped by Mexican soldiers on a high cliff overlooking a river. “I just remembered I can’t swim,” says Sundance. “It doesn’t matter. The fall will kill you,” replies Butch. While both efforts were critical, they were distinct and often incompatible. Y2K was about maintaining a consistent, predictable existing function, while modernization was about replacing old equipment or adding new technology and function.

While changes to hardware and software did not generally address fundamental Y2K issues, changes to data formats in databases required associated changes in any module that read, processed, or transferred the newly formatted data. For this important class of problems, the flow of data was the driver, not hardware, operating systems, or software. Thus, Y2K fostered a perspective in which data held the central position, with hardware and software needing to be adjusted to continue serving that data. (This perspective is consistent with the fact that hardware and software change rapidly, while data and databases change rarely and only at great cost.)

Furthermore, Y2K reminded us that problems with data can have disastrous implications independent of whether the hardware and software are performing as intended or not. Data corruption could be a greater concern than system failure. “JACAL is a warning system, and if data [are] intentionally corrupted…and then sent to an installation—that’s what we do our maintenance on. If it’s the wrong information—a

slight miss torque on an egress line on an A-16, that could kill a pilot. …I’m concerned about somebody getting bad information into a system that we rely on for operations” (AFCIC/SY). Here, the central driver goes beyond the data to see how people use data to generate information that is essential to accomplishing an organizational mission. Over the course of the Y2K effort, the central focus shifted from hardware and software to data and information and, ultimately, to how people use information to achieve organizational goals.

Y2K encouraged organizations to reverse the commonly held perspective of computer-centric IT management by emphasizing the central nature of data as they are used in the accomplishment of organizational missions. Data and the databases within which they reside represent the core knowledge of an organization, and an organization faced with saving either their processing systems or their data will choose the data. For many IT professionals this represented a new perspective on their systems. Data, databases, and the knowledge they represent were increasingly seen as holding a stable central position, with computers and software constantly evolving to assure that people could use the data and knowledge to achieve organizational goals.

The increasingly information-centric perspective of ICT fostered in part by Y2K did not just mean that traditional IT professionals began to view data, information, and knowledge as holding a more central position in their world. It also meant that many operational and strategic managers who had previously seen themselves to be on the periphery of the ICT world (if not completely outside it) suddenly found themselves thrust into its center. This coming together of operational and ICT managers was one of the most significant outcomes of Y2K. For many organizations (including the Air Force), Y2K instigated the first large-scale, formal effort to align ICT management with operational and strategic management.

Generally, IT management and the strategic management of an organization have differed significantly. IT management has focused on acquisition and keeping technology working within an imperfect world where failures and fixes are a common occurrence. In this world, correct decisions about hardware and software, based primarily on technical knowledge, result in relatively short-term system improvements, such as restored or improved functionality, increased compatibility, and easier maintenance.

On the other hand, strategic organizational and business decisions are seen as being more pervasive, with longer-term impact on a wider range of the enterprise. Strategic decisions are generally the result of a negotiated consensus process within a dynamic context of shifting economic, legal, and political forces. The goal is to achieve an accepted best direction based on appropriate trade-offs and compromises. While the nature of this decision is complex, once it is made there is little tolerance for error and miscalculation. To a strategic planner, failure is a career-threatening event; to an IT manager, failure is part of the job. This is one example of the differences in perspective, focus, and knowledge that can result in a gap between ICT and strategic management, and both sides can help create this gap. “Managers have often delegated or abdicated

decisions to information technology professionals… [while] poor specification of strategic objectives often leads to the information technology group setting an information technology strategy in isolation from the business” (Weill and Broadbent 1998). Where gaps between ICT and strategic management existed, Y2K highlighted both the difficulty of bridging them and the critical importance of doing so.

As Y2K evolved from a primarily technological to a primarily mission-oriented issue, IT and operational personnel were drawn together in new ways. These two groups, generally with differing backgrounds, perspectives, and corporate cultures, found themselves sharing responsibility for what had become a complex, dynamic, high-priority, organization-wide project. Not surprisingly, this coming together of IT and operational managers under difficult and stressful conditions was not without its problems. “Y2K was not just a common computer problem but also a mission problem. …When we got all the different functionaries involved in it, that tended to complicate things. There were times when coordination between the different functionaries was difficult, at best, or lacking, at worst” (AMC HQ).

Coordination issues were complicated by the fact that IT professionals and operational managers had differing perceptions of the Y2K situation and response effort. Of particular relevance was the considerable difference in their understanding and acceptability of risk and error. As mentioned earlier, IT professionals were in an environment where risk, and even breakdown, was far more prevalent and acceptable. For these professionals, any change raised the possibility that, even with testing, catastrophic problems could follow. “Everyone who’s dealt with software knows that [but] senior leadership…has an absolute unawareness that this is the reality…we live in every day” (AMC/SCA).

Over the course of Y2K, the wide range of perspectives on ICT caused different people to have very different responses to the same situation. For example, when Y2K was still seen primarily as a technical problem, frontline Y2K workers found it extremely difficult to obtain resources from higher-level IT managers who were used to dealing with potential failure and whose primary focus was on keeping their technology functional.

Later, as Y2K evolved into an operational issue, another set of differences developed—this time between these same IT managers and the more mission-focused operational managers who gradually took over leadership of the Y2K process. The far lower tolerance for uncertainty of operational managers contributed to a far greater availability of resources devoted to Y2K. But this reduced tolerance for risk could be extremely irksome to IT managers, who lived on a day-to-day basis with the development, operation, and maintenance of highly sensitive and often unreliable ICT systems (see Section 1.1.4). “During Y2K there was zero tolerance of risk because of ignorance on the part of people looking for certainty. An engineer knows that there is

always a probability that things might not work” (AMC/SCA). (Risk and response are discussed in more detail in Chapter 4.)

While the differences between traditional IT managers and operational managers could be significant, something even more significant was strongly emphasized by the Y2K experience: the absolute necessity of bringing together these two groups under a single strategic umbrella. This recognition became clear even to those who most experienced the difficulties of trying to make it happen. As sAMC/HQ stated: “We need to take the information sharing we had—take the things that we learned from getting the operational people involved in it and looking at it not just as an IT problem but, everybody uses it, it’s a problem throughout the business that we do—and we need to manage it that way. And we need to make that business as usual.”

The growing perception of Y2K as a mission problem served to emphasize the cross-functional nature of ICT and the increasingly central role of the new information infrastructure in achieving the strategic goals of an organization. The overriding lesson was that the organization had to incorporate its management of ICT within its overall operational and strategic management: “The entire information technology portfolio…must be managed by a partnership of business and technical management to create business value. …In most businesses, deciding on information technology capabilities is far too important a strategic decision to be left to the technical people or, worse, to the outsourcer with its own business objectives and need to make a profit…” (Weill and Broadbent 1998). To align ICT and operational management, organizations need an effective enterprise-wide information strategy based on achieving organizational goals.

As Y2K evolved from a primarily technological to a primarily operational effort, it brought home the need to align ICT and strategic management. The experience of addressing Y2K reminded organizations that the ultimate goal of ICT was not the continued functioning of local clusters of technology but, rather, was the effective use of information in support of strategic goals. This lesson was particularly important to government and military organizations less driven by the demands of private enterprise and more likely to think of ICT as secondary support rather than as a major component of their operational product. The USAF was a prime example of an organization that faced this lesson as its Y2K effort evolved from IT leadership to operational leadership.

Differences between traditional IT managers and operational managers were not the only organizational gaps that needed to be bridged in order to effectively address Y2K (or, more generally, to effectively manage ICT). The complexity of ICT makes it easy for people with differing perspectives to view the same system very differently.

Probably the most common perceptual barriers that had to be overcome during the Y2K effort stemmed from the organization of most corporate, governmental, and military entities into functional units. A worker’s functional location impacts nearly every aspect of her or his organizational life. Information flow is a major component of this impact. In most organizations, information sharing “is usually up and down the structural hierarchy—up to superiors and down to subordinates—within functional boundaries”

(Davenport 1997). While there are many situations where it is entirely appropriate for workers to focus on their particular functional niche, most high-level operational and strategic objectives require integration across functional lines. In these situations, “stovepipe” perspectives can result in damaging operational and communication barriers. The Y2K situation emphasized that ICT is one such critical cross-functional activities, in which success often depends on overcoming stovepipe perspectives and actions.

Because of their structure and culture, military organizations are particularly susceptible to the problems that can result from the stovepipe effect. Fortunately, when faced with achieving cross-functional goals, leaders at the highest levels of these organizations recognize the importance of getting people to look and act beyond their particular area of the overall operation. For instance, “the integration of our aerospace forces and people is a critical element of our plan. This process will break down stovepipes between air and space, leading to integrated solutions with air and space systems that are more effective and efficient than separate systems” (Peters 2000). Nevertheless, even with this high-level recognition of the issue, cross-functional management of enterprise-wide projects can be extremely difficult to achieve.

During Y2K, the need to overcome functional barriers in the management and operation of ICT was particularly evident. As Y2K progressed, issues initially viewed as isolated within a particular technology under the control and responsibility of a particular functional area became increasingly intractable as those issues cut across technologies and functions. These cross-functional complications generally began at the level of ownership and responsibility issues and progressed to operational, strategic, and legal issues.

For example, most organizations began their Y2K efforts with a unit-by-unit inventory and assessment of at-risk technology (for the USAF this was called the Air Force All Systems Inventory, or AFASI). Yet, even at this early step, it could be difficult to maintain a functional unit perspective, particularly where ownership of and responsibility for systems were unclear. Whose name went into the inventory as owner of a given system that was paid for and developed (in conjunction with an outside vendor) by one functional unit, used by a number of different functional units, and supported by yet another functional unit? Who was responsible for certifying this system as Y2K compliant?

Given the pervasiveness and interdependency of system elements, tensions could arise that were difficult to resolve through central guidance. For instance, “[AMC] had an argument with ESC (Electronic Systems Center) that lasted for months over who the ‘owner’ [of certain software] was. Other systems have had the same argument over ownership” (AMC HQ). Or, “In AFASI there was a Sponsor, Owner, and PMO (program management office) field. Folks sorted out who these were on their own” (AFCA).

During Y2K, functional unit perspectives were further blurred by the central role of data. Section 2.3 discusses how changes to data formats were greatly complicated because databases not only contain instances of data but also represent how an organization views the world and conducts its business. Beyond this, database change was further complicated by the fact that data are commonly shared across systems. This meant that changes to one database owned by one functional unit could lead to the need for coordinative changes in other databases owned by other functional units (as well as

coordinative changes in all the software that read, manipulated, and transmitted that data). Another complicating factor could occur when one functional unit owned a system, but another unit owned the database (SSG).

All of these interdependent complications contributed to a highly uncertain atmosphere wherein no single functional unit could declare with absolute certainty that its systems would work in the face of Y2K. When these units turned to the makers of their system components to provide some answers, the same uncertainty, again stemming from the interdependencies of those components, was evident in the highly qualified statements of Y2K compliance that were provided.

(Chapter 4 looks more closely at the impact of this atmosphere of uncertainty on Y2K risk assessment and response tactics.)

Another complication of the Y2K effort was the common occurrence of multiple sources of guidance. This complication stemmed from the application of functional perspectives to what was a cross-functional issue. Stovepipe Y2K management efforts often meant that Y2K workers had to be aware of and respond to numerous overlapping sets of directives. In many cases, this contributed to a significant increase in workload.

One medical division was particularly impacted by underbudgeting man-hours for Y2K. As of December 1999, this division estimated more than 4,000 hours of additional Y2K-related effort. More importantly, they indicated that they had to respond to guidance from five different units, and they estimated that approximately 50 percent of their effort was spent in dealing with multiple guidance and policy. This was not an isolated situation nor was it limited to the Air Force.

“A lesson from Y2K is that we have underestimated the workload, the amount of tasking involved in communication, and the work involved in keeping up with directives and changes to the directives” (USFJ). In part, multiple Y2K guidance occurred because no single functional unit could adopt a response strategy

that adequately addressed the spectrum of uncertainties stemming from cross-functional interdependencies. For this reason, many large, multifaceted organizations found it necessary to establish a temporary cross-functional entity to oversee Y2K efforts (for example, the President’s Council on Year 2000 Conversion). These entities tended to be operationally oriented, focusing more on mission capabilities than on specific technology within functional domains. As stated in the Department of Defense Year 2000 Management Plan, this meant that “progress will be measured not in terms of numbers of systems fixes, but in terms of warfighter mission readiness unimpeded by Y2K glitches” (USAF 1999b).

Through the use of these temporary cross-functional entities focused on “mission threads,” attention could be paid not only to the functional nodes of an organization’s information system but also, more importantly, to the links between those nodes. In the Air Force, this temporary entity was called the Air Force Year 2000 Office (AFY2KO). Chapter 4 looks more closely at the role of the AFY2KO and other Air Force organizational entities involved in Y2K, including examination of the issue of whether such a cross-functional entity is desirable on a more permanent basis.

There were many reasons for the often fragmented, piecemeal organizational perspective on Y2K. Faced with a complex, uncertain situation, people tended to fall back on what they understood best—their own particular corner of the organizational and ICT world. In addition, day-to-day operational issues and functional demands made it extremely difficult for individuals to keep in mind the cross-functional interdependencies of their systems as well as their roles in the overall flow of data and information to achieve organizational goals. Finally, organizational territorial issues and the mechanisms for funding systems worked against a cross-functional perspective, as with MSG: “We really didn’t understand the configuration of our system of systems. That problem is exacerbated by the way systems are viewed and, more importantly, by the way systems are funded. They’re funded individually as a system, and so there is no real impetus to look at it as a system of systems.”

In many cases, these same issues continue to contribute to a fragmented approach to the ongoing management of ICT in general. “The Air Force’s [information] efforts may not be as well integrated as they should be, which may result in duplication of effort and inefficiency” (USAF deputy chief of staff for air and space operations, reported in USAF 2000c).

Fortunately, the Y2K experience confronted many key people with the limitations of relying on piecemeal, functional perspectives to manage information and communication technology. Managers of the overall Y2K effort came away realizing they had been forced to fill in gaps that existed in the business-as-usual management of ICT. They realized that, from a mission-oriented perspective, ICT management was more about sharing ideas, developing appropriate trade-offs, and balancing competing “goods” than it was about making correct technology decisions. In other words, people need to be taught about teaming, sharing ideas, and working with one another cross-functionally as they enter the business. To do this: “we have to break down the barriers and walls both organizationally and procedurally, from a policy standpoint and from a security standpoint. There are some things that we’ve created over the last 50 years…that will keep us from being flexible in how we adapt to this kind of business in

the future” (AFCIO/AFY2KO). Thus, Y2K helped teach organizations the necessity of breaking down functional barriers in the strategic management of ICT.

The media portrayed Y2K as an issue centered on computer technology,⁴ but managers on the Y2K front lines knew that far more was at stake. Previously, they had focused on specific components of their technology; now they were being called on to consider the role of that technology in the overall organizational operation. They were seeing that the interdependent elements of the ICT infrastructure were not fully under their control and could not be addressed in isolation. They were seeing that data issues could not be adequately understood independently of the interpretation and use of that data.

As this more holistic perspective grew (and as the new century approached), a change occurred in specific Y2K project goals. Whereas early on the goal had been to fix every possible glitch, the approaching deadline and increased focus on mission meant that glitches with little or no impact on operational goals could be ignored.

As organizations increasingly put their Y2K efforts within an operational context, they were doing more than simply changing specific Y2K project goals. They were also shifting the role of ICT managers from a support activity into the operational mainstream of the organization.

As Y2K progressed, ICT managers were increasingly placed in positions where their efforts were meaningful not so much because their technology worked, but because they enabled people to use data and information to accomplish operational missions. With this came a growing recognition of how the systems they managed fit into the larger organizational picture: “People saw for the first time that this information does fit together. Systems do support missions and missions do rely upon certain things. So that at least at a very high level the operational system world…suddenly came together—central management, mission funding, personnel, all these kinds of things” (AFCA). Despite this recognition, it remained a difficult proposition to develop and implement new long-term strategies for managing ICT systems.

For most technology managers, Y2K was a new organizational experience. Under previous business-as-usual practice, the investment in ICT had been essentially uncoordinated across the enterprise. During Y2K, the ICT community was called on to

play a major role in a coordinated, strategic, mission-oriented activity. As with any new role, it was not always easy, as illustrated in the following excerpts:

The fragmentation and inconsistency of ICT management stemmed in part from the operational community having a strategic perspective the ICT community lacked and needed. The Y2K experience emphasized the need for an integrated ICT strategic perspective that started not with technology but, rather, with the people in the organization who created and used information, with the nature of that information, and with the missions that people accomplished through the use of that information. “Information and knowledge are quintessentially human creations, and we will never be good at managing them unless we give people a primary role” (Davenport 1997).

Y2K taught many ICT leaders that they needed to develop an enterprise-wide information strategy that would be aligned with the overall organizational strategy. “Leaders who were actively engaged in this process, they essentially ‘saw the light.’ I think those individuals in leadership positions will carry that throughout the rest of their careers” (AFCIO/AFY2KO). This recognition among organizational leaders helped stimulate efforts to develop an overall information strategy centered on people, information, and missions.

In the Air Force, steps toward developing such an overall information strategy began shortly after the New Year.

Clearly, the lessons of cross-functional management and attention to system environments were not lost on this group of Air Force information leaders.

Similarly, on April 14, 2000, the Air Force held a workshop on the lessons of Y2K for ICT management.⁵ Again, cross-functional managers who had previously not come together found that they shared important pieces of the ICT management puzzle. They also found that these pieces would continue to be important for ongoing issues beyond Y2K. “There are some things we can do with CIP (critical infrastructure protection) and with information assurance… that will carry forth from the lessons that we learned from Y2K. Prior to this workshop that discussion really hadn’t taken place” (AFCIO/AFY2KO).

It is no simple task to keep ICT technology functioning effectively on a daily basis, and it is not surprising that ICT managers must often focus on the continued functioning of local clusters of technology. However, Y2K helped remind organizations that ICT was an enterprise-wide activity and that ICT management needed to focus on more than technology. It needed to focus on the effective use of information by people in support of overall organizational missions.

Unfortunately, the struggle to understand and manage the critical relationships among technical, human, and organizational aspects of ICT systems is a difficult and never-ending process. Not surprisingly, there are strong tendencies to revert to a less comprehensive business-as-usual approach.

Many middle-level managers learned the lessons of Y2K firsthand, but some doubt the long-term impact of those lessons on the organization. “Those of us at mid-level management will carry forward the lessons that we learned during Y2K, but I’m skeptical about how we will carry these things forward as an organizational enterprise. Because I don’t feel that we had the full buy-in throughout the organization on this problem” (AFCIO/AFY2KO).

There were a number of reasons why people who were not on the Y2K front lines would continue to view ICT management as a loosely connected, technology-focused business-as-usual activity. For one thing, most people not directly involved with the issue saw Y2K as a nonevent or, even worse, as a hoax. There had been threats of catastrophe, yet “nothing” happened. How could it be viewed as a watershed event with important lessons to teach?

Perhaps even more significantly, the crisis of Y2K forced people to grapple with complex issues that were not fully under their control. This is not a particularly comfortable position for most people. With the passing of the crisis came a natural tendency to seek a return to more familiar methods and roles. “Y2K made people do some uncomfortable things. Now that Y2K is over there will be a tendency to go back to doing it the old way” (MSG). Despite this tendency, one of the most important themes of this work is the need to retain and build on the lessons of Y2K, to resist the seemingly easy path of a return to business as usual.

Air Force ICT managers involved in dealing with the complexities of Y2K saw that existing business-as-usual practice could not deal with the situation, even

as they experienced the benefits of changing that practice. Furthermore, they recognized the “need to take some of the things we’ve been talking about [in the Y2K Lessons Learned Workshop] and make that the new business as usual” (AMC HQ).

This call for changes in ICT management practice did not suggest an absence of useful procedures in place before Y2K. On the contrary, at the tactical level, staff complained that the new processes they were pressed to use for Y2K duplicated existing structure (374^th AW/CS).

At the strategic level, however, Y2K leaders saw a clear need for change. They had struggled to fill the gaps in the overall management of ICT. They had developed an organizational context for what had been an essentially fragmented management activity. With the Y2K effort complete, they grew concerned that their newly developed context would not result in ongoing benefits, specifically, that the enterprise as a whole was not being considered. Even with a new management and policy, the strength from an enterprise standpoint was being lost, and the momentum gained through Y2K was rapidly falling away. In short, they were “losing…[their] opportunity to maintain the enterprise perspective” (AFCIO/AFY2KO).

A critical issue was that temporary organizations and money had been used to guide the Y2K effort, and as a result, no permanent homes had been established for the arduously developed policies and practices.

Despite the barriers to implementing an ongoing integrated plan for managing ICT systems, some leaders saw the lessons of Y2K to be both compelling and even inevitable.

The general lessons of Y2K were felt strongly by many who participated in the experience, and these lessons are critical to the successful management of ICT. Nevertheless, without accompanying organizational change, these lessons cannot provide ongoing benefits. It is far simpler to call for an enterprise-wide ICT management strategy than it is to make it happen within a complex, dynamic organization. The next chapter examines organizational aspects of the Air Force Y2K experience, with a focus on institutionalizing the general lessons of Y2K.

This page intentionally left blank.