National Academies Press: OpenBook

Information Technology Systems at Airports--A Primer (2012)

Chapter: Chapter 3 - The IT System Lifecycle A Common Process

« Previous: Chapter 2 - The IT Communication Triangle Solving IT Issues
Page 29
Suggested Citation:"Chapter 3 - The IT System Lifecycle A Common Process." National Academies of Sciences, Engineering, and Medicine. 2012. Information Technology Systems at Airports--A Primer. Washington, DC: The National Academies Press. doi: 10.17226/14622.
×
Page 29
Page 30
Suggested Citation:"Chapter 3 - The IT System Lifecycle A Common Process." National Academies of Sciences, Engineering, and Medicine. 2012. Information Technology Systems at Airports--A Primer. Washington, DC: The National Academies Press. doi: 10.17226/14622.
×
Page 30
Page 31
Suggested Citation:"Chapter 3 - The IT System Lifecycle A Common Process." National Academies of Sciences, Engineering, and Medicine. 2012. Information Technology Systems at Airports--A Primer. Washington, DC: The National Academies Press. doi: 10.17226/14622.
×
Page 31
Page 32
Suggested Citation:"Chapter 3 - The IT System Lifecycle A Common Process." National Academies of Sciences, Engineering, and Medicine. 2012. Information Technology Systems at Airports--A Primer. Washington, DC: The National Academies Press. doi: 10.17226/14622.
×
Page 32
Page 33
Suggested Citation:"Chapter 3 - The IT System Lifecycle A Common Process." National Academies of Sciences, Engineering, and Medicine. 2012. Information Technology Systems at Airports--A Primer. Washington, DC: The National Academies Press. doi: 10.17226/14622.
×
Page 33
Page 34
Suggested Citation:"Chapter 3 - The IT System Lifecycle A Common Process." National Academies of Sciences, Engineering, and Medicine. 2012. Information Technology Systems at Airports--A Primer. Washington, DC: The National Academies Press. doi: 10.17226/14622.
×
Page 34
Page 35
Suggested Citation:"Chapter 3 - The IT System Lifecycle A Common Process." National Academies of Sciences, Engineering, and Medicine. 2012. Information Technology Systems at Airports--A Primer. Washington, DC: The National Academies Press. doi: 10.17226/14622.
×
Page 35
Page 36
Suggested Citation:"Chapter 3 - The IT System Lifecycle A Common Process." National Academies of Sciences, Engineering, and Medicine. 2012. Information Technology Systems at Airports--A Primer. Washington, DC: The National Academies Press. doi: 10.17226/14622.
×
Page 36
Page 37
Suggested Citation:"Chapter 3 - The IT System Lifecycle A Common Process." National Academies of Sciences, Engineering, and Medicine. 2012. Information Technology Systems at Airports--A Primer. Washington, DC: The National Academies Press. doi: 10.17226/14622.
×
Page 37
Page 38
Suggested Citation:"Chapter 3 - The IT System Lifecycle A Common Process." National Academies of Sciences, Engineering, and Medicine. 2012. Information Technology Systems at Airports--A Primer. Washington, DC: The National Academies Press. doi: 10.17226/14622.
×
Page 38
Page 39
Suggested Citation:"Chapter 3 - The IT System Lifecycle A Common Process." National Academies of Sciences, Engineering, and Medicine. 2012. Information Technology Systems at Airports--A Primer. Washington, DC: The National Academies Press. doi: 10.17226/14622.
×
Page 39
Page 40
Suggested Citation:"Chapter 3 - The IT System Lifecycle A Common Process." National Academies of Sciences, Engineering, and Medicine. 2012. Information Technology Systems at Airports--A Primer. Washington, DC: The National Academies Press. doi: 10.17226/14622.
×
Page 40
Page 41
Suggested Citation:"Chapter 3 - The IT System Lifecycle A Common Process." National Academies of Sciences, Engineering, and Medicine. 2012. Information Technology Systems at Airports--A Primer. Washington, DC: The National Academies Press. doi: 10.17226/14622.
×
Page 41
Page 42
Suggested Citation:"Chapter 3 - The IT System Lifecycle A Common Process." National Academies of Sciences, Engineering, and Medicine. 2012. Information Technology Systems at Airports--A Primer. Washington, DC: The National Academies Press. doi: 10.17226/14622.
×
Page 42
Page 43
Suggested Citation:"Chapter 3 - The IT System Lifecycle A Common Process." National Academies of Sciences, Engineering, and Medicine. 2012. Information Technology Systems at Airports--A Primer. Washington, DC: The National Academies Press. doi: 10.17226/14622.
×
Page 43

