Below are the first 10 and last 10 pages of uncorrected machine-read text (when available) of this chapter, followed by the top 30 algorithmically extracted key phrases from the chapter as a whole.
Intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text on the opening pages of each chapter. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.
Do not use for reproduction, copying, pasting, or reading; exclusively for search engines.
OCR for page 55
Strategic Management of Information and Communication Technology: The United States Air Force Experience with Y2K Chapter 3 Aligning Organizational and ICT Strategies While the organization as a whole is becoming more and more interdependent, the parts increasingly display choice and behave independently. The resolution of this dilemma requires a dual shift of paradigm. The first shift will result in the ability to see the organization as a multiminded, sociocultural system, a voluntary association of purposeful members who have come together to serve themselves by serving a need in the environment. …The second shift will help us see through chaos and complexity and learn how to deal with an interdependent set of variables. (Gharajedaghi 1999) Chapter 2 focused on general lessons of the Year 2000 (Y2K) that establish a need and indicate an overall framework for an integrated, enterprise-wide information and communication strategy. This chapter focuses on more specific lessons of Y2K that can be used to translate that general framework into organizational practices and tactics. This can be an extremely difficult task. Like information and communication technology (ICT) systems, organizations are dynamic open systems consisting of “organized wholes of many variables” (Bertalanffy 1976). Anyone involved in managing the coevolution of these two highly complex, fundamentally different yet interdependent systems (that is, ICT and the organization itself) is engaged in a never-ending effort to improve a situation, not a grand scheme to achieve final victory. Given the complexity of managing ICT within the context of a specific organization, the notion of an organization’s “information ecology” has been gaining visibility (Davenport 1997). Complete alignment [between the information technology portfolio and the business strategy] is usually nonsustainable because strategic context constantly changes and because information technology portfolios are assets that take a long time and significant investment and expertise to develop. … Alignment is dynamic—a change in any one of the ingredients usually requires another shift elsewhere. The goal is for information technology investments and the portfolio to be heading in the right direction to maximize the value of those investments to the business. (Weill and Broadbent 1998) Although this is a business school perspective, it nevertheless sounds more like tending a garden than balancing a financial spreadsheet. Many United States Air Force (hereafter simply USAF, or Air Force) leaders already share a vision in which major elements across the service will operate within a single integrated system. This vision acknowledges the open nature of commanding such an integrated environment, calling it an art. There is even the recognition that achieving this vision requires organizational change, as stated in the Air Force Vision 2020. “We operate aircraft and spacecraft optimized for their environments, but the art of commanding aerospace power lies in integrating systems to produce the exact effects the nation needs. To meet this need, we’ve modified our command organizations to take full advantage of air, space, and information expertise.” With slight modification, this Air Force vision statement could serve equally well as a vision statement for managing ICT: We operate ICT systems optimized for their environments, but the art of managing ICT lies in integrating systems to
OCR for page 56
Strategic Management of Information and Communication Technology: The United States Air Force Experience with Y2K produce the exact effects the organization needs. To meet this need, we will modify our organizations to take full advantage of mission and information expertise. When most people hear the phrase “system integration,” they think of technical issues, such as machine compatibility and achieving common operating environments. From this computer-centric perspective, two systems are integrated if they are electronically linked and can communicate with each other. However, the Y2K experience demonstrated that cross-functional ICT challenges, particularly those involving the interpretation and use of data and information, cannot be defined solely or even primarily in terms of technology. Like Y2K, current ICT management challenges such as system integration, information assurance, security, and life-cycle management cannot be met on purely technical grounds. Because ICT is pervasive, yet personalized; affects everyone, yet has no single owner; and is intimately tied to organizational missions, broad-based ICT issues inevitably generate tensions across various organizational boundaries. Y2K was a warning that technical solutions to broad-based ICT problems that fail to consider these tensions are unlikely to succeed. Under the added strain of Y2K, the impact of cross-organizational tensions on Air Force ICT policy and practice became increasingly evident. While the tensions and related issues were exacerbated by Y2K, they are a fact of organizational life even during periods of business as usual. In most cases, these tensions represent competing yet mutually desirable “goods” (for example, additional functionality versus tighter security), each of which needs appropriate representation within the organization. For this reason, attempts to solve these problems by eliminating the tensions that caused them are generally unrealistic and even undesirable. One-dimensional cures aimed at establishing enterprise-wide ICT uniformity can be worse than the problem. Rather than seeking to eliminate ICT tensions, management strategies and tactics need to carefully consider and appropriately balance these dynamic multidimensional demands. Such strategies and tactics must be based on an enterprise-wide view of the varied ways that information is used to achieve organizational goals. The remainder of this chapter explores specific organizational lessons of the Air Force Y2K experience that clarify and expand on the art of managing integrated ICT systems. These lessons are discussed under the following general headings: 3.1 Balance Central Management and Local Execution 3.2 Consider Evolution of the Problem over Time 3.3 Clarify Ownership and Responsibility 3.4 Consider the Impact of Local Diversity 3.5 Consider the Role of Local Autonomy 3.6 Build Trust Between Local Administrators and Central Managers 3.7 Strengthen Horizontal Relationships across the Organization 3.8 Overcome Funding Disincentives to Working across Organizational Boundaries 3.9 Clarify the Appropriate Level of Central Guidance and the Role of Central Administrators 3.10 Address Cross-boundary Issues in Life-Cycle Management of Systems 3.11 Tackle the Huge Informational Effort Needed to Support Management of Integrated Systems 3.12 Address Issues of Organizational Culture 3.13 Empower Permanent Organizational Entities Focused on Cross-boundary Issues
OCR for page 57
Strategic Management of Information and Communication Technology: The United States Air Force Experience with Y2K These organizational lessons of Y2K can help guide not only the Air Force but also any organization seeking to integrate ICT systems and to align management and use with organizational goals and strategies. 3.1 Balance Central Management and Local Execution Probably the most pervasive organizational ICT issue is the intricate and dynamic tension between central management and local units or departments. Neither the central nor the local perspective is right or better, and it would be neither feasible nor appropriate to attempt to eliminate the differences between them. Achieving an effective balance between central management and local execution is a critical component of any organizational information strategy. During Y2K these tensions were especially evident and had significant impact. In fact, nearly all the lessons discussed in this chapter relate in some way to tensions across the horizontal layers of an organization. The Air Force is well aware of the desirability and complexity of balancing these tensions, since its overall management strategy, commonly referred to as “manage globally, execute locally,” depends on it. This popular strategy extends far beyond the Air Force. At many organizations in the public and private sectors, top-level managers use some version of this strategy as they simultaneously attempt to coordinate action toward a common goal while freeing individual groups to adjust tactics to their specific conditions. In the Air Force, the manage globally, execute locally strategy is implemented by designating a single point of contact (POC) for each major action or issue. The POC provides general guidance to local units who act on that guidance within the context of their individual situations. Y2K demonstrated that ICT presents special challenges to this strategy. Over the course of its Y2K effort, the Air Force found it very difficult to establish consistent guidance under a single POC. This was evident across numerous levels, functional areas, and locations. For instance, ICT staff received guidance from and were accountable to several POCs, or bosses. The difficulties with this arrangement included a lack of organization and format (AFY2KO), the dynamics of dealing with multiple bosses (AMC/SCA), and demands for the same data in different formats (375th AW/MDG). In some cases, this resulted in excessive use of man-hours: “We put in about 20,000 man-hours overall. It should have been about 12,000” (375th AW/MDG). During Y2K, many complicating factors made it difficult to implement and effectively employ standard Air Force management practices based on central guidance and local execution. These factors are important to understand as part of a postmortem to Y2K, but far more importantly, they are general facets of ICT that continue to complicate ongoing management of this critical resource. As lessons learned from Y2K, they must be taken into account in the implementation and maintenance of any enterprise-wide information strategy. These lessons are discussed in the following sections.
OCR for page 58
Strategic Management of Information and Communication Technology: The United States Air Force Experience with Y2K 3.2 Consider Evolution of the Problem over Time One set of factors that complicated the effort to manage globally, execute locally stemmed from tensions generated by the way Y2K evolved over time. Chronologically, Y2K’s evolution ran counter to this standard management strategy. Rather than evolving from central awareness and management to local execution, the Y2K experience—as with most large ICT problems—evolved from local identification and action to central awareness and management (AFCA). For instance, MITRE first became involved in the Air Force Y2K effort in 1993 (Cheyenne Mountain) and then again in 1995 (AWACS), before the organizational issues with Y2K were prominent. This process was similar to the evolution of Y2K in industry. Once the Y2K problem reached a certain critical mass, management efforts rose up the chain of command and out across the military and government. Specifically, “in October 1997 there was no Y2K policy or guidance; in November 1997 the original guidance was that everybody should report to the host units; …[by] spring 1998 the policy was that everyone should report up the chain of command. This caused problems” (AMC/SCP). As higher levels of command became involved, so did Congress and accompanying oversight staff, each with “their particular view of [Y2K]” (MITRE). For AMC/SCP, the process for Y2K fixes was “(1) MAJCOM discovers the problem and finds a solution;… (2) policy is created; (3) three months later the Air Force comes out with a [different] policy…to fix the problem;… (4) three months later the DOD [Department of Defense] comes out with a policy that again forces us to do Y2K checks but in a different format….Those after-the-fact policies…led to the MAJCOM being hesitant to put out policy.” Similarly, from the perspective of the 374th OG, “We couldn’t tell who was asking what. We just had to do things again and again.” From the local perspective, the gradual upward and outward shifting of problem management produced a changing and, at times, redundant policy, making it difficult for local Air Force Y2K managers and staff to find a way of coping with the situation. Even as local Y2K staff struggled with the uncertainties of an evolving policy environment, central managers were experiencing their own growing uncertainties. In this case, uncertainty grew over time as managers became increasingly aware of how Y2K risk was complicated by the cross-functional, interdependent aspects of ICT. These managers saw the need to achieve consistency and accountability in the service-wide Y2K response, but this was greatly complicated by the diversity of local ICT activities. “Numerous places…[use] Air Force personnel to do systems development. They have their CDA (central design activity); we have our CDA. They don’t use our tools; we don’t use theirs. We don’t talk to them—maybe at conferences sometimes. MAJCOMs do their own development. Even the National Guard does its own development in some small part” (SSG). The difficult task of managing interdependencies was often heightened by a lack of global information at the local level. “There was a lack of understanding in the functional community of how…systems…worked together. The functional world understood the processes their systems went through, but because of manpower downsizing and people changing jobs,… the people who really understood that System A passed its information to System B through System C weren’t there” (MSG).
OCR for page 59
Strategic Management of Information and Communication Technology: The United States Air Force Experience with Y2K Although problems at the local and central levels were different and could therefore lead to tensions, they were both related to the ways Y2K evolved over time. In this context it is instructive to compare large ICT problem-solving activities to large ICT central initiatives. While problem-solving activities such as the Y2K effort tend to evolve from local recognition and activity to central management, large ICT initiatives tend to follow a reverse evolutionary pattern, one that more closely resembles the manage globally, execute locally principle. Nevertheless, the initiative’s pattern of central management to local execution generates its own set of tensions between central and local units. With Y2K we saw that local identification and execution existed before global management was established (or even seen as necessary). On the other hand, with large ICT initiatives, such as the Defense Messaging System (DMS),1 the concept is usually generated centrally, while the reality of that idea is subsequently identified and tested locally. “Usually ideas come from top down… but feasibility must filter up from the bottom” (375th AW/NCC). In addition, at any given time there are generally numerous overlapping system initiatives, forcing bases to “just field [them] and then try to figure [them] out” (374th AW/SC). In this situation, local executors become testers for centrally developed projects, often bringing to light unanticipated problems that then filter back up the layers of the organization, perhaps leading central managers to adjust their initial plans. This not only occurs with big programs but also with relatively small, highly frequent changes. For example, patches are function-specific, but when loaded onto a local system, they often introduce a new problem, one that may not be easily resolved. In some cases, unanticipated local problems can force central management to abort a patch load altogether (374th AW/OG). Bases do not generally like to see themselves as a testing ground for central ICT initiatives. Local units are focused on their functional missions; they expect that those missions will be enabled, not disrupted, by their ICT. Thus, when the central idea does not match the local reality, it can generate strong responses and loss of support at the local level (375th AW/NCC). ICT issues can evolve across organizational layers in two directions: large problem-solving activities evolving up into centrally managed initiatives, and centrally managed initiatives evolving down into locally driven problem-solving activities. Each related pattern has the potential to generate tensions across those layers. In addition, given the often rapid pace of ICT change, central ICT management can face a difficult task just in keeping up with the current version of these dynamic issues. While Y2K was primarily a problem-solving activity, the tensions associated with central initiatives were also visible in the Y2K response effort both because Y2K itself evolved into a centrally managed initiative and because Y2K efforts became closely interrelated with ICT initiatives in such areas as version control, certification, configuration management, testing, continuity planning, and security. (The first four of these areas are discussed in Section 3.10, the last two, in Chapter 4.) Despite the various tensions from differences at the local and central levels, it is important to keep in mind that each represents critical and compatible strengths. Local 1 DMS is an initiative led by the Department of Defense to establish secure e-mail throughout the department.
OCR for page 60
Strategic Management of Information and Communication Technology: The United States Air Force Experience with Y2K units more quickly recognize and respond to specific evolving issues, while central units more easily understand and respond to the need for compatibility and coordination of effort over time. For these strengths to be integrated, the tensions that can arise between central and local perspectives must be constantly and creatively managed. 3.3 Clarify Ownership and Responsibility Another source of the organizational tensions that complicated the management of Y2K (and continues to complicate ongoing ICT management) was a lack of clarity in the ownership of and responsibility for ICT systems. “It’s never one person who owns a system” (374th AW/XP). Generally, local units attempt to assert control over the systems they rely on. During difficult times such as Y2K, however, central ownership of these shared systems could be seen as desirable, since it lessened local responsibility for assessing and addressing the problem. The 374th AW/CS, for instance, viewed “70 percent of systems…[as being] out of local control; that is, the managing unit…[was not] on base. Therefore, 70 percent of assessment was already done.” Central ownership could be viewed as meaning central responsibility for a system’s functioning. “We have no access into C2IPS (Command and Control Information Processing System), so we have to take [central’s] word on Y2K compliance” (374th AW/CS). If other units owned their systems, then local units were free to interpret central Y2K policy as best suited their needs. This was especially visible at overseas (OCONUS) bases, where stressful frontline conditions and limited resources increased the incentive to minimize the demands of the Y2K response. This is illustrated by such statements as: “It was a moot point to freeze our systems because systems are centrally controlled,” and “We didn’t have to do most DOD tests because we’re at the end of the…[system] chain” (374th AW/CS). Yet even at major stateside (CONUS) bases, unclear ownership and responsibility could be a complicating factor. “We argued with the Audit Agency over who is responsible for making sure the base has updates—the base or PMO (Program Management Office)” (375th AW/CG). In addition, like their OCONUS counterparts, CONUS bases could interpret central ownership as meaning that primary responsibility for assessment was not with the local units. “C2IPS is on the infrastructure spreadsheet. Systems like this that are used but not owned appear on the database … but aren’t inventoried” (375th AW/CG). In actuality, neither central nor local units alone can be fully responsible for shared ICT systems. Even when central units are solely responsible for development and fielding of organization-wide off-the-shelf systems (whether government or commercial), these systems invariably require ongoing adjustment for implementation, operation, and maintenance under local conditions and needs. For this reason, a comprehensive assessment of shared ICT requires an appropriate integration of central and local evaluation. Another aspect of unclear ownership of and responsibility for ICT systems is that different components—and even parts of components—can be viewed as being owned or under the responsibility of different units. For instance, “the last 50 feet of wire belongs to AMC (Air Materiel Command), and anything that belongs to AMC is reported through
OCR for page 61
Strategic Management of Information and Communication Technology: The United States Air Force Experience with Y2K AMC channels” (AMC/HQ). This can result in potentially confusing arrangements that impact ICT management practices. In particular, local users of ICT systems can face a confusing picture when deciding with whom responsibility lies. For a system problem, users may contact the functional system administrators; for a Windows problem, they contact another technical group. Each group has a local expert who discerns whether problems have resulted from commercial off-the-shelf (COTS) hardware or the system itself. The result of having different agencies responsible for different parts of an end user’s system is less than optimal (374th AW/CS). One of the important benefits of the Y2K experience was that it forced diverse owners of systems and overlapping system components to communicate with each other in an effort to coordinate responsibility. Unfortunately, much of this valuable information and communication is being lost. (See Section 3.6 for further discussion of information needs in support of integrated ICT management.) 3.4 Consider the Impact of Local Diversity Closely related to ownership and responsibility issues are issues that stem from the diversity of local ICT environments and resources. Multiple ownership and guidance may confuse individual users as to who is responsible for the different parts of the complex systems they rely on, but central owners and maintainers of those systems face the equally confusing task of understanding and managing a complex system of systems that spans significantly different functional and geographical environments. During Y2K the effort to provide central guidance was greatly complicated by the diversity of local ICT conditions. Even central management of a specific piece of software with a common function had to account for complications that could stem from differences in local and mid-level management. “For Scott [Air Force Base], supply is under AMC; at Yokota, supply is under PACAF [Pacific Command]. But each base uses the same system, SBSS (Standard Base Supply System)” (374th AW/CS). These differences in ICT management contributed to diversity in response activities as central guidance filtered down to local execution. The divergence of interpretation of central guidance sometimes began at high levels and involved cross-service entities, creating potential confusion well before it reached the even greater diversity of frontline conditions. In one instance, the Commander in Chief (CINC) and PACAF received the same guidance, but by the time a base (under PACAF) and a tenant at that base (under CINC) received it, the guidance was different (USFJ). In addition to management differences, local diversity of ICT resources was another important complicating factor for central managers. These differences occur across many units and at many levels, but they were particularly evident during Y2K within the operating environments at OCONUS bases. Even though systems staff had been “told that all bases had new equipment,” old equipment (for example, copper wires and low-bandwidth modems) was still in use and could not support many of the new systems. Updating all the bases was a six-year project, which meant that some bases would not receive new equipment for several years: Yokota, for instance, was the second-to-the-last base to be updated. Differences
OCR for page 62
Strategic Management of Information and Communication Technology: The United States Air Force Experience with Y2K like these mean there is great variability by location in the demands during a large ICT problem-solving activity such as Y2K. This issue continues to impact such service-wide ICT efforts as DMS (374th AW/SC). Complications that arise from the diversity of local environments can be greatly exacerbated by the way systems are viewed. The risk of disruption from local diversity greatly increases when systems are developed and fielded in isolation rather than as a piece of a larger system of systems. “Ideally, programs should be tested higher up. The programs are time line driven rather than event driven, so the engineering and installation ends up happening at the bases” (374th AW/CG). This is more than just an Air Force issue. The success record of large ICT projects throughout government and industry is very poor (see Section 3.13), and many of these difficulties can be traced to a failure to anticipate the impact of local changes on the overall system. This occurs even within the most technically perceptive organizations: for example, in 2001 the isolated test of a WorldCom employee “crippled NASDAQ’s network” (Weinraub 2001). (This issue of cross-boundary interdependency is discussed further in Section 3.10.) 3.5 Consider the Role of Local Autonomy Local diversity issues can be further complicated by a high degree of local autonomy. This autonomy stems from facets of the organization and of ICT itself. In the Air Force, local autonomy is fostered in part by the ways ICT is funded or, as is often the case, not funded. Many times, “systems are fielded without funding in hopes that bases will find their own funding for them” (375th AW/CG). As a result, regardless of certification or policy, if a base lacked the funding to implement a system, implementation did not occur. Without accompanying funding, there can be only limited confidence in the effectiveness of central guidance. However, the wide diversity of local conditions and infrastructure greatly complicates any effort to centrally fund ICT guidance. (See further discussion of ICT funding in Section 3.8.) Where central funding does not accompany central guidance, local units may be unable or unwilling to follow that guidance. On the other hand, the existence of flexible money can enable local units to do what they want outside of central guidance. Thus, International Merchant Purchase Authorization Cards (IMPACs), military credit cards for flexible purchases, represent the other financial side of local autonomy. In the case of ICT purchases, local initiatives outside of central guidelines can greatly complicate the central management effort. For instance: “folks use IMPAC cards to buy stuff and hook it up to the network. … We have no central way of knowing what’s on the network” (374th AW/CG). In addition, because the use of IMPAC cards bypasses the standard purchasing process—and therefore the standard approval process—security problems may be detected after the fact (if at all).
OCR for page 63
Strategic Management of Information and Communication Technology: The United States Air Force Experience with Y2K There is a problem with the use of IMPAC cards and not using the standard process. Operational commanders listen to the local IT expert in their units, and he says, “We really depend on the network and if we put a modem on this box we can go out and back up the network on the Internet.” And the commander signs off on it. Next thing you know I detect a security problem and I’m investigating it. And then I’m asking them where their approval is. … (375th AW/CG) On the other hand, the use of IMPAC cards to support local ICT initiatives can be seen as a local user’s response to rapidly changing needs within the context of a slowly changing bureaucracy. “Government tends to be very slow and makes it very hard to change direction, yet the entire information technology field is characterized by very rapid change. … So users go off and do their own things—that’s why IMPAC cards came out. People couldn’t do what they wanted quick enough through our means, so they purchase and build…miscellaneous little [utilities] on their own…because that meets their needs” (MSG). While funding is a critical contributor to local autonomy, it is not the only one. Inconsistent ICT guidance, quite evident during Y2K, also frees local units to choose their own courses of action. For example, “last year we refused to install [a business system]… because [we] got conflicting guidance from SSG and PACAF” (374th AW/CS). Sometimes, questions about central guidance are raised by the use of less formal, individualized communication channels that appear to be quicker and more reliable to local ICT managers. This occurred frequently during Y2K as local managers sought additional information and clarification of central policy that was often changing or unclear. For instance, “[Our] guidance came…through PACAF. However, I was part of the AFCA newsgroup so I’d get to see their spin was on what PACAF said” (374th AW/SC). These informal communication channels could be very helpful, but they further increased the likelihood that local units would find their own ways to interpret central guidance. Another issue related to local autonomy is the creation and use of locally developed software and systems. Because these systems are motivated by and tailored to specific situations they can often better address local needs, including ease of use, at least in the short term. However, these systems can easily result in duplication of effort, such as double entry of data, and difficult maintenance problems when the local developer leaves the unit (374th AW/CG). Locally developed software was a particular concern during Y2K. Date formats could be idiosyncratic, and data processing and flow could be difficult to understand, especially if the developer was no longer available. In addition, many Y2K fixes came from commercial providers, not in-house staff, so they did not address these “homegrown” systems. Addressing the concerns about locally developed software became another side benefit of the Y2K effort in that less visible problems were noticed and potential long-term problems were identified. For example, AMC/SCA was required to upgrade a program written in an old version of Access to be Y2K-certified. Fortunately, this coincided with the imminent retirement of the staff member who had written the program.
OCR for page 64
Strategic Management of Information and Communication Technology: The United States Air Force Experience with Y2K 3.6 Build Trust Between Local Administrators and Central Managers For many reasons, including those already discussed, local system administrators can develop considerable skepticism about central ICT guidance. This can make it difficult to predict the outcome when central guidance meets local execution. During Y2K a master sergeant at an OCONUS base was under additional pressure to deliver administrative system reports. He preferred to use an alternative software package to generate the reports rather than the approved package he was told to use in central guidance received through his major command (MAJCOM). (See discussion of system certification in Section 3.10.) He had experienced considerable problems in working with the approved software, problems that he attributed to insufficient bandwidth on his local network. He concluded that this was yet another case of central managers not understanding his local conditions. There was no one he could turn to for support of the approved software, so he went to people he knew within the local systems group and got them to sign off on his use of the alternate system, and he got his reports in on time. While the master sergeant’s general concerns—that is, lack of local support for the system, too-low bandwidth, and generality of central guidance—are important to consider, there is another version of this story as told by a captain in the systems group responsible for system configuration. From the captain’s perspective, a master sergeant has invested in learning a software package that facilitates his work. He then is told he should be using a different package. The sergeant halfheartedly tries the approved package and experiences a variety of problems. He receives a quick approval from some systems staff to use his preferred package, without the knowledge of the captain, who is responsible for network configurations. (One office within the Network Control Center [NCC] provided one level of approval without the other office being informed.) In addition, the captain disagreed with the sergeant’s view of the specific problems, attributing them not to insufficient bandwidth but, rather, to incompatibilities between the approved and non-approved software packages. A number of possible issues are involved in this scenario. The approved package may or may not be the best option for the local environment. There are cases where local personnel appropriately consider critical aspects of their unique situation that global management does not anticipate. In such cases, it is important to consider whether central guidance is being issued at an appropriate level, focused on enterprise-wide organizational goals that allow for a greater diversity of local execution to achieve those goals. (For further discussion of this issue, see Section 3.9.) On the other hand, there are less desirable (though no less important) reasons for local resistance to central policy, including lack of communication, failure to develop local investment in desired changes, lack of training, and user investment in existing successful practices. Local management and staff recognize their accountability to central authority; sometimes, however, new policy or procedures are counter to accepted practices or legacy versions at a particular base. Therefore, local staff may refuse to implement them (374th AW/XP). At other times, local system administrators may consider new policy a less than optimal solution for their situation, and in these cases, they develop their own solution or work-around (374th AW/SC). Other relevant issues to address include: Was the approved package too difficult to install?
OCR for page 65
Strategic Management of Information and Communication Technology: The United States Air Force Experience with Y2K Was NCC’s role as a mediator between the MAJCOM and the local user clear and effective? Was there sufficient training and local support? From one perspective, staff who circumvent central policy are likely to create difficulties for others; from another perspective, people like the master sergeant (trained in logistics, with only occasional short courses in system administration) are showing initiative in the face of an expanded mission. One conclusion is clear, however: within ICT, numerous conflicting and interrelated factors make it difficult to anticipate what will happen when central policy meets local execution. This unpredictability greatly complicates central ICT management activities in such areas as configuration management and version control. This became clearer during Y2K, when central software managers had a greater need than usual to track the version of software packages in use. “‘Versions released’ does not always equate to ‘versions in use,’ especially in the client-server environment. Some versions were…not installed. Some were installed wrong. Some of the program offices were allowed to release their own software, …[which was] almost impossible to install…” (SGG). (Version control and related ICT life-cycle issues are discussed further in Section 3.10.) Because of the many tensions that can arise between central ICT management and local execution, the complications associated with the way ICT problems and initiatives evolve over time, and the diversity of conditions and rapid rate of change, it can be extremely difficult for central managers to stay current on a given overall situation. In many cases, central management finds itself grappling with what are actually earlier issues that have evolved into new challenges at the local level. This can result in further rifts between local administrators and central managers. Trust between local and central administrators is needed to break this potentially destructive cycle. While problems with communication and trust between local administrators and central managers were evident during Y2K, they extend far beyond it. Any broad-based ICT initiative or problem-solving activity runs the risk that centrally driven activities will break down into a set of local tests and solutions. To minimize this risk, organizations need enterprise-wide information strategies and tactics that mediate the tensions between central and local ICT personnel. In particular, stronger relationships across vertical organizational boundaries can reduce risk and unpredictability by increasing trust, facilitating communication, and focusing decision making on shared organizational investments, goals, and missions rather than on individual and diverse technologies or conditions. 3.7 Strengthen Horizontal Relationships across the Organization In addition to vertical tensions across hierarchical organizational layers (for example, Headquarters [HQ], MAJCOM, base), there are equally critical horizontal tensions across functional organizational lines. During Y2K these horizontal tensions also worked against effective global management and local execution of Air Force ICT. In fact, some managers who went through the Y2K experience and faced the many ongoing ICT issues
OCR for page 82
Strategic Management of Information and Communication Technology: The United States Air Force Experience with Y2K Technology issues also affected the consistency of data-gathering practices. During Y2K, bases lacked the software other organizations used to gather data; the AFASI interface was difficult to use, which resulted in inaccurate data; the functional managers experienced problems in accessing the database; and the capacity problems in Excel were not anticipated (AFCA). Equally critical were issues of organizational politics and information control that led to inconsistencies in the execution of data-gathering plans. For instance, 130 people from different communities developed a plan for reporting Y2K information to the Fusion Center. They used large group process techniques to create an acceptable reporting structure and vetted the plan across various other groups and organizations—some liked it and some did not. One MAJCOM “told its world, ‘Don’t report directly to the Fusion Center. Report to us. We’ll massage the information and give it to the Fusion Center’” (SSG). Geographical and cultural differences, especially between CONUS and OCONUS bases, could also impact the consistency of information-gathering efforts. OCONUS bases were required to go through the State Department—specifically, the embassies—to obtain information from host governments. The information received from these sources was much different from the information received from stateside sources. Other information originated from intelligence and similar networks that pooled information (374th AW/CS). The barriers to effective data gathering were not limited to the Y2K effort; they continue to complicate ICT informational activities to the present. Despite these challenges (including additional information security issues discussed in Chapter 4), this huge and complex effort is necessary to support effective high-level ICT management. The Y2K exercise gave the Air Force a much-improved grasp of the systems it has, the purpose and functions of those systems, and the systems and organizations with which they interface. The next step is to develop processes and procedures that maintain that data and use them constructively (AMC HQ). To do this, organizations need to give information issues a proper home (see Section 3.13), sufficient priority and organizational visibility, and adequate resources. Continuity over information inventories developed during Y2K must be retained (AFCIO/AFY2KO). Over time, organizations need to make information gathering and maintenance part of their ongoing communication culture. 3.12 Address Issues of Organizational Culture Beyond technology that is well designed and appropriately used; beyond data that are current, relevant, and readily manipulated; even beyond information that is alive and useful, there is communication among people and the culture within which that communication occurs. Information is not neutral. Existing relationships with an information source, for example, can mean more than the specific message content. In the Air Force, receiving information from one organization rather than another (for instance, OPS [operations] versus COMS [commands]) can determine whether the issue is dealt with by the base or delegated to one functional group (374th AW/XP).
OCR for page 83
Strategic Management of Information and Communication Technology: The United States Air Force Experience with Y2K Similarly, existing informal patterns of interaction can mean more than formal plans of operation. While formal communication plans were in place, verbal agreements among the program offices assured them that if a critical Y2K failure occurred, everyone would “get a call” (MSG). Because of its pervasive effect on how people perceive and practice communication, organizational culture impacts all aspects of ICT management, from specific tactics to overall strategies. Y2K was neither the first nor the last ICT project in which cultural issues played a central role. This is generally the case for any major, cross-organizational change in ICT such as occurs during mergers or strategic realignments. In 1995, when changes in the economics of health care forced Johnson & Johnson to move toward a more integrated delivery system involving doctors, hospitals, patients, and insurance companies, the president of their customer support center found himself in a countercultural effort: “Johnson & Johnson has over 100 years of history authorizing operating companies to manage all business facets to maximize their brands’ [profits and losses]. …We are learning how difficult it is to break those paradigms and work together to leverage the strength of the firm with larger retail customers” (Weill and Broadbent 1998). The Air Force, too, has a long history of functional autonomy, and Y2K similarly brought out the need to break down cultural barriers, to balance differences, and to work together while maintaining the benefits of that autonomy. There has been a tug of war between the network view and the systems view. Y2K taught us that both are good. … The AF needs to continue to have folks be cross-functionally focused while maintaining stovepipe functionality. (375th AW/SC) Some cultural traits are generally pervasive throughout an entire organization. The Air Force, for example, has a common “culture of perfection” that impacted the organization’s tolerance for risk during Y2K (see Chapter 4). Most cultural issues, however, involve differences among organizational subcultures, for instance, those that are information or commission driven (AMC) versus those that are not (ACC); those focused on system capabilities and performance (acquisitions) versus those focused on compliance and version change issues (computing operations). These subculture differences were especially visible during Y2K. Perhaps the most visible cultural differences during Y2K were those between acquisitions and computing. Even at the top level of management, the Air Force Y2K effort was split between these two perspectives. The Air Force Chief Information Officer (CIO) came from acquisitions (SAF/AQ), while the deputy CIO came from computing and communications (HQ/SC). Within these two areas, units that were particularly active in providing Y2K leadership included, on the acquisitions side, the Standard Systems Group (SSG) and the Material Systems Group (MSG) and, on the computing side, the Air Force Communications Agency (AFCA) and the Air Force Communications and Information Center (AFCIC). On the one hand, the acquisitions culture fostered a more hierarchical approach to Y2K. Those with an acquisitions orientation focused on centrally administered correction and testing of large systems acquired and maintained through contractual agreements. As discussed in Section 3.10.1, they saw Y2K as a demonstration of the need for more uniform, centralized software development and testing. The key to this was an increased emphasis on contractually based ICT management. On the other hand,
OCR for page 84
Strategic Management of Information and Communication Technology: The United States Air Force Experience with Y2K the computing culture fostered a more distributed response to Y2K, with local SC units working at each base. The emphasis was more on networking and managing nodes of activity focused on local, ongoing operational and maintenance issues. During Y2K, SC provided leadership and support to the various Y2K working groups that tackled the frontline efforts at bases and facilities across the service. Counter to the acquisitions’ perspective, those with a more computing perspective saw Y2K as a demonstration that central developers often fail to adequately consider the realities of local conditions and ongoing operational and maintenance issues (374th AW/XP, AFY2KO). Different perspectives, combined with the complexities of ICT systems, led to some confusion during Y2K over ownership of systems, responsibility for assuring compliance, and guidance on how to achieve it. However, it is neither surprising nor disturbing to discover that SSG primarily saw Y2K as an Air Force–wide acquisitions and fielding problem, while SC units primarily saw Y2K as a functional, operational support and maintenance problem. Each of these activities is highly complex and equally critical, yet each is fundamentally different. Even when acquisition decisions do consider maintenance, it is only one of a large set of other equally compelling issues (for example, cost, platform, function, training, scheduling, past performance, existing agreements, future acquisition plans). This is very different from the ongoing activity of maintaining systems under local conditions and needs with dynamic operational demands. In the current operational and organizational environment, acquisitions and computing could not be accomplished without the distinct cultural mechanisms that each activity has developed to support their differing relationships and practices. Nevertheless, acquisitions and operational support and maintenance are interrelated ICT management activities. Central acquisitions decisions impact the operational support effort, and the operational support situation impacts acquisition decisions. These activities need to be integrated, and for this to occur, bridges must be built between the two cultures that support them. It is critical that there be formal organizational mechanisms for supporting communication across these cultures, as well as regular occasions for that communication to occur. (For more discussion on this, see Section 3.13.) Other cultural differences also surfaced during Y2K. Users have their own culture, too, which is different from that of either system developers or computing support personnel. An analysis of user needs and environments is a complex activity, generally associated with the design phases of software and other information products. Although a detailed analysis of Air Force system users is not within the scope of this report, it is important to note that user backgrounds, purposes, perspectives, and environments differ from those who acquire, develop, or support the systems. Unique relationships and practices lead to a distinct user culture, and this can contribute to tensions that make it difficult to work with other interrelated activities, such as acquisitions and support. For instance, what works for system developers in the development stages does not necessarily work for users in day-to-day operations. “From the 600,000-foot view, C2IPS works. But in the trenches it doesn’t work. The real test is day-to-day operations. It takes a while to make a system run consistently” (374th AW/OG). While users can see developers and high-level managers as out of touch with the realities of frontline system operations, developers and system maintainers can see users as untrained and
OCR for page 85
Strategic Management of Information and Communication Technology: The United States Air Force Experience with Y2K unpredictable, prone to individualized actions that can defeat carefully conceived central plans (375th NCC). Some Air Force managers even see conflicts between the culture of technology users and that of government itself as contributing to the tensions they experienced with users. Government tends to be very slow and makes it very hard to change direction…yet, the entire information technology field is characterized by very rapid change—change in the technology, change in terms of our users’ needs. …Everyone else looks to information technology as a solution to their own internal problems. So they’re trying to do more things with information technology. That creates an inevitable conflict because as part of a government bureaucracy we can’t always do the things that we would like to do, so we tend to be unresponsive to those users. (MSG) It is vital to understand and link user culture to the other cultures that impact ICT management activity. Users are not only the system’s reason for being but also the first to notice (and are most affected by) ICT problems. For the 375th AW/CG systems, customers find 99 percent of system degradation. During Y2K, for example, users were in a far better position to recognize certain data corruption issues than were developers and others working on the central Y2K effort. AMC/HQ asked its users to monitor any special processing that occurred infrequently to be sure that the results made sense. Only thoughtful and alert users could catch these kinds of data corruption issues early. As with the acquisitions and computing cultures, the user culture is complex, functionally beneficial, and an inevitable part of ICT use. High-level ICT management needs to balance tensions stemming from cultural differences and to provide bridges across these various interrelated cultures so that users become part of the conversation and part of the solution. Like cultural differences, geographical differences in both physical and organizational location also impact ICT management. During Y2K these differences were particularly visible between stateside and overseas bases. For OCONUS staff, a major challenge was presented by the cultural differences of the host government: “Too many people wanted to ask too many questions and it damaged relations” (USFJ). In addition, Air Force ICT managers located in non-U.S. environments were generally more concerned about the impact of Y2K on the foreign culture they depended on than on their own ICT systems. Given the extensive DOD, MAJCOM, and system group scrutiny generated by Y2K, OCONUS staff were confident that their own system’s potential problems would be identified and fixed. Their concern was focused on the host country’s reaction and ability to provide dependable utility support. To that end, they spent 1999 preparing for the worst case (374th AW/CS). “The experience was more challenging because of our unique situation to be dependent on an electrical power source outside of U.S. territory. Your main power source may not be there no matter how prepared your systems are. Host country data/parts were not readily available when needed. The base prepared higher-level contingencies because of these limitations” (374th AW/MDG). Another geographical factor that impacted ICT management was physical proximity to major organizational units. This impact could be both positive and negative. On the one hand, Air Force units on a base that hosts a MAJCOM headquarters, for instance, increase their likelihood of informal interaction with that unit and, therefore, access to central guidance and related communications. “It was nice to have AMC next door. We looked at reports sent up to the MAJCOM that other folks didn’t get to see. We were
OCR for page 86
Strategic Management of Information and Communication Technology: The United States Air Force Experience with Y2K guinea pigs for inspectors so they could get a first run-through for inspections” (375th AW/CE). On the other hand, the impact of organizational proximity to major commands could preclude certain activities, such as total blackout tests (375th AW/CG). Finally, cultural and geographical issues impact ICT management at the highest, most strategic levels. Like Johnson & Johnson, the Air Force had a deep-rooted history of functional autonomy that had to be overcome in order to address the cross-functional aspects of Y2K. Those who went through Y2K, especially from a leadership perspective, were profoundly impacted by this experience. They acknowledged the difficulty in implementing change; however, they also recognized the potential for making a significant difference in the way ICT is managed, and that to do so was their responsibility (AFCIO/AFY2KO). It’s going to be difficult to change some of the perspectives of the current leadership. … We won’t recognize what really happened culturally to us individually and to our organizations. The potential is there for us to do some significant things. But it’s going to be incumbent upon those of us who participated in this process to continue to bear the flag. … We’re facing a tremendous amount of cultural change in the way we go about tackling problems, and the way we go about finding solutions and executing things is going to change. It changed with the way we dealt with Y2K. (AFCIO/AFY2KO) At the top level, ICT management is about the space between functional areas. It is about fostering cross-cultural communication and balancing the dynamic tensions that arise across organizational boundaries. It is therefore critical to recognize and address the many organizational subcultures that sustain these various functional homes. To accomplish this, the “space between” requires an organizational home as well. 3.13 Empower Permanent Organizational Entities Focused on Cross-Boundary Issues Once Y2K was perceived to be a general, widespread threat to ICT infrastructure, many organizations found it necessary to establish temporary organizational entities to spearhead their Y2K response efforts. Efforts to solidify central management of Air Force Y2K activities culminated in the creation of the AFY2KO in mid-1998. This temporary office not only faced a large problem with a short deadline but also came into being at a time when a variety of Y2K activities and levels of management had already existed for several years. Thus, while the AFY2KO was well positioned to provide coherent leadership to culminating activities, such as the final CINC-level assessments of mission threads, there was little time, resources, or incentive for establishing itself as the single POC responsible for providing consistent Y2K guidance across the myriad of Air Force Y2K activities. Similarly, numerous other organizations established temporary Y2K management entities, such as the President’s Council on Year 2000 Conversion and the United Nations’ International Y2K Co-operation Center. These entities were created not so much because the problem was large and important, but because existing entities did not encompass the cross-functional, cross-hierarchy, cross-organizational, and cross-system issues involved. During Y2K, temporary organizational entities were used to gain perspective on interdependencies across units and subsystems, as well as to foster
OCR for page 87
Strategic Management of Information and Communication Technology: The United States Air Force Experience with Y2K communication where existing channels did not exist or were insufficient. The President’s Council, for example, focused much of its energies on leading a series of meetings that brought together key people from various sectors, as well as creating an International Communication Center to gather and distill information on national and international Y2K incidents. Were such temporary entities filling a need for integration and communication that existed only during the Y2K situation? Based on everything discussed previously in this chapter, the answer is no. The creation of these temporary entities represented a missing element in ongoing ICT management: “There are a large number of IT-related issues that need to be worked similarly to the way we did it in Y2K. … It’s been looked at as unique in a number of ways, but it shouldn’t be” (AMC HQ). Organizations already have permanent homes for functional parts of their ICT system of systems; they also need permanent homes for the space between those parts. Complex systems such as ICT are more than the sum of their parts. Partial perspectives are often sufficient for day-to-day operational activities, but as has been shown in this chapter, high-level, strategic ICT management needs to integrate and balance the ongoing, dynamic tensions between the various parts and perspectives. This holistic perspective represents a different kind of knowing than knowledge of the parts. Both are essential to the understanding of a complex system. “More than one way of knowing is possible. …Without the development of an over-all perspective, we remain lost in our individual investigations. Such a perspective is a province of another mode of knowledge, and cannot be achieved in the same way that individual parts are explored. It does not arise out of a linear sum of independent observations” (Ornstein 1975). Many ICT managers who went through the Y2K experience came to recognize the necessity of permanent organizational entities focused on enterprise-wide, holistic aspects of ICT systems. They saw that the toughest problems occurred not so much within areas under their responsibility but, rather, within areas that cut across those responsibilities. These more holistic problems were not so much about technical issues—they involved integration of and communication across the entire system of systems, that is, the overall infrastructure (AMC/SCA). There are a number of areas that are very soft and it would be wonderful if they got a greater emphasis. The programs have their problems, but largely those are being worked. What isn’t being worked is the overall infrastructure. (AMC/SCA) Yet, as difficult as it had been to focus on enterprise-wide ICT management during a crisis situation, managers knew it would be even more difficult to maintain this focus under normal conditions, especially since funding and other mechanisms for institutionalizing change had not been put into place. “Y2K was a hybrid organization and it was set up to run for this period of time. … Now we step forward past the rollover and …[nothing] has changed within our own organization. … Y2K has imploded itself back into the organization…” (AFCIO/AFY2KO). ICT has become a less visible issue, resulting in a return to business as usual with normal (namely, pre-Y2K) funding. Therefore, mandates to solve information assurance and security problems will not be fulfilled (MITRE). (Of course, the events of 9/11 have changed this.) Because Y2K was not expected to have a long-term effect or enterprise-wide impact on the Air Force, professional financial managers were not brought into the
OCR for page 88
Strategic Management of Information and Communication Technology: The United States Air Force Experience with Y2K program. Such a group could have been carried over into a new ICT management environment (AFCIO/AFY2KO). As Y2K ended with seemingly little long-term impact, ICT managers worried that the critical cross-boundary focus was rapidly being lost. “The enterprise as a whole is not being looked at. We may have management and policy, but strength from an enterprise standpoint is lost. … Momentum… that we gained through Y2K is rapidly falling away—we’re losing our opportunity to maintain the enterprise perspective” (AFCIO/AFY2KO). Even a cursory look at the ongoing state of ICT management leads to the conclusion that organizations should not need a crisis to stimulate cross-enterprise ICT coordination and communication. There are staggering organizational losses every year that can largely be traced to incomplete and ineffective ICT management. Overall, ICT projects have an extremely poor completion and success record. The following describes the situation immediately prior to the Y2K effort (1994/95): In the United States, we spend more than $250 billion each year on IT application development of approximately 175,000 projects. The average cost of a development project for a large company is $2,322,000; for a medium company, it is $1,331,000; and for a small company, it is $434,000. A great many of these projects will fail. Software development projects are in chaos, and we can no longer imitate the three monkeys—hear no failures, see no failures, speak no failures. The Standish Group research shows a staggering 31.1% of projects will be canceled before they ever get completed. Further results indicate 52.7% of projects will cost 189% of their original estimates. The cost of these failures and overruns are just the tip of the proverbial iceberg. The lost opportunity costs are not measurable, but could easily be in the trillions of dollars. … Based on this research, The Standish Group estimates that in 1995 American companies and government agencies will spend $81 billion for canceled software projects. These same organizations will pay an additional $59 billion for software projects that will be completed, but will exceed their original time estimates. Risk is always a factor when pushing the technology envelope, but many of these projects were as mundane as a driver’s license database, a new accounting package, or an order entry system.(Standish Group 1994) Since these ongoing estimated losses are comparable to expenditures during Y2K, the need for a central home of ICT management appears not to be limited to times of crisis. Because so many ongoing ICT issues were interwoven with the Y2K effort (for example, version control, certification, system ownership and responsibility, configuration management, system maintenance, continuity planning, security), there was a relatively brief time during Y2K when the AFY2KO became the Air Force’s home of enterprise-wide ICT management. As a temporary office, however, the AFY2KO had no mandate for developing and implementing long-term approaches to these ongoing ICT challenges. However, it did recognize the importance and complexity of these evolving issues and that permanent homes were needed for managing them. “We need to find homes for issues like configuration management and certification and version control and we need to put them into policy and procedure” (AFY2KO). While the AFY2KO and similar Y2K-focused entities have disappeared, there are legacies of Y2K aimed at addressing this ongoing situation. Most significant are the rapid growth of a relatively new corporate position, the Chief Information Officer (CIO), and the creation of an even newer cohort, the Chief Knowledge Officer (CKO). “Agents
OCR for page 89
Strategic Management of Information and Communication Technology: The United States Air Force Experience with Y2K of change are…rewiring corporate culture one technology project at a time. These direct descendants of Y2K crisis management teams are more highly disciplined and closely managed than past IT teams. …The CIO has emerged as the driving force behind these collaborative implementations of technology” (McCartney 2001). While CIOs and CKOs have increasingly been charged with managing an organization’s information and knowledge systems, there has been considerable uncertainty as to the exact nature of and appropriate skills for these positions. What is enterprise-wide management of an organization’s information and knowledge systems? What does an entity devoted to this activity do? As with the Air Force, many organizations initially saw the CIO’s office as an extension of already influential acquisitions and development functions. This fostered two related perspectives: (1) technology was the central component of an organization’s information and knowledge activities, and (2) the CIO’s primary role was as owner and manager of that technology. Thus, many CIO offices centered their information and knowledge management activities on standardizing and keeping up with new information and communication technology. This focus was not only aligned with existing ICT units but also was economically beneficial to the many technology companies with products in this area. “Technological perspectives of knowledge management are popular because of the power and resources often held by technology departments. Furthermore, some of the most widely distributed knowledge management periodicals (KMWorld and Inside Knowledge magazine, for instance) are sponsored almost exclusively by the advertising dollars of technology companies marketing their products” (Wick 2000). As Y2K demonstrated, enterprise-wide ICT management is not primarily about functionally organized technology. If the CIO owns anything, it is the space between these nodes of responsibility, the conversation and interactions that link the functional parts into a strategic whole. As such, one of the primary activities of the CIO’s office must be team building. “It's no longer the case that companies are just forming teams within their own walls. Now they're doing teams across company lines. So you have teams that are cross-organizational, cross-company, cross-culture, cross-hierarchy, cross-technologies, cross-languages, cross-functional—cross-everything” (Jessica Lipnack, quoted in McCartney 2001). Team building was a critical issue during the Air Force Y2K response effort. In addition to the AFY2KO, Y2K spawned unique working groups at bases across the service. These working groups took cross-functional interaction to a lower level than most workers had ever experienced. The working groups, where the decisions were made, were composed of the organizations’ labor forces, which do not usually work with each other. Consequently, people from the various organizations came to recognize that they have a mutual dependency (375th AW/Y2K, 375th AW/CE). However, team building and coordination are difficult tasks, especially when teams operate out of the normal channels. Many saw these lower-level working groups to be impaired by a lack of leadership and traditional rank. “We had a COMS Tech Sergeant running the [base] Y2K program…not only didn’t he have the rank but he didn’t have the experience or background of taking all the players on a base and getting them involved” (374th AW/CS). Therefore, “it was… difficult to get [Y2K work group] members involved…the effort’s success depends on the level of involvement. It depends on each functional commander’s opinion; if they are behind the effort, then there is good
OCR for page 90
Strategic Management of Information and Communication Technology: The United States Air Force Experience with Y2K involvement. While the strength of the effort was the cross-functionality, there was no central, formal power behind it” (AMC HQ). Others gave a far more positive appraisal of the Y2K working groups, though even these people acknowledged the critical role of high-ranking leadership and authority behind the groups. For example, before Y2K it could take up to three weeks for information to be routed up through the wing chain of command. But during Y2K, “the worker bees could take the raw data, streamline it just a little bit, and present it right to the wing commander. And we did that weekly at the stand ups. … I don’t think it’s something that’s ever happened before” (375th AW/Y2K). Perhaps this occurred because “wing commanders were personally called to task for Y2K. …That’s why the low-level organizational matrix worked” (375th AW/ CG). For others, cross-functional teams could be advantageous if they had a defined function. It was noticeably effective to have cross-functional problems addressed by people from different parts of an organization (AMC/HQ). Whatever the success of the Air Force Y2K working groups, cross-functional team building is a complex activity, one where organizational CIOs charged with enterprise-wide ICT management need to play the central leadership role. This, alone, impacts the desired skill set for the CIO position. “Given the high risk for failure of teams, the CIOs who lead [collaborative] groups require business, technology, team-building, project management, and communication skills to be effective” (McCartney 2001). What else must the CIO do? The CIO needs to distinguish functionally bound ICT issues from enterprise-wide ones. Where the issue resides within a functional responsibility, the role of the CIO is greatly minimized or nonexistent. But the CIO needs to be extremely sensitive to the interdependencies of the overall system. When an error is made, it is likely to be the incorrect assumption that a cross-functional issue is bounded within a particular functional responsibility. When an ICT issue is identified to be enterprise wide, the CIO must take ownership. While this means assuring that there is a single point of contact providing consistent guidance at the appropriate level, it does not mean the CIO’s office should be that POC or should own the problem parts. The CIO owns the space between the parts—the space that makes it a cross-enterprise, strategic issue. In this case, his or her primary role is to identify the relevant organizational perspectives, to determine the best available representatives of those units and perspectives, and then to link, guide, and empower those people and units to manage the issue. Under the CIO’s guidance, a cross-boundary entity defined to represent the relevant organizational perspectives on an issue becomes the POC. Only such an entity, acting with the guidance and authority of the CIO’s office, can take on the delicate task of balancing the competing organizational goals that surround a cross-boundary ICT issue. The CIO is the fulcrum in this balancing act—team building, facilitating cross-boundary communication and activity, assuring that ICT activities are aligned with organizational goals and strategies, and institutionalizing desired change. Sometimes, however, the CIO must go beyond the fulcrum role to one of greater authority and stronger leadership. Specifically, during times of critical activity like Y2K or security threats, the CIO may be required to assure speed and flexibility in the face of traditional methods for doing things. “There are bureaucracies that are designed to slow
OCR for page 91
Strategic Management of Information and Communication Technology: The United States Air Force Experience with Y2K down decision making and there are places where you want to do that—but in this case [Y2K], because of time urgency, the bureaucracies were either pushed aside or stepped aside and allowed that rapid reaction to take place. And you need to be able to adapt your organization to do some of those things” (MSG). For an organization such as the Air Force, the CIO would be responsible for assuring whatever ICT flexibility was required for national defense. In addition, the CIO’s office should serve as the single point of contact for ICT coordination outside the organization. This was a successful aspect of the AFY2KO effort but may be less clearly achieved in noncrisis cross-service initiatives. For instance, “the Y2K strategy was to develop the relationship with DISA (Defense Information Systems Agency) early on…create a service-level agreement. …We probably worked on that relationship as much as anything else to make things function smoothly. …[However,] DMS is…not being run that way…” (AFCIO/AFY2KO). Finally, the CIO must foster the use of ICT systems themselves as part of the solution to the problems they generate. These systems are increasingly the primary medium for the cross-boundary conversation and activity the CIO must establish and guide. During Y2K much of the sharing of information among the Air Force, the services, the federal government, and other governments took place over the World Wide Web, which was not business as usual. In the future, “similar approaches will be needed for other equivalent issues” (MITRE). In this vein, the AFCIO/AFY2KO is working with the Air Force Materiel Command to develop a knowledge management website to host the Y2K lessons learned. Given the ability of modern ICT to empower individual users and groups of users, some wonder whether decentralization is an inevitable feature of ICT activity. They wonder whether we must focus on the strengths of local flexibility to achieve our goals, even under crisis conditions. For instance, IT support during the Gulf War was essentially a kludge; that is, a flexible and decentralized system composed of very different parts was organized into a working system that successfully served a critical yet temporary need. “And that’s effectively how we’re going to do it in the future” (AF/XOIWD). Even though there is considerable validity and strength to this perspective, it must be coupled with the strengths of enlightened central leadership. A recent Pentagon study of the Gulf War found that Army logistics and support units “were hard-pressed to keep up with the rapid pace,” and if the victory had not been swift, “maneuver forces would have outrun their fuel and other support” (Rosenberg 2001). As difficult as it may be to achieve, without a single point of responsibility for the overall ICT system, without the cohesion an appropriately focused CIO’s office can provide through central authority and the creation and use of formal cross-boundary entities, we may not be as fortunate in the future. Managing ICT systems means managing risk. In battling the risks of Y2K, there were lessons for the current struggle with risks associated with information assurance, critical infrastructure protection, and security. “What we did during Y2K is going to continue into the information assurance and the CIP program as we move toward better and better ways of managing IT” (AFCIO/AFY2KO). Chapter 4 focuses on applying the lessons of Y2K to managing ICT risk.
OCR for page 92
Strategic Management of Information and Communication Technology: The United States Air Force Experience with Y2K This page intentionally left blank.
Representative terms from entire chapter: