This page includes all content for this chapter.
Chapter 7: Launch Common Use Initiatives
Project definition and requirements development activities establish the critical foundational elements for success in launching new common use initiatives. For example, your first initiative may be a small common use passenger processing system (CUPPS) implementation along with some self-service options, or it may be an airport-wide CUPPS expansion including the latest innovations. It could be a rule-based gate allocation methodology or perhaps an implementation of a digital twin that enables the integration of data from all common use and airport operational systems to create situational awareness and predictive analytics.
Regardless, you can use the following best practices in project definition and requirements development, as summarized in Figure 7.1. Though these are more typically seen in system implementation projects, keep in mind that much of this can be applied to other initiatives, such as new methodologies or processes.
Figure 7.1: Project Definition and Requirements Development
Project Definition
It is essential to clarify and document the relevant parameters that define each specific project. Though the program's overall purpose, goals, and objectives will have already been documented under the common use management framework described in Chapter 6, each initiative needs to define those elements as they specifically relate to each unique project.
The following items encompass important starting points for ensuring project success and should be defined at the level of depth and formality that is appropriate for the scope and scale of the project. The project definition is key to initiating the project and moving it forward; in addition, a more detailed project management plan will be highly beneficial for enabling effective management of the project, whether developed internally or by a contracted solution provider.
Scope
A clear and unambiguous project scope must be developed that defines what the project is intended to accomplish. It should speak to the relevant stakeholder needs or challenges that the project is intended to address, as well as to any known assumptions or constraints. It should also consider any related projects and define the expected deliverables of the project.
Schedule
A schedule should then identify key milestones and any critical dependencies, including a high-level work breakdown structure (WBS) of key tasks required to achieve each key milestone. A detailed WBS should be created as part of the detailed project management plan.
Budget
The budget needs to be clearly established, along with any conditions or constraints that must be considered. This could include allocations tied to fiscal years or the specific items that the funds can and cannot be spent on based on the source of the revenue.
Risk and Quality Planning
A high-level risk assessment and quality plan should be conducted as part of the project definition, with the expectation that a quality management and control plan and a detailed risk assessment will be part of the project management plan. Known risks to the scope, schedule, budget, and quality should be defined with general mitigation plans for each.
Project Team
The project team members, including a project manager, subject matter experts, and other supporting staff, need to be identified to the extent possible. Depending on the scope and scale of the project, it may also be necessary to identify a project-specific steering committee. This committee should have representation from the key stakeholders affected by the project, including airlines, TSA, CBP, and others, where appropriate. Projects will often be overseen by airport staff and executed by contracted firms. Either way, the roles and responsibilities should be defined for internal resources as well as any outsourced resources.
Requirements Development
One of the most critical aspects in determining the success or failure of a technology-related project is the quality of the solution requirements. All too often, an airport releases a request for proposals (RFP) for a system that either has insufficiently defined requirements or that reuses the requirements from an RFP that another airport previously released. In some cases, these requirements may provide much of the needed value. However, there are requirements that should be uniquely tailored to your airport that, when left generic, can result in the need for several change orders or even a failed project.
One way to mitigate these risks is by including a professional business analyst on your project team. Regardless, when done right, the following activities will help ensure the solution procured is in full alignment with the needs of your airport.
Requirements Analysis
The requirements development process should start with the identification and analysis of relevant information related to the airport's objectives and current capabilities, as well as the specific pain points and challenges being faced. The requirements analysis should include documentation review and interviews with all of the relevant business units and other stakeholders as appropriate, to define the functionality of the existing systems, current and proposed requirements of the system processes, and the airport's policies, procedures, and standards regarding maintenance, operation, and security.
Process Flow Development
After defining the current requirements, the next step should be to prepare annotated process flows to validate the information collected. These process flows should describe the major functionalities and users of the current system. This helps to resolve one of the primary challenges of existing systems, which is a disconnect with the current business processes. Alternatively, the need is sometimes to transform or streamline the current business process.
Requirements Development
With the process flows defined, the requirements documentation can be developed, including functional, integration, and technical requirements. This effort includes requirements prioritization, definition of interfaces/integrations, technical and business constraints, and assumptions.
With these elements in place, it is time to procure solutions, a process described in Chapter 8.