Below is the uncorrected machine-read text of this chapter, intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text of each book. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.

3.1 Introduction This chapter introduces fundamental concepts of the IT system lifecycle that can be applied to the aviation industry. As implied by its name, the lifecycle is the process of managing the entire life of a system, from its conception through design, implementation, and ongoing operations until it is removed or replaced. Following a standard process in a deliberate, structured, and methodical way integrates people, data, and business systems from all areas of the airport and can generate a high-quality system that brings the following benefits: • Meets or exceeds customer expectations. • Reaches completion within time and cost estimates. • Works effectively and efficiently within established IT principles and infrastructure. • Is cost-effective to operate and maintain. Much has been written about system lifecycles, and many names have been applied to the phases and documentation that result from following a standard process. Regardless of the names, the lifecycle is a sequence of stages in which the output of each stage becomes the input for the next. There is no one definitive lifecycle model, but the stages generally follow the same basic steps, which, for the purposes of the primer, have been simplified into four key phases: • Strategic planning • System planning • Implementation • Operations and maintenance (O&M) Identifying requirements accurately and completely for a new system is vital to its successful implementation. Requirements are defined in progressively greater detail in each of the first three phases. At each phase, consensus between stakeholders and IT departments should be reached. The activities performed and the outputs of each phase are depicted in Figure 3-1. The reality of IT system lifecycle implementation is more complex than Figure 3-1 shows. People and departments cannot perform their tasks in isolation, and the activities do not flow sequentially, with one starting only after the previous one is finished. Many activities are carried out in an iterative process until all parties can agree on the outcome. The lifecycle portrayed here provides a common process that all organizations can implement to reduce time and costs, resolve conflicts faster, and create a commonly understood set of documentation supporting all systems. The following sections give a high-level description of each phase in the IT system lifecycle, including inputs, activities, and outputs. Outlines and templates of many of the lifecycle documents referenced in the text are included in Appendix A. 29 C H A P T E R 3 The IT System Lifecycle— A Common Process

3.2 Strategic Planning Strategic planning is the coordinated process by which the high-level aims of an organization are translated into individual projects. This phase is usually performed annually to establish or update the goals and high-level plans for the entire airport, including IT. Within the strategic planning phase, key tasks to accomplish include: • Airport master planning • IT master planning Figure 3-2 depicts the activities and outputs of the strategic planning phase. 30 Information Technology Systems at Airports–A Primer Strategic Planning Airport Master Planning IT Master Planning System Planning Concept Definition Cost–Benefit Analysis Funding Operations and Maintenance Help Desk Implementation Change Requests & New Requirements Project Charter Service Level Agreements (SLAs) & System Documentation System Administration MaintenanceUser Feedback Project Planning Design Procurement Deployment Capital Improvement Plan (CIP), IT Principles, & ITMP Figure 3-1. IT system lifecycle.

