Click for next page ( 60


The National Academies | 500 Fifth St. N.W. | Washington, D.C. 20001
Copyright © National Academy of Sciences. All rights reserved.
Terms of Use and Privacy Statement



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 59
APPENDIX A Example Document Outlines IT Master Plan Purpose The purpose of the IT master plan is to assess the condition of the existing system and map its applicability to the airport's master plan. The IT master plan correlates all of the IT depart- ment's goals and envisions projects that will support the airport's goals and keep the IT infra- structure current. Outline and Contents 1. Executive Summary High-level synopsis of the findings and conclusions intended to provide senior executives with a one- or two-page quick read of the complete document. 2. Terms and Acronyms Lists the terms and acronyms used in the IT master plan and provides their definitions. 3. Methodology Describes the approach used to construct the IT master plan. 4. Existing Systems Assessment Evaluates each independent system and its readiness to serve the airport's needs for the next 4 to 8 years. Examines the serviceability of the system, suitability to new evolving demands and requirements, conformance to standards (especially new ones), and ability to support the airport master plan. Mirrors the layers presented in the systems architecture section, pro- gressing from the most physical to the most software oriented. Parallels the International Standards Organization (ISO) Open Systems Interconnection (OSI) model and the organ- ization of systems in this primer. 4.1 Physical Infrastructure Identifies the conditions of the telecommunications rooms and cabling infrastructure and includes: Building facilities, including server room and telecommunications closets. Cabling infrastructure, including copper and fiber-optic. 59

OCR for page 59
60 Information Technology Systems at AirportsA Primer 4.2 Network Architecture Describes the current state of the wired and wireless networks at the airport or under man- agement by the airport administration. Local area network topology. Wide area network topology. Wireless networks. Addressing, virtual local area networks (VLANs), and routing. Security including firewalls, remote access, and so forth. Network administration and operations. 4.3 Application Systems Airport operations systems. Passenger processing systems. Business, finance, and human resources. Safety and security systems. Basic office systems. Building systems. 4.4 Interoperability and IT Management Systems Documents the current state of systems designed to provide interoperability among the other systems in the lower layers of the model. Includes systems management tools and inte- gration tools. 5. Management Describes the existing staff organization, charter of the IT department, project management methods, guiding IT principles, and budgets. May be appropriate to include a 360-degree evaluation of the IT department based on interviews with stakeholders. 6. Business Models Describes any shared tenant business models, pricing, take-rates, and so forth, as well as cost allocation schemes and ways that labor is calculated in projects. 7. Benchmarking Reports metrics from peer airports to provide comparisons, including the type and numbers of systems, size and organization of staff, and capital and operating budgets. Including basic airport comparison metrics such as number of passengers, gates, and/or traffic mix is useful. 8. Technology Plan Lays out the important evolutionary changes required to maintain a current IT environment that serves the needs of the airport and its tenants and passengers. Should offer a cure for all deficiencies identified in the existing conditions. It is helpful to organize the technology plan into project-sized initiatives that are small enough to be funded and completed in a single fis- cal year, which allows for systems definitions, CONOP, and value propositions to be quickly developed. 9. Transition and Action Plan Prioritizes the recommendations from the previous sections and organizes them into a road map with recommended funding, presents a year-by-year capital budget, and includes a gap analysis that summarizes the deficiencies between the existing system and the technology plan. 10. Management and Staffing Recommendations Describes, in light of the newly created technology plan, how management must adapt to enact these changes. May include recommendations for staff reorganization, redistribution, and/or retraining; business model modifications; alterations to the IT principles; assessment of outsourcing alternatives; and a 5-year projected O&M budget.

OCR for page 59
Appendix A 61 Concept of Operations Purpose The concept of operations document, used to ensure consensus among users, operators, and developers, describes the effort required to operate the new system after deployment. It should briefly describe the system as well as users' expectations for the new system, the operational envi- ronment, operation scenarios, support environment, and impacts to other systems and organi- zations. The intended audience includes technical and nontechnical personnel. Outline 1. Scope Contains the title and overview of the new system. 2. Terms and Acronyms Lists terms and definitions of acronyms used in the document. 3. Applicable Documents Lists by title any documents that are referenced or are applicable to the system. 4. Current System or Situation Analyzes current system capabilities and limitations as well as the motivation for the new sys- tem. Describes current users and support environment. 5. New System Description and Justification Describes the new system's attributes, capabilities, and interfaces, summarizes benefits to be achieved, and provides justification details such as missions, objectives, and limitations of current systems. 6. Concept for New System 6.1. Description of the New System, to Include: Operational environment. Major system components. Interfaces to other systems and data flows. Capabilities or functions of the new system. Data flows. Performance characteristics Quality attributes (reliability, accuracy, flexibility, availability). Safety/security requirements. 6.2. Operational Policies and Modes of Operation Hours of operation, staffing constraints, hardware constraints, space constraints, and modes such as standard, after hours, maintenance, emergency, and backup. 6.3. Organizational Structure 6.3.1. System Users Identifies system users and how they interact with the system, the organizational struc- ture, and required skill levels. 6.3.2. Support organization Identifies the support organization, facilities and equipment, maintenance concepts, and supply methodology. 7. Operational Scenarios Describes step by step how the new system should operate under varying circumstances as well as what it should not do. Each scenario describes a specific operational sequence that

OCR for page 59
62 Information Technology Systems at AirportsA Primer illustrates the system's functions and its interactions with users and other systems and includes events, actions, inputs, and data. 8. Expected Impacts Describes the operational impacts of the new system from the user's perspective, which allows affected organizations to prepare for changes the system implementation will bring about. System Definition Purpose The system definition is a high-level requirements document that describes the need for a new capability. It is the first attempt to define the system's scope, serves as a starting point for defin- ing requirements (which is carried out in detail later in the system specification), and should be written so that both users and technical personnel can understand it. The system definition may refer to trade studies and feasibility studies performed. Outline and Contents 1. Scope Identifies the needed system by name, concisely describes the needed application or product, and specifies whether the system is an upgrade or correction to an existing system. 2. Terms and Acronyms Lists the terms and acronyms used in the document and their definitions. 3. Applicable Documents Lists by title any documents that are referenced in or applicable to the system definition. 4. Business Environment Defines the business area in which the need exists and relationships with other business areas. 5. Description of System Describes the needed system or capability in terms of shortcomings of existing systems or new functionalities needed. 5.1 Functional Capability Describes functional application needs and interfaces with other systems. 5.2 Operational Capability Specifies operational performance requirements and goals such as system capacity and throughput. 5.3 Service and Logistical Support Describes support elements needed to achieve effective operations, such as maintenance, supply, support personnel, facilities, and training. 5.4 Other Considerations Describes other issues that could have an impact on the system, including disaster planning, environmental impacts, and security requirements. 6. Suggested Solutions Describes the proposed solution, acquisition strategy, system deliverables, test strategy, and alter- natives that could be pursued to satisfy the requirements such as an existing system upgrade. 7. Schedule Discuss the desired schedule for capability availability.

OCR for page 59
Appendix A 63 8. Cost Estimate and Funding Provides a high-level estimate of the total costs to implement the system and identifies the reference resources used. Also describes ongoing operational and maintenance cost assump- tions and discusses potential funding sources for the new system. Value Proposition Purpose The value proposition presents economic and non-economic arguments about why the proj- ect should be funded and completed, defines benefits that will be measurable after the project is completed, and describes stakeholders. Outline and Contents 1. System Description A brief restatement of the CONOP and system definition, which are fundamental building blocks for the value proposition. 2. Terms and Acronyms Lists and defines terms and acronyms used in the value proposition. The acronym list in Appendix C of this primer is a good source of definitions. 3. Applicable Documents Lists by title any documents that are referenced in or applicable to the value proposi- tion, including the CONOP and system definition, and possibly the airport master plan, IT master plan, publications from regulatory agencies, revenue studies, and oper- ational cost studies. 4. Stakeholders Describes all departments and external entities with a say in whether the project gets funded; includes beneficiaries of such improvements as more efficient workflow, lower costs, increased revenue, or better service; and indicates those who may have to contribute to the system--including parties that may not receive direct benefits. 5. Benefits Lists each benefit the system delivers and which stakeholders receive each benefit, both finan- cial and nonfinancial. Examples of typical benefits include: More revenue. Lower costs. Reduced paperwork. Fewer errors. More accurate information. Faster or broader access to information. Fewer incidents. Regulatory compliance. Improved safety and security. 6. Nonfinancial Value Describes nonfinancial value, such as: Meets strategic objectives. Improves airport safety.

OCR for page 59
64 Information Technology Systems at AirportsA Primer Improves airport security. Regulatory requirement. 7. Financial Value Estimates and explains benefits that can be quantified in dollars, such as: Increases in net revenue. Reductions in net operating costs related to: The direct operating costs of the system itself. Retirement of direct costs from the old system. Labor to operate the system. Labor no longer required to operate the old system. Changes to indirect costs due to the new system. Changes to indirect labor due to the new system (work that no longer has to be done). Capital avoidance/deferral. 8. Capital Cost One-time project-oriented expense required to deliver the financial and nonfinancial value, which is typically made up of direct and indirect capital costs. Direct capital costs should be supported with vendor estimates or quotes when possible. Indirect costs should be estimated and accompanied by an explanation of how the estimate was made. 9. Return on Investment Calculates return on investment using internal rate of return, net present value, or break- even point. Should be derived entirely from estimates in the financial value and capital cost sections. Project Charter Purpose The project charter, completed after project funding is approved, initiates the implementa- tion phase. It identifies the project manager (PM) and his or her authority, gives the PM the go- ahead to commence project planning and obtain a project number, and states the project's scope, schedule, and budget. Note: This outline for a project charter has been aligned with the Project Management Insti- tute's A Guide to the Project Management Body of Knowledge (PMBOK Guide), Fourth Edition, published 2008 (Project Management Institute, 2008). Outline and Contents 1. Project Purpose or Justification Summarizes of the value proposition. 2. Measurable Project Objectives and Related Success Criteria These are derived from the value proposition, CONOP, and system description. The updates should reflect any goals or success criteria introduced by the type of funding or in final nego- tiations to get the project approved. 3. High Level Requirements These are restated and updated (post-funding) from the system definition. The updates should reflect any constraints or requirements introduced by the type of funding or in final negotiations to get the project approved.

OCR for page 59
Appendix A 65 4. Summary Milestone Schedule A set of dates indicating the objective time frame the project must meet. It must include any date constraints imposed by the stakeholders, funding type, fiscal year, regulatory deadlines, or other deadlines, such as vendor offer windows. 5. Summary Budget Restates the value proposition sections estimating both direct and labor capital costs. Also states the funding sources and identifies the type of funds to apply to specific portions of the capital budget. 6. Project Approval Requirements Defines what is meant by successful execution of the project (in other words, what "done" means) and specifies who decides when the project is done as well as who signs off on it. 7. Assigned Project Manager Identifies the individual with authority to act as the project manager and verifies his or her authority to accept deliverables, approve payment of invoices, and assign tasks to other departments and vendors (via normal procurement channels). If a procurement is planned, this section should identify the source selection board (SSB) or define the project manager's authority to select the SSB. 8. Authorization Provides name, title, and signature of the manager with authority to assign the project man- ager and delegate the responsibilities mentioned previously. In most medium and small air- ports, this is likely the CEO or airport director. In larger airports, other senior executives may be given this authority, perhaps up to a certain project dollar ceiling. Project Management Plan Purpose The project management plan is a management document that defines the overall plan for the project. It should describe the tasks, schedule, resources, and costs for completing the project in accordance with project objectives. Outline 1. Scope Contains the title and a brief description of the system. 2. Terms and Acronyms Lists terms and definitions of acronyms used in the document. 3. Applicable documents Lists by title any documents that are referenced or are applicable to the system. 4. Project Overview 4.1. Project Objectives Describes project goals as stated in the system definition, IT master plan, or airport mas- ter plan. 4.2. Project Description Briefly describes the project in a way that reflects the system definition and project requirements.

OCR for page 59
66 Information Technology Systems at AirportsA Primer 4.3. Assumptions and Risks States assumptions made about the system or the project execution; includes constraints regarding technology, schedule, or budget; addresses the strategy for monitoring, evaluating, and mitigating risks, which might relate to technology, schedule, or resource availability. 5. Organizational Responsibility and Authority Specifies roles and responsibilities of all organizations associated with the project, including contractors, and provides an organizational chart identifying key personnel. Responsibilities may include: Project management. Technical performance. Quality assurance. Configuration control. Training. Interorganizational coordination. Signature authorities from each organization. 6. Work Breakdown Structure (WBS) 6.1. Project Tasks Provides a detailed breakdown of tasks needed to perform the entire project and associ- ates each task with a number, description, purpose, needed inputs, expected outcome, and deliverables. 6.2. Project Deliverables Describes each project deliverable and cross references it to the associated task. 6.3. Responsibility Matrix Identifies responsibilities of each person or organization associated with the project and assigns each task identified in the WBS to at least one organizational unit. If multiple organ- izations are involved, primary and support roles should be identified. It is useful to complete a spreadsheet with hours by resource by task. Estimate the level of effort and commitment required of the assigned resources and obtain buy-in from the organizational management regarding the resources' availability. 6.4. Schedule and Milestones Provides a schedule of all tasks and major milestones for the duration of the project, includ- ing training, reviews, testing, system acceptance, and system cutover, and indicates depend- encies among tasks. A program management software tool is helpful in managing task schedules and dependencies. 7. Budget 7.1. Funding Profile Addresses all sources of project funding and amounts from each source. 7.2. Cost Estimate by Task Provides a breakdown of the budget by task, including budgets for hardware, software, project management, special facilities, subcontractors, and other direct costs. 8. Reporting and Communications 8.1. Project Reviews Describes formal and informal communications between the project manager and all organ- izations associated with the project, including stakeholders and future support personnel. Specifies the frequency of project reviews and personnel who should attend.

OCR for page 59
Appendix A 67 8.2 Project Tracking Specifies the plan for tracking the project, including mechanisms for tracking cost, schedule, task progress, action items, and risks. When using a project management tool, specify the reports that will be generated to reflect project status. System Specification Purpose The system specification is a requirements document that establishes the functional, perfor- mance, design, and testing requirements of a system. Outline 1. Scope Contains the title and purpose of the system. 2. Terms and Acronyms Lists terms and definitions of acronyms used in the document. 3. Applicable documents Lists by title any documents that are referenced or are applicable to the system. 4. System Requirements Specifies the requirements for the system. 4.1. General Requirements Describes the system, with emphasis on pertinent operational and logistical considerations. It is helpful to reference the CONOP and include a system diagram. 4.2. Detailed Requirements 4.2.1. Functional Requirements Describes the system's functional requirements. Each requirement should be numbered separately. 4.2.2. Performance Requirements Describes the system's capabilities in a quantitative manner, including system capacity and capacity reserve. 4.2.3. Interface Requirements Describes interfaces required with other systems. Each interface should be numbered separately and described in detail. 4.2.4. Quality Requirements Specifies quality requirements in a quantitative manner, such as reliability, availability, maintainability, correctness, and efficiency. 4.2.5. Environmental Conditions Specifies the environmental conditions the system must withstand during operations. 4.2.6. Flexibility Specifies areas for potential growth and expansion, and highlights areas that might require additional capacity.

OCR for page 59
68 Information Technology Systems at AirportsA Primer 4.3. Design and Construction Requirements Specifies system design and construction standards that might be applicable to the system equipment--whenever possible by incorporating established standards and specifications. Items to consider including are materials, product marking, safety, and human engineering. 4.4. Security Requirements Specifies security requirements necessary to protect the system physically and to prevent sensitive information from being compromised. 4.5. Documentation Specifies documentation required for the system, including specifications, drawings, technical manuals, acceptance test plan, user's manual, operations manual, quality assurance plan, and configuration management plan. 4.6. Personnel and Training Specifies the number of personnel and skill level required for operational support and maintenance, as well as training requirements and training plan for support personnel. Service Level Agreement Purpose A service level agreement sets clear expectations between a service provider and a service sub- scriber about the quality of the service and the way it will be managed. In airports, SLAs may refer to the IT department as the subscriber and a third party (such as a network or maintenance ven- dor) as the service provider, while simultaneously the airport IT department is the service provider and its subscribers are other airport departments and tenants. The SLA outline is gen- erally written as an attachment to a larger general contract; if the SLA is to be the contract it will need many routine legal provisions. Outline and Contents 1. Service Description Provides a high-level description of the service, its intended purpose, hours of operations, and the regulatory environment in which it is provided. May also define the meaning of minor, major, and catastrophic failures. 2. Physical Service Boundary Defines the physical point at which the service provider's responsibilities end and the sub- scriber's responsibility begins. (A drawing here is usually very helpful.) In a maintenance SLA the geographic area or specific sites should be identified. 3. Performance Metrics Defines the service performance covered by the SLA, describes how it is measured, and states expected and minimally acceptable levels. Performance metrics vary by the system, but may include: System availability. Average station availability. Mean time to respond (electronically or in person). Mean time to repair. Mean time between failure. Error tolerance.

OCR for page 59
Appendix A 69 Latency or relay (e.g., response time). Number of simultaneous users. Transaction processing volume. Throughput. Percentage of problems resolved in a specific time frame. 4. Trouble Reporting Procedures Describes how the subscriber should notify the service provider of problems, how the service provider will track and provide status on corrective actions, and how close-out procedures are handled. Identifies who can report trouble, specifies who receives the trouble report, and includes contact information. 5. Subscriber Responsibilities Defines the subscriber's role in maintaining service quality. If penalties are contractually tied to performance that the SLA describes, this section is the one most likely to be used to escape penalties. Subscriber responsibilities might include: Providing access to technicians at any hour of the day. Providing storage, staging, or office space for technicians. Providing specific information when reporting trouble. 6. Escalation Procedures Describes how the service provider notifies both its own management and the subscriber management when a problem exceeds severity or duration thresholds. Defines the form and frequency with which the service provider must provide status updates of a problem. 7. Reporting Describes the type and frequency of reporting from the service provider to the subscriber. Reports typically use the performance metrics and often compare results over multiple reporting periods. 8. Maintenance Windows Describes maintenance windows, usually at low-traffic periods, that may allow the service provider to be relieved of meeting the performance metric objectives. May also contain noti- fication procedures and timing the service provider must conform with when notifying the subscriber of a planned change to the service. 9. Subscriber Access Describes tools at the subscriber's disposal for accessing data automatically from the ser- vice provider and specifies who is granted access in the subscriber organization. Such data might include: Reports on service performance. Trouble ticket information. System status. Knowledge base and FAQs.