7.3 Solution Availability
7.3.1 Solution Viability
An existing solution must be viable in order to be useful. This means that it must meet system standards and requirements, and ensure that the new capability can be compatible with the existing system. These requirements influence the structure of a solution as it is developed.
In addition to meeting technical requirements and standards, solutions are often shaped by national policy agendas, plans, and goals. Such visions and plans are often developed by leaders and those with authority in the system and can influence the change process by shaping problem definition and outlining the type of solutions that are acceptable. In addition, policy goals often influence the resources available for research and solution development. Since limited resources exist for research and development, in the case of the FAA only 1% of their budget, the allocation of resources can have significant impact on what lines of research and solution development are pursued and which are not. The NextGen plan is an example of a plan that sets research requirements and influences resource allocation. Such plans structure and limit the scope of potential research and solutions which can be helpful and limit the amount of time it takes to develop a new capability. However, by limiting potential options possibility for innovation and creativity is also limited.
7.4 Implications
Solution development plays a key role in transition by providing potential capability options that can used to address problems in the system. Based on analyzing past cases of transition in the air transportation system it is evident that developing solution in anticipation of pressure
In a system where most transitions occurs reactively in response to events, in order to best take advantage of pressure for change when it manifests, solutions must be developed in anticipation of needs. When solutions are ready they can be implemented rapidly leading to improved system capability. As a result, the role of the research and development community is to support transition by pro-actively developing potential solutions. However, if viable solutions do not exist, lengthy development is needed and transition is delayed. In some cases, when pressure for change is high, available but inadequate solutions may be implemented in response to pressure. In such cases it becomes difficult to later implement improved solutions.
Developing solutions in anticipation of need increases the risk that a solution will not be used.
The earlier the development the greater the uncertainty of how a problem will develop. A portfolio approach to solution development would help to minimize risk poses by uncertainties in what actions will be needed and used. In addition, the success of a development program should not be judged by whether or not every solution is used. Some amount of failed ideas must be expected in order to develop viable solutions in anticipation of system needs.
Chapter 8
Implementation Process
Once an action is selected, it needs to be implemented before a problem is considered addressed. This takes place during the implementation process shown in Figure 8-1 below, which depicts the detail model as constructed so far through the past 3 chapters. During this process stakeholder must develop detailed action plans, receive necessary certification and approval, and finally deploy a new capability in the system as shown in Figure 8-2.
Actions selected during the change process provide the inputs to implementation and specifi-cally to the detailed action development subprocess where technical specifications, detailed policies, and an implementation plan are developed. Once complete, the detailed action plan must pass through the certification and approval processes where safety, environmental, economic and other approvals are issued. These approval processes can be iterative and require changes to the selected actions to ensure that they can be approved. In addition, approval processes include opportunity for interested stakeholders to comment on proposals and influence the final form of the solution. As changes need to be made and stakeholders comment on projects stakeholder disagreements can reemerge and return the transition back to the change process step. This process of solution refinement is represented in the model by the solution refinement loop that feeds back to the change process. This loop can pose a barrier and delay implementation. Once a detailed solution exists and is approved, deployment can
Figure 8-1: Feedback Model Framework
begin. The result of the implementation process is the successful deployment of a new Air Transportation System capability.
While improving the capability of the system is the goal of transition, case studies indicate that implementation can take a significant amount of time. The time to implement a selected action can be long due to the inherent construction or deployment time of the solution. In addition, required approval and certification processes take time to complete. Finally, stakeholders can deliberately attempt to stall or derail implementation if it would result in an unfavorable change. Such delays can pose a barrier to transition resulting in long implementation time constants and potentially stalled transitions.
The time that a solution takes to implement is important because factors affecting the success of transition perish over time. For example pressure for change dissipates over time, especially if other issues rise to the top of the agenda space. Stakeholder agreements developed during
Figure 8-2: Simplified Approval Processes Necessary for Improved Operational Capabilities the change process can change as time passes and the context in which decisions were made changes. Such changes can result in the shifting of funding to other problems. Finally, technical solutions can be replaced by new better options as time passes potentially restarting the change process to determine if a different action should be selected.
It was found that the safety and environmental approval process, while necessary, can intro-duce substantial delays into the transition process, in some cases on the order of decades. The multiple steps required during these processes as well as the opportunity they provide for the re-initiation of stakeholder disagreements both contribute to implementation delays. During the implementation process, stakeholders who were outvoted during action selection can receive another opportunity to contest a planned system change. As detailed action plans are made, stakeholder disputes can reemerge and potentially require a new iteration of the change process. In addition, approval and certification processes include review periods during which stakeholders can comment on planned changes. Disagreements between stakeholders can be voiced during these comment periods and if differences cannot be resolved stakeholders may resort to litigation. The environmental approval process has been used by community groups
as a leverage point to initiate litigation in an attempt to prevent runway projects from moving forward. As a result, stakeholder issues remain an important dynamics during implementation.
Figure 8-3 integrates the impact of review processes that occur during implementation. In addition, this model captures the use of demand management due to its role as a potential solution to capacity problems. Since demand management does not add new system capability, but rather controls demand, it is represented by a separate arrow in the model.
Figure 8-3: Transition Model Including Implementation
Currently many attempted and planned system changes deal with addressing capacity prob-lems. As a result, many of the examples in this chapter deal with plans and attempts to implementing these solutions and the barrier that are being encountered. However, safety and security examples are used to understand cases when implementation can occur more rapidly.