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 32
32 Information Technology Systems at Airports­A Primer 3.2.2 IT Master Planning IT master planning is the step that translates the airport goals and projects proposed in the airport master plan and the capital improvement plan into the realm of information technology. It is an ongoing process that derives IT requirements from the airport master plan for new projects and the intrinsic replacement/updating needs of the IT infrastructure. Results of this step include: · IT principles. IT principles are the guiding rules that govern how information technology is deployed and maintained at an airport. They directly reflect the airport goals and represent overarching practices that ensure airport planning aims are achieved. Sample IT principles are provided in Chapter 4. · IT master plan (ITMP). The ITMP is built from the airport master plan. It explicitly addresses App end ix the IT systems of an airport and distills AMP programs down to the specific information tech- A nology components. Like an AMP, an ITMP is a long-term, multi-year document that builds an image of the state of IT at the end of the projected period. Projects appropriate to an ITMP may be directly addressed in an AMP but are more commonly derived from larger scopes (e.g., calculating the network growth necessary to accommodate a parking garage expansion). Table 3-1 gives examples of strategic airport goals that can be enabled by IT. The ITMP, CIP, and IT principles established in the strategic planning phase are often used to establish an IT road map for new systems and enhancements. The ITMP and its road map, along with change requests and new requirements derived from ongoing operations, are inputs to the next phase, system planning. 3.3 System Planning Phase Unlike the strategic planning phase, which deals with total airport planning and multiple sys- tems, the system planning phase and subsequent lifecycle phases deal with one system at a time and are reiterated for each system being considered. The system planning phase encompasses all tasks that must be completed before an airport can begin implementing an IT project. The system planning phase starts when a formal request is made for an IT solution that meets a valid new requirement or change to an existing system. Within the system planning phase, goals to accomplish include: · Create a high-level concept definition of the system. · Evaluate each system based on economic, operational, and technical feasibility. · Evaluate the benefits and value of the system. · Establish funding mechanisms. Figure 3-3 depicts the activities of the system planning phase. Table 3-1. Examples of airport goals enabled by IT.

OCR for page 32
The IT System Lifecycle­A Common Process 33 System Planning Concept Definition System Definition Concept of Change Requests & Operations New Requirements Cost­Benefit Project Analysis Charter Funding Value Proposition Figure 3-3. System planning phase. 3.3.1 Concept Definition The first activity of the system planning phase is concept definition. The goals of concept def- inition are to further refine the initial request for an IT system, clarify the project goals and scope, and establish how the system will be operated. Documents that must be developed during this stage are: · Concept of operations (CONOP). This document is a conceptual overview of how the App proposed IT system will operate within the airport environment. It describes how the pro- end ix A posed IT system will interact with other systems as well as the burdens the new system will impose on responsible people or departments. The CONOP outlines specific roles and responsibilities of stakeholders, end users, system administrators, and others, and identifies processes and procedures that may need to be developed. Questions the CONOP addresses include: ­ Who will install the system? ­ Who will put data into the system? ­ Who will monitor the system and take action if there is a problem? ­ Who will take calls from users who have a problem using the system? ­ Who will actually fix parts of the system when they are broken? ­ Who will provide regular service (cleaning, restocking, lubricating) for the mechanical portions of the system? ­ Who will provide regular service for the software and data such as backups and updates? ­ Who needs to get data out of the system? ­ Who is going to monitor the quality control of the system? The CONOP is a very people-focused document describing how people and organizations will interact in the day-to-day operations of the system. · System definition. This document is the first attempt to define the requirements of the system, App including functional features, performance characteristics, other systems with which this system end ix A must interoperate, and important environmental considerations. These are all defined to the degree necessary for an initial budget to be developed later in the system planning phase. The system definition becomes the basis for discussing the system's primary features and a starting

