Annex C provides guidance to personnel who are providing input to, or developing applications for, approval of Flight Conditions and Military Permits to Fly (MPTF). This annex identifies good practices, and discusses how to avoid common issues, to support applicants in developing a credible and defensible submission likely to have minimal need for clarification or re-work. This is especially important when a short turnaround is required to meet capability imperatives.
Since the introduction of DASRs, DASA has issued MPTFs for a broad range of flying activities, spanning single short-notice ferry flights to a suitable maintenance venue, to primary authorisations for aircraft not yet certified. In many cases these have required a quick turn-around, both from the applicant and the Authority, to support capability imperatives. During this time, DASA has identified a number of common issues with applications for Flight Conditions and MPTFs that reduce the credibility and defensibility of the ‘decision-to-proceed’ with an activity, resulting in delays to approvals, or the need for re-work. This annex has been developed to provide guidance on how to avoid these common issues.
Role of the Operator
An MPTF is required because an Operator needs to fly an aircraft that does not meet the applicable airworthiness or aviation safety requirements. While non-compliances against airworthiness requirements are often technical in nature, and technical support will be required from the Military Type Certificate Holder (MTCH) or a relevant design organisation, the MPTF is ultimately an operational authorisation.
Good practice: Ensuring that the application focuses on understanding and managing the risk to safe flight operations and that the application has clear input from both suitably-knowledgeable technical personnel and the Operator.
Common issue: Providing a design-centric document with a final Operator signature. Often Risk decision briefs lack the operational ‘so what’ of a technical issue. This makes it difficult to fully appreciate the risks associated with a technical issue.
Prioritising Risk Management
Applications for approval of flight conditions and MPTFs must include the seven-step risk management process documented clearly, concisely and completely, with both technical and operational input. The risk management for the non-compliance with applicable airworthiness or aviation safety requirements (and the documentation of that risk management) must be completed before developing the applications for Flight Conditions and MPTFs.
Good practices:
Focusing on completing and documenting credible and defensible risk management for the identified issue before commencing an application.
Ensuring that the risk assessment clearly addresses the seven steps and that work completed by the applicant is linked to the relevant steps.
Ensuring that the proposed flight conditions and/or restrictions in the applications are clearly linked to the outcomes of the seven-step risk management process. That is, controls that have been identified as reasonably practicable in the seven-step process must then be translated into the conditions and/or restrictions for the Flight Conditions and MPTF.
Common issues:
Developing the risk management and resulting documentation solely for the applications.
Developing risk documentation with the sole or primary intent of satisfying the Authority. The focus of the risk management (and associated documentation) is to manage the risk (IAW WHS requirements).
Deciding on the flight conditions prior to completing the risk management and then attempting to ‘reverse engineer’ the risk management process to support the pre-determined outcome.
Providing a collection of disparate documents or pieces of evidence without providing an overarching narrative or linking to the seven-step process.
Applications presented in this way often experience delays while the Authority attempts to understand the material provided and/or seeks clarification from the applicant. In some cases it is not ultimately possible to confirm that such an application presents a credible and defensible basis to proceed with the activity.
DASA has found that when applicants submit a collection of documents not integrated by a single overarching risk management document the likelihood of other errors and omissions in the documentation increases significantly.
Co-ordination Between Technical and Operational Assessments
Applications must provide operational and technical assessments that are co-ordinated. Note, the assessments may differ in places but those differences are always identified and explained in the application.
Good practice: Developing a single assessment that considers both technical and operational perspectives is best practice. Where this is not practical, it is good practice to provide an operational perspective on the technical assessment. This should explain why recommended controls might not be reasonably practicable from the operational perspective, or why the risk is different in the operational context.
Example: The technical assessment may recommend that a control, such as ‘only one person allowed near equipment during operation’ be implemented. The operational assessment determines that this control is not reasonably practicable based on the capability imperative for the task. The technical assessment does not need to be changed, but the operational assessment needs to clearly show that the control has been considered and assessed as not reasonably practicable, and then the impacts on the remainder of the assessment also need to be considered (i.e. are there other controls that now become reasonably practicable instead and does the risk characterisation change).
Common issues: Providing operational and technical assessments that have differing risk levels or different controls, without clear justification for the differences. It must be clear in the application that there has been co-ordination between the two assessments rather than them being done in isolation.
Justifying the Capability Imperative
The application must clearly communicate the operational context and capability imperative for operating an aircraft which does not meet airworthiness or aviation safety requirements.
Good practice: Justifying why the aircraft needs to operate despite the aircraft not satisfying the airworthiness or aviation safety requirements of DASRs. The capability imperative must establish the context for the assessment of risk controls and provide the basis for Command’s ‘decision-to-proceed’. Establish the minimum period for retention of the elevated level of risk.
Common issues:
Stating ‘Directed tasking’ or ‘to enable operations beyond expiry of [extant MPTF]’. This is unlikely to be defensible as it does not provide the detail needed to understand the context of the risk management or to justify a decision-to-proceed.
Submitting an application that does not match the stated capability imperative. For example, stating the capability imperative is that the aircraft must be returned to home base, but requesting an MPTF for 12 months. In this case the decision-to-proceed is unlikely to be defensible.
Extensions to Existing MPTFs
Justification is required for applications looking to ‘extend’ existing permits/authorisations. The updated application must provide detail on why the MPTF is still required and why it was not possible to resolve the issue or gain a permanent approval in the original timeframe. For example, if a MPTF was issued for 12 months to enable certification activities to be completed, and 12 months later it is being extended, there needs to be explanation for why certification activities were unable to be completed in the original timeframe, and what is being done to ensure that they will be completed as soon as practicable (noting that completion of the certification is a risk control and therefore should be completed as soon as reasonable practicable).
Good practice:
Reconfirming that the capability imperative remains valid for the context and timeframe of the ‘extension’. This requires confirmation that the requirement to operate with the identified non-compliance(s)/risk remains valid, taking into account the delays to the original timeframe.
Reassessing the risk characterisation in light of the new context, new information received, additional work performed and the new exposure period.
Reassessing the risk controls to confirm existing controls have proven effective, and to identify whether any new controls, or controls previously not reasonably practicable or available, are now able to be implemented.
Common issues: Submitting the same application that was originally provided, with just a change to the dates and no detail or substantiation relating to the delay. The delay will always change the context of the application and, as such, not considering this changed context will not be credible or defensible.
Scaling Applications
The scope and timeframe of the requested authorisation must be constrained to match the capability imperative and timeframes available.
Good practice: Limiting the scope and duration of an urgent application to only what is necessary for the urgent task. If there is a need for greater scope and duration after the initial activity, this can be provided in a subsequent application, which allows for appropriate ‘ensure’ and ‘assure’ activities to occur.
Example. An MPTF is required to enable a ferry activity in the next few hours to get an aircraft back to home base. However, it is expected that the aircraft will continue to operate in the same configuration for the next 12 months. An initial application can be provided which allows for only ferry, which is of limited duration and allows a limited scope of flying, to support the immediate task. This will constrain the risk context associated with the permit/authorisation and align that risk context with the reduced time for both ‘ensure’ and ‘assure’ activities to occur. Once the initial permit is provided, an expanded application can be completed, covering the risk for the greater timeframe and greater scope of flying, with appropriately scaled assessment and substantiation.
Common issues: Submitting an application requesting a large scope and timeframe, where there is an urgent capability imperative which limits the ability to develop full substantiation for that scope, or which limits the time available to review the full scope of the application.
Example. An MPTF is required in 3-4 hours, to conduct a transit flight based on an urgent capability imperative. The applicant submits an application for a 12 month permit/authorisation to conduct the full scope of aircraft operations as detailed in the Statement of Operating Intent and Usage (SOIU). It is unlikely that the applicant has adequately completed ‘ensure’ activities to support a 12 month permit/authorisation in such a reduced timeframe, and work on both the applicant and Authority side to assess this ‘full-scope’ application, instead of solely focusing on the scope required for the urgent task, will likely cause delays.
Commencing Work Early
Work on risk management (IAW the seven-step risk management process) and applications for Flight Conditions and MPTFs should commence as soon as the need is identified. Often the non-compliance with airworthiness or aviation safety requirements creating a risk and resulting in a need for an MPTF can be forecast well in advance.
Planned deliveries of new aircraft, integration of modifications prior to certification, and operation of aircraft with expired Airworthiness Limitations (AwLs) due to logistics shortfalls, are common examples of situations where the issue requiring an MPTF is not a surprise. Completing risk management and applications for respective authorisations only once the need and timeframe are critical will often lead to a flawed approach which is unlikely to be credible and defensible.
Good practice: Commencing work on risk management and the applications when the issue is identified.
Common issues: Waiting until the need for the MPTF is critical before commencing development. This approach often leads to flawed risk management, where the operational and technical activities are already ‘locked in’ and the resulting risk management is merely intended to justify what is already being done. This routinely results in:
Controls commonly used in these circumstances across Defence aviation not being identified nor considered.
Appropriate subject matter experts not consulted or if consulted, provided insufficient time to provide adequate advice.
Risk management documentation that is rushed, poorly integrated and contains errors and omissions.
Note: Applications developed at the last-minute will often identify that controls are not reasonably practicable to implement at that late stage due to lack of time. This may appear to be justifiable at the time of the application, and therefore support a claim that the risk has been eliminated or otherwise minimised So Far As in Reasonably Practicable (SFARP). However, if an unnecessary delay in commencing the risk management process resulted in a reduction in the reasonably-practicable controls, the applicant must be aware that defensibility and credibility of their position may be reduced in the event of an occurrence.
Justifying the Urgency
The Authority appreciates that short turn-around applications are sometimes necessary to support capability imperatives. In order to be able to appropriately prioritise resources across a range of platforms and activities, it is important for DASA to understand the priorities and urgencies for each, to provide the best support possible. As such, when a short turnaround is required for an application, the reason for the urgency and the need date must be clearly established.
Good practice:
Engaging the Authority at the earliest opportunity if a short turnaround application is expected, to allow the Authority to identify resources to support.
Ensuring that urgent/high-priority applications are able to be supported within the applicant organisation. If an application has an extremely-high priority, submit as soon as possible and ensure that key people are able to support any queries or requests for additional information in line with the priority of the application.
Common issues: Altering the priority, submission dates or need dates for an application without keeping the Authority informed. This impacts the Authority’s ability to provide timely support for the application.
Risk Management Documentation
Applications and the supporting documentation must detail the full range of considerations or actions (e.g. information gathering, consultation, assessments, implementation of risk controls) taken as part of the risk management.
Good practice:
Documenting all credible risk controls that were considered, not simply those that were determined to be reasonably practicable. Often applications fail to provide full detail on controls that were considered, or why a control was considered not reasonably practicable. If these considerations are not documented, confidence that the seven-step risk management process was completed appropriately will not be possible from a desktop review.
Providing full reasoning for the risk characterisation.
Documenting all actions that will be undertaken to control the risk, even if they appear obvious, or are part of ‘standard practices’. An independent reviewer will not necessarily be familiar with local procedures for every Unit. As such, if there are standard activities that are undertaken within a Unit that are relevant to the application and managing the risk, this must be documented in the application to ensure that the application provides a credible and defensible basis for proceeding.
Documenting any Orders, Instructions and Publications (OIP) changes and/or training that must be implemented to support the operation under the MPTF (e.g. for an aircraft that is in a different configuration to the remainder of the fleet and needs to be operated differently).
Common issues:
Stating that a risk is ‘Medium’ before a control is implemented, and ‘Low’ after a control is implemented, without explaining how the control has impacted on the risk to result in a change to ‘Low’.
Stating that a risk is [X] level without providing the justification for that characterisation.
Stating a risk level that does not align with the justification or analysis provided.
Not identifying all the credible hazards related to the technical issues.
Risk Controls and Flight Conditions
Risk assessments must be complete before an application is submitted, and controls that have been assessed as reasonably practicable must be included in the proposed Flight Conditions.
Good practice:
Ensuring that all required assessments have been completed prior to finalising an application, so that the risk is understood and reasonably-practicable controls have been identified11.
The application should not suggest that an assessment or other activity will be done to identify controls at a later date. This must be done prior to applying for the Flight Conditions. If an assessment is not able to occur until just before the MPTF is required, the Authority can be engaged with drafts of the applications to enable an expedited turn-around after the final activities are complete.
Example. The Flight Conditions can require an activity (such as EMI/EMC testing or maintenance check flights) to be completed to confirm the validity of the risk assessment completed (i.e. to confirm that a hazard is not present), but these activities cannot be used to identify hazards or new risk controls. For example, ‘EMI/EMC testing must be completed to confirm nil interference’ is a valid control, however ‘EMI/EMC testing must be completed to identify impacted systems’ is not a valid control.
Ensuring that all reasonably-practicable controls have been implemented (or will be implemented prior to flight).
Common issues:
Stating that a control is reasonably practicable, but not implemented. If this is true, then the risk has not been eliminated or otherwise minimised SFARP, and the activity should not proceed.
Note: It may be possible for a control to be reasonably practicable in the future, but not reasonably practicable immediately. This must be made clear in the submission, including the justification for why it is not reasonably practicable immediately, the timeframe when it will become reasonably practicable, and how it will be tracked to ensure it is implemented once it is reasonably practicable.
Relying upon controls implemented through other documents (such as Flying Orders) without those other documents being controlled through the approved Flight Conditions22. The approval of Flight Conditions and MPTFs are Authority-issued authorisations, and they are issued on the basis of the controls that have been implemented. It is not possible to issue these authorisations on the basis of controls that are being managed separately to the authorisation (e.g. on the basis of a Flying Order which is being managed and updated separately to the approved Flight Conditions/MPTF). If controls change, new Flight Conditions and a new MPTF will be required.