3.2.1 Airport Master Planning Airport master planning is the first step in the strategic planning phase. It is the initial activity that determines the current and future needs of the airport, translates these needs into airport projects and programs, and sets financial investment strategies for the planning period. The results of this step should include the following: • Airport goals. The airport goals document takes the needs and deficiencies of an airport and creates the positive statements necessary to address them. It is vital that the airport goals devel- oped be concrete and actionable. They should specify the anticipated beneficiaries and provide target metrics to measure success. Vague goals such as “better customer service” are difficult to translate into actions because they fail to specify the target audience (who the customer is) and the degree of improvement required (“better” can include marginal improvements). Examples of well-formulated goals are “Handle 10% more passengers with the existing terminal infrastructure within four years,” “Grow parking revenue 6% over the next three years,” and “Reduce inaccurate flight information complaints 30% next year.” • Airport master plan (AMP). An airport master plan is a long-term, multi-year document that takes the goals of an airport and maps them to major programs and projects. The aim of an AMP is to create a blueprint showing the intended state of an airport at the end of the planning period. AMPs are updated periodically to alter assumptions and ensure continued eligibility for FAA AIP grants. Future IT projects are often explicitly included or dramatically affected by the programs planned in the AMP. • Capital improvement plan (CIP). A capital improvement plan is a medium-term document that selects individual projects, often from the AMP, and develops preliminary, high-level financ- ing strategies. Available funds, the ability to raise revenue, and potential debt placement are considerations that must be evaluated in the document when projects are being prioritized. The CIP serves as an intermediate step between the long-term strategic plan provided in an AMP and the airport’s annual budget. These outputs are all used as input to the next step, IT master planning. The IT System Lifecycle–A Common Process 31 Strategic Planning Airport Master Planning IT Master Planning Airport Master Plan IT Principles ITMPCapital Improvement Plan (CIP) Figure 3-2. Strategic planning phase.

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 the IT systems of an airport and distills AMP programs down to the specific information tech- 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. 32 Information Technology Systems at Airports–A Primer Appendix A Table 3-1. Examples of airport goals enabled by IT.

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 proposed IT system will operate within the airport environment. It describes how the pro- 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, including functional features, performance characteristics, other systems with which this system 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 The IT System Lifecycle–A Common Process 33 Appendix A Appendix A System Planning Concept Definition Cost–Benefit Analysis Funding Project Charter Concept of Operations System Definition Value Proposition Change Requests & New Requirements Figure 3-3. System planning phase.

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. 34 Information Technology Systems at Airports–A Primer

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- sition. The value proposition is the key document for obtaining funding. Intended for management and financial audiences, the value proposition document should provide a compelling argument as 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. If the project is selected for execution, a project charter is created that restates the project scope, schedule, and budget and names the project manager and his or her authority to run the 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 The IT System Lifecycle–A Common Process 35 Appendix A Appendix A Figure 3-4. Sample cost–benefit analysis.

36 Information Technology Systems at Airports–A Primer Table 3-2. Typical funding sources.

checklist for ensuring that all the necessary activities have been completed and the appropriate documents created during the system planning phase. 3.4 Implementation Phase The implementation phase, which involves all efforts to manage, design, acquire, and deploy a new system, has four sequential activities, depicted in Figure 3-5. 3.4.1 Project Planning The main challenge of project planning is to stay within all project constraints (time, budget, and scope) while achieving the desired goals. A critical tool developed at this stage is the project management plan, which serves as a guide for implementing the project methodically from start to finish. • Project management plan. Guides all aspects of the implementation phase. Delineates how the internal project team will be organized, breaks down activities and tasks to be carried out, estimates the level of effort and funds required to complete each task, and provides detailed task schedules. Every project plan should: – Define scope and objectives clearly. – Define deliverables. – Create a detailed breakdown of each task from start to finish. – Identify the schedule for each task and dependencies among tasks. – Identify resources required to complete the project. – Estimate costs for each task involved in the project. – Discuss project communication channels. – Discuss risk management. For larger projects, several associated plans may be needed. Following is a list of plans for the project manager to consider developing in addition to the PMP. • Resource plan. Identifies and allocates the resources needed to complete activities in the proj- ect plan. The resource plan should include people’s roles and responsibilities, type and quantity of resources required (e.g., labor, equipment, and materials), and equipment specifications. The IT System Lifecycle–A Common Process 37 Appendix A Table 3-3. System planning phase checklist.