OCR for page 32
34 Information Technology Systems at Airports­A Primer point for a more-detailed requirements definition once the project is funded. The system definition should address: ­ A system overview from the stakeholder's perspective. ­ The business area of the new system. ­ The needs the system will meet, mapped to the AMP or ITMP. ­ The systems relationship or interactions with other systems or entities. ­ Performance characteristics. ­ Support elements such as maintenance, training, manpower, and other resources needed. ­ Description of design considerations such as disaster planning, security, operational envi- ronment, and regulatory constraints. ­ Desired acquisition strategy and schedule. The system definition must adequately express the needs of the users requesting the system and should tie directly to the strategic objectives of the airport. 3.3.2 Cost­Benefit Analysis Having completed the system definition and CONOP, it is time to develop the budget and define the benefits of the new system. These will be used to evaluate the system by performing a cost­ benefit analysis. Evaluating the value of proposed systems is one of the more difficult tasks airport executives undertake. Chapter 5, Evaluating IT Investments, describes a detailed process and provides a standard scoring mechanism that airports can use to perform this activity, which is summarized here for completeness of the lifecycle description. There is a four-step methodology to performing a cost­benefit analysis: 1. Document system benefits. The system benefits are the most important component when evaluating the value of a system. Without benefits there would be no reason to invest in the system. It's important for stakeholders to agree on the expected benefits so they will support the value that is assigned. Some benefits have financial value, and others have intangible value that cannot be expressed in monetary terms. Make every effort to find the hidden financial value in nonfinancial benefits. 2. Determine TLC. A key factor in deciding to invest in a new system is the cost. Often capital (one-time) costs are the only costs used when making investment decisions. However, ongoing operations and maintenance costs should also be considered when evaluating a new system because many of the system benefits are derived during the O&M phase. The TLC of a system is defined as the sum of all one-time (nonrecurring) costs and recurring costs over the full life span of a system. For IT systems, the life span is usually only 3 to 7 years. 3. Perform the cost­benefit analysis. After the system benefits and TLC have been determined, a cost­benefit analysis can be performed. The TLC is weighed against the system's total expected benefits to determine if there is a positive return. Figure 3-4 shows a sample cost­benefit analysis. The formulas for the cost­benefit analysis can be complex and should be implemented by CFOs. a. Lines 1 through 3 represent the one-time costs of the system, and lines 4 through 7 represent the net of the recurring costs and the projected financial benefits of the system. From this data, three valuation criteria can be calculated: net present value (NPV), internal rate of return (IRR), and break-even point. b. Net present value brings all project costs into the present. If the result is positive, the project is worth doing. c. Internal rate of return is used to measure the profitability of investments. The higher a project's IRR, the more desirable it is to undertake. d. Break-even point determines the point in time that total savings resulting from the system benefits surpass the costs of implementing the system. Most airports look for payback periods in the 3-year time frame.

OCR for page 32
The IT System Lifecycle­A Common Process 35 Figure 3-4. Sample cost­benefit analysis. 4. Score system values objectively. The cost­benefit analysis discussed only takes into account benefits that can be quantified in terms of financial savings. When evaluating a potential investment in a system, the nonfinancial benefits need to be considered too. Refer to Chapter 5 for a score sheet that includes both nonfinancial benefits and valuation data from the cost­ benefit analysis. Upon completing the cost­benefit analysis, the results should be documented in a value propo- App sition. The value proposition is the key document for obtaining funding. Intended for management end ix and financial audiences, the value proposition document should provide a compelling argument as A to why the system is needed. In the value proposition, be sure to include a summary of the system definition and CONOP (in case the value proposition is the first document the reader sees) and a list of stakeholders with a description of their interest in the system. 3.3.3 Funding As the value proposition takes shape, potential funding sources are important to consider. There are many possibilities, so it's helpful to work in collaboration with the finance department to determine which sources are appropriate for the project. Table 3-2 examines typical funding sources for an airport IT infrastructure. Stand-alone IT projects (ones not associated with a large construction project) typically use airport funding. Often, the finance department will want to put the IT project into a larger cap- ital plan, which helps the airport organize and coordinate its funding applications but may delay an urgent project. This is a great opportunity to use the IT master plan to coordinate funding in the capital program so that outside funding is available when the project is slated to begin. Once the funding mechanisms are determined, the value proposition can be completed and a decision made about the overall value of the project in light of the following: · Available capital funding and external funding. · The stand-alone merits of this project based on its financial and nonfinancial value. · The relative merits of this project compared with others vying for the same funding. App If the project is selected for execution, a project charter is created that restates the project end ix scope, schedule, and budget and names the project manager and his or her authority to run the A project. Issuing the project charter transitions the project from the system planning phase of the IT system lifecycle to the implementation phase. Table 3-3 provides a management project

OCR for page 32
36 Information Technology Systems at Airports­A Primer Table 3-2. Typical funding sources.