SMS INSIGHTS Part 1: Is "MOC Fatigue" draining your team?
📊 SMS INSIGHTS
Practical Safety Intelligence
Part 1: When to Trigger an MoC (And When Not To)
Ask any aviation safety manager about their biggest administrative headache, and you are likely to hear the same answer: "MOC Fatigue."
In many flight departments, the Management of Change (MoC) process has evolved from a targeted safety tool into a default project management system. Safety teams find themselves buried under mountains of documentation for every minor checklist tweak, routine software update, or office relocation. This over-application of the MoC process doesn't make an operator safer; instead, it dilutes safety department resources, creates administrative backlog, and turns a critical risk-mitigation framework into a paper-pushing exercise.
The key to a highly functional Safety Management System (SMS) is knowing how to strictly adhere to your manual's explicit triggers without adding unnecessary paperwork. In this first part of our four-part series on change management, we establish the foundation by exploring exactly when a change requires a formal MoC—and more importantly, when it does not.
📌 The Core Principle: MoC is Not a Project Management Tool
To understand when to bypass the MoC workflow, you must first understand what it is designed to do—and what it is not.
Key Definition: Management of Change is a formal Safety Risk Management (SRM) process used to manage significant changes within an organization, ensuring that changes which may impact identified hazards and risk mitigation strategies are accounted for, before the implementation of such changes. |
An effective manual system should warn against confusing change management with a general project management tool. Rather, change management is used specifically to identify and manage hazards associated with the project or change.
If your organization is implementing a new software system to track passenger catering or upgrading an accounting platform, you are managing a business project. Unless that project directly interfaces with flight safety, airworthiness, or introduces physical operational hazards, it does not belong in your SMS change management queue.
🚀 When You MUST Trigger an MoC (The Four Regulatory Triggers)
Under 14 CFR Part 5 § 5.51 and standard international safety frameworks (like IS-BAO § 3.3.2), Safety Risk Management must be applied anytime an operator meets one of the four regulatory SRM triggers:
1️⃣ Implementation of new systems.
2️⃣ Revision of existing systems.
3️⃣ Development of operational procedures.
For complex, multi-faceted changes, your safety documentation should guide managers to use a centralized Project or Change object within your SMS software to group and track multiple related safety issues.
An operator should formally initiate a corporate MoC process under any of the following explicit conditions:
🔶 Introducing New Technology, Equipment, or Facilities: Adding a new aircraft model to the operating certificate, constructing a new hangar, or introducing significant new operational capabilities (such as Controller-Pilot Data Link Communications (CPDLC) or international oceanic operations).
🔶 Significant Restructuring of the Organization: Organizational expansion or contraction, major shifts in staffing levels, or changes in multiple key management positions (such as a concurrent change of the Chief Pilot and Director of Operations).
🔶 Significant Changes in the Operating Environment: Expanding operations into entirely new geographic regions, commencing high-risk operations (such as night operations in mountainous terrain), or reacting to major regulatory changes from the civil aviation authority.
🔶 Changes in SMS Interfaces: Modifying how your operational processes interact with external organizations, such as outsourcing substantial maintenance functions to a new Approved Maintenance Organization (AMO).
🛡️ When NOT to Trigger an MoC (The Art of Leaving Your Manual Alone)
The secret to avoiding "MOC Fatigue" is utilizing the built-in bypasses and scaling options that should be defined within any mature SMS manual system. There are four distinct scenarios where a formal, complex MoC is not required:
🔹 1. Standard Formatting and Administrative Edits
A common misconception is that any manual revision requires a full MoC and SRM process. Your manual system should maintain a clear distinction: typos, sentence case changes, repagination, or standard cell fills should not be considered "contextual changes" unless they have an appreciable impact on the item’s actual content. Standard formatting items do not represent a change to system design and require zero SRM or MoC intervention.
🔹 2. The "No Hazards Identified" Fast Track
Even when a change technically touches an operational system—such as standard personnel turnover or updating an organizational chart due to a single promotion—you should not have to execute a full, multi-week risk assessment. Your safety procedures should allow for a rapid initial system description and hazard screening. If no hazards are identified by the change, the process is complete. Within your SMS tracking software, the manager should simply be able to check a "No hazards identified" box, which instantly transitions the record to "Ready to close," bypassing the investigation, corrective action planning, and follow-up stages entirely.
🔹 3. Non-Safety-Critical Adjustments (Lesser Hazards)
What if a change does introduce a minor hazard, but it has absolutely no bearing on flight safety or airworthiness? A well-designed SMS focuses formal, strategic SRM—which mandates a system analysis, standard risk matrix calculation, and residual risk evaluation—only on hazards that could foreseeably cause or contribute to an aircraft incident or accident. For lesser, non-aviation safety concerns (such as minor ground-handling inefficiencies, administrative errors, or occupational health issues that exclude aircraft damage), a formal strategic SRM is not required. These can be managed swiftly with a simple corrective action or localized task assigned directly to the process owner.
🔹 4. Scaling Down: Safety Issues vs. Change Projects
For minor changes—such as slightly modifying an operational checklist or tweaking a localized procedure—do not over-complicate your safety database by creating a multi-department "Project / Change" object. Your manual should establish that minor changes may be managed entirely within a single safety issue. This keeps the system description, hazard identification, and risk assessment contained in one clean, localized record, preventing other departments from being dragged into unnecessary review loops.
The Change Management Decision Tree
👉 STEP 1: Check formatting first
Is it a change to standard formatting, manual typos, or administrative text? ➔ [YES] Do not trigger MoC. Publish the update directly. ➔ [NO] Proceed to Step 2.
· · · · · · · · · · · · · · · · · · · · · · · · ·
👉 STEP 2: Assess accident potential
Does the change lack any foreseeable potential to cause or contribute to an aircraft accident? ➔ [YES] Do not trigger formal Strategic SRM. Manage via a localized corrective action or a simple safety report. ➔ [NO] Proceed to Step 3.
· · · · · · · · · · · · · · · · · · · · · · · · ·
👉 STEP 3: Screen for immediate hazards
Is it a routine system update (e.g., standard personnel promotion) that yields zero hazards upon a quick initial screening? ➔ [YES] Describe -> Screen -> Bypass. Log the system change, document "No hazards identified" in your tracking system, and close the file. ➔ [NO] Proceed to Step 4.
· · · · · · · · · · · · · · · · · · · · · · · · ·
👉 STEP 4: Gauge the scope of change
Is it a minor procedural modification affecting only one department? ➔ [YES] Scale down. Manage it inside a single Safety Issue, not a complex Project object. ➔ [NO] Proceed to Step 5.
· · · · · · · · · · · · · · · · · · · · · · · · ·
👉 STEP 5: Complex / Multi-department shifts
Is it a major, multi-faceted operational, organizational, or environmental shift that directly impacts flight safety or airworthiness? ➔ [YES] Trigger MoC. Initiate a formal Strategic SRM using the Project / Change object to systematically protect your operational margins.
· · · · · · · · · · · · · · · · · · · · · · · · ·
Takeaway: A mature safety culture is not measured by the sheer volume of paperwork it generates, but by the precision with which it targets real operational risk. By strictly adhering to your manual's explicit triggers and utilizing fast-track bypasses, you protect your safety team from administrative exhaustion and ensure that when a critical change does occur, it receives the undivided, rigorous focus it deserves. |
🎧 Up Next in our SMS INSIGHTS series: Part 2: How to Write a Bulletproof System Description for a Change.
If you would like to see the SMS AI Agent tools we developed in action, Schedule a 15-Minute Custom Demo.
Doug Spanier
Founder, AI SMS Expert
954-646-8554
Custom AI Solutions for Part 91 and Part 135 Operators
Just in case: If you need a robust SMS software solution, we recommend OmniSMS https://omnisms.aero/
Comments