• Quality management plan. Defines quality expectations and clear quality goals for each deliverable and discusses the resources responsible for ensuring adherence to the plan. • Risk management plan. Identifies all anticipated project risks and how they will be mitigated before the project is implemented. • Acceptance plan. Outlines acceptance criteria indicating what is required for each deliverable to be successfully completed. This plan provides a schedule of acceptance reviews, giving stakeholders the opportunity to formally accept the original requirements. • Communications plan. Establishes methods and procedures for informing stakeholders of project progress; includes the types of information to be distributed as well as the methods and frequency of distribution. • Procurement plan. Describes the products to be acquired, outlines the product delivery schedule, and establishes the process for selecting vendors and procuring products. 3.4.2 Design Once the PMP has been approved, system design activities can begin, including developing system specifications and completing procurement documentation (if the system is to be acquired). Using the basic requirements agreed to during system planning and documented in the system definition, system designers must articulate detailed application requirements, functional require- ments, performance requirements, and system integration requirements. Collecting detailed, accu- rate requirements may require multidisciplinary teams with representatives from multiple organi- 38 Information Technology Systems at Airports–A Primer Implementation Project Planning Design Procurement Deployment Service Level Agreements (SLAs) System Documentation Project Management Plan System Specification Contract Procurement Documentation Project Charter Figure 3-5. Implementation phase.

zations. All stakeholders must agree on the system’s functionality and performance requirements. The outputs of this stage include the following: • System specification. Accurately and clearly defines the system’s full attributes, functionality, and performance requirements. System specifications help to: – Establish agreement among planners, customers, and suppliers about how the system meets the requirements. – Provide a baseline for validating and verifying the system. – Facilitate transfer of the system to its owners and users. – Serve as a basis for later enhancements. Areas that should be addressed in the system specification include: – Expected functionality. – External interfaces. – Performance metrics. – Security requirements. – Environmental requirements. – Attributes of the system (portability, maintainability, business rules, etc.). – Specific design constraints (equipment to be used, standards, etc.). – Acceptance criteria or test scenarios. The system specification is the key document included in procurement documentation given to potential suppliers to define the requirements they are to meet. These requirements must be clearly stated and agreed on by all stakeholders before the system specification is released for procurement. • Procurement documentation. When seeking competitive bids, be sure the procurement pack- age has all necessary elements and is advertised appropriately to ensure adequate responses. Among items to include in the procurement package are: – Procurement instructions and schedule. – Proposal format requirements. – Pricing format requirements. – Vendor qualification and reference requirements. – Statement of work for the vendor to accomplish. – Bid evaluation criteria and selection methodology. – A sample of the contract to be signed. – A detailed system specification. – A draft SLA. – Minority business enterprise/disadvantaged business enterprise (MBE/DBE) objectives. – Bond requirements (bid and performance). The complexity and level of detail of procurement documents should be consistent with the value and risks of the system being procured. Procurement documents should be rigid enough to solicit consistent responses from proposers so that fair evaluations of the solutions can be made. 3.4.3 Procurement The procurement process begins after the system specification and procurement documents are released to potential suppliers, who must be given adequate time to develop the required proposals and documentation. It is an intricate process that demands attention both to the time period allowed and solutions received to ensure that selection criteria are applied evenly. When seeking competitive bids, be sure the procurement package contains all necessary ele- ments and is advertised appropriately to ensure adequate responses. Strong attention must be given to local procurement rules and laws to ensure the process is fair. The culmination of this The IT System Lifecycle–A Common Process 39 Appendix A

stage is the signing of a contract—the binding agreement between the firm selected to imple- ment the system and the airport. The proposed contract is often included in the procurement package to allow review by prospective respondents before they submit a legally binding response. Contract details vary between jurisdictions and airports, but standard features to include are: • Schedule. • Pricing and payment terms. • Termination clauses. • Indemnification and limitation of liability clauses. • Insurance and performance bond requirements. • Conflict of interest disclosure. • Statement of nondiscrimination. • MBE/DBE objectives. • Acceptance criteria. • Service level agreement and penalty clauses. • Warranty and product support needs. To these features, a statement of work is appended that specifies requirements the vendor must meet, including: • Project management. • Schedule. • Reporting. • Shipping. • Installation. • Testing. • System cutover. • Training. • Operations and maintenance. • Documentation (project management, system, user, administrator, training). • System specification. When the procurement process is completed, the PMP must be updated to reflect revisions to cost, scope, or schedule resulting from contract negotiations with the selected vendor. 3.4.4 Deployment Deploying the system, the most complex task in the IT system lifecycle, is the culmination of the previous planning and documentation tasks, and it validates that all tasks have been completed correctly. Important steps in this phase include: • Building the project team. • Coordinating people and resources associated with the project. • Monitoring progress. • Loading necessary data from old systems. • Identifying and correcting issues. • Training end users and maintenance personnel. • Monitoring contract performance (if the system has been procured from an outside vendor). • Defining completion and acceptance criteria. • Performing acceptance testing to ensure that the final product complies with specifications and requirements. • Carrying out an operational readiness review to ensure that all logistical elements for operating and maintaining the system are in place (e.g., spares, consumables, staff, help desk). 40 Information Technology Systems at Airports–A Primer

• Ensuring that system documentation has been developed so that the system can be maintained and operated on an ongoing basis after it goes into service. These documents may include: – User manuals. – Operational manuals. – Technical manuals. – As-built drawings. – Training manuals. – System administration manuals. – Configuration management plan. • Developing the service level agreement. The SLA defines the performance of the system in ways that are meaningful to the end user. It can serve as a contractual agreement between the IT department and its service vendors or as an expectation of performance by the IT department for its end users. Typical characteristics of an SLA include: – System availability. How many minutes or hours the system was available divided by the total minutes in the period, expressed as a percentage. Examples of typical system availabil- ities are provided in Table 3-4. – Response time for certain transactions, often measured in the 90th or 95th percentile. (e.g., “3 seconds or less in the 90th percentile” means that 90% of transactions had a response time of less than 3.0 seconds. The other 10% could have been very long.) – Measuring system capacity or utilization against an agreed goal. – Data throughput. – Number of transactions. – Accuracy of data. – Responsiveness of the vendor. – Number of active users. – Number of trouble tickets. – Mean time to repair (often confused with “mean time to respond,” which does not include di- agnosis or repair). Table 3-5 provides a management project checklist for ensuring that all the necessary activities have been completed and the appropriate documents created during the implementation phase. 3.5 Operations and Maintenance Phase The term operations refers to the ongoing use of the installed system to provide benefits enumer- ated in the value proposition and project charter. The O&M phase consists of the system’s day-to- day operations as well as predictive and preventive maintenance such as periodically replacing hardware, deploying personnel to maintain the system, and putting end-user support processes, such as the help desk, in place. Figure 3-6 shows the activities occurring during the O&M phase. The IT System Lifecycle–A Common Process 41 Appendix A Table 3-4. Typical system availabilities.

3.5.1 Help Desk The help desk is the primary source of contact for users reporting technical malfunctions with a system. A service group for system users and administrators, the help desk leads and coordinates both in-house and external troubleshooting efforts. Problems are documented in the form of trouble tickets, which are tracked and acted upon until the problem is successfully resolved. • Procedures and processes to be developed for help-desk support should include, at a minimum: – Hours of help-desk operation and after-hours support process. – End-user processes for notification of system failures. – End-user processes for new service or changes to existing service. – Internal processes for level 1 troubleshooting. – Internal processes for escalating problems above level 1 support. 42 Information Technology Systems at Airports–A Primer Table 3-5. Implementation phase checklist. Operations & Maintenance Help Desk Maintenance Performance Measures Trouble Tickets Service Level Agreements (SLAs) System Documentation System Administration User Feedback Change Request & New Requirements Figure 3-6. O&M phase.

• Trouble tickets are usually classified by type of issue, which determines the appropriate inter- nal or external resource to address the malfunction. Until the issue is resolved, the trouble ticket is left open and the problem remains in the work queue, with issues of higher priority taking precedence in the workflow. 3.5.2 System Administration System administrators handle day-to-day operations to keep the system operating effectively and smoothly for users. They take ownership of the system documentation developed at the end of the implementation phase and keep it up to date; they may also generate trouble tickets to correct malfunctions encountered in day-to-day operations. • SLA enforcement is handled by system administrators, who collect system performance measure- ments in order to evaluate the system’s ability to meet performance goals and SLA requirements. • Performance measures established during system design are collected during the O&M phase to validate that system goals and user requirements are being met, enforce SLAs, and improve system and support methodologies. Performance measures must be objective and quantifiable. 3.5.3 User Feedback User feedback complements performance measures by capturing subjective aspects of the user experience to help signal emerging requirements, maintain user satisfaction, and address new needs as they evolve over the life of the system. • A change request is developed once a system’s performance and functionality diverge suffi- ciently from the original goals. The document should list the features that are absent from the current system and explain the forces motivating the change. • A new requirement is developed to suggest the need for a major system upgrade, replacement, or new system. 3.5.4 Maintenance Ongoing maintenance is a critical component of meeting availability targets in the SLA. Main- tenance, performed by system administrators or the system vendor, consists of both preventive and reparative activities instigated by an issue documented in a trouble ticket. • Preventive maintenance, a scheduled activity arranged to minimize its impact on operations, aims to prevent unplanned disruptions in service from hardware or software failures. • Corrective maintenance, a response to unplanned system malfunctions, may lead to change requests when problems recur so that systemic problems can be fixed or system upgrades initiated. Table 3-6 provides a management project checklist for ensuring that necessary activities have been completed and that the appropriate documents from the operations and maintenance phase have been created. The IT System Lifecycle–A Common Process 43 Table 3-6. O&M checklist.

Next: Chapter 4 - Guiding IT Principles for Airports A Common Framework »
Information Technology Systems at Airports--A Primer Get This Book
×
MyNAP members save 10% online.
Login or Register to save!
Download Free PDF

TRB’s Airport Cooperative Research Program (ACRP) Report 59: Information Technology Systems at Airports--A Primer is designed to help facilitate mutual understanding between airport executives and information technology (IT) professionals to enable them to work together effectively on IT projects. One of the goals of the report is to help airports achieve better performance and reliability of IT systems and fewer cost overruns and delays during system implementation.

ACRP Report 59 offers techniques to identify critical IT issues and communicate effectively on those issues. The report also addresses sound IT principles for implementing new IT systems, describes the benefits and value of various IT systems, and highlights the fundamental architecture concepts of IT systems as they relate to airports.

  1. ×

    Welcome to OpenBook!

    You're looking at OpenBook, NAP.edu's online reading room since 1999. Based on feedback from you, our users, we've made some improvements that make it easier than ever to read thousands of publications on our website.

    Do you want to take a quick tour of the OpenBook's features?

    No Thanks Take a Tour »
  2. ×

    Show this book's table of contents, where you can jump to any chapter by name.

    « Back Next »
  3. ×

    ...or use these buttons to go back to the previous chapter or skip to the next one.

    « Back Next »
  4. ×

    Jump up to the previous page or down to the next one. Also, you can type in a page number and press Enter to go directly to that page in the book.

    « Back Next »
  5. ×

    To search the entire text of this book, type in your search term here and press Enter.

    « Back Next »
  6. ×

    Share a link to this book page on your preferred social network or via email.

    « Back Next »
  7. ×

    View our suggested citation for this chapter.

    « Back Next »
  8. ×

    Ready to take your reading offline? Click here to buy this book in print or download it as a free PDF, if available.

    « Back Next »
Stay Connected!