For critical safety-of-flight nonconformances, root cause analysis should be cross-functional from the start. Quality typically facilitates, but quality alone is not enough. At minimum, you usually need the people who understand the requirement, the process that produced the condition, the evidence trail, and the authority to contain risk and approve corrective action.
Core participants
In most regulated aerospace and similar environments, the core RCA team should include these roles:
- Quality engineering or quality management: owns the NCR workflow, evidence discipline, containment tracking, and linkage to CAPA or equivalent corrective action processes.
- Responsible design or product engineering: confirms the requirement, characteristic criticality, functional impact, and whether the issue is design interpretation, tolerance stack-up, process capability, or execution failure.
- Manufacturing or process engineering: analyzes routing, work instructions, tooling, fixtures, machine parameters, process controls, and recent changes.
- Production supervision and the operator or inspector closest to the event: provides factual sequence-of-events detail that is often missing from formal records. Excluding frontline knowledge is a common RCA failure mode.
- MRB authority or equivalent disposition authority: separates immediate disposition decisions from long-term corrective action and keeps the investigation grounded in product risk.
- Program or business leadership for major events: ensures resourcing, customer communication paths, schedule impact management, and escalation discipline where the issue affects delivered or deliverable hardware.
Roles that are often required depending on the case
Critical safety-of-flight events usually pull in additional functions. Whether they are mandatory depends on your product, customer contract, internal procedures, and where the failure originated.
- Supplier quality and supplier engineering if the nonconformance originated in purchased material, special processing, calibration services, or outside processing. If the supplier owns part of the cause chain, they need to participate directly, not just receive a corrective action request.
- Special process engineering for heat treat, coating, bonding, welding, NDT, plating, composites, sterilization, or other tightly controlled processes where certification and parameter history matter.
- Metrology, test, or labs when measurement method, fixture bias, software revision, environmental conditions, or test setup may have contributed. Many RCAs go wrong because they assume the detection method is valid without checking MSA, calibration status, or setup repeatability.
- Configuration management or document control if there is any chance the event is tied to drawing revision mismatch, obsolete work instructions, uncontrolled local copies, or incorrect model-based definition release.
- Maintenance, controls, or equipment engineering if machine condition, preventive maintenance gaps, alarms, overrides, sensor drift, or PLC or HMI changes may be involved.
- PLM, MES, ERP, or QMS system owners when the event may involve bad master data, routing mismatch, serialization gaps, missing as-built records, or interface failures between systems. In brownfield plants, these are common contributors and often missed.
- Training or competency owners when qualification, certification, or recency of training is in question.
- Materials, planning, or receiving quality where lot mix, substitution, shelf-life, handling, storage, or traceability breaks may be causal.
Who should lead?
Usually, quality leads the investigation process, but the technical lead should match the dominant cause path. If the likely cause is process control, manufacturing engineering may drive the technical analysis. If the likely cause is requirement interpretation or design intent, engineering may need to lead that portion. What matters is that one role owns coordination and evidence control, while technical ownership sits with the people competent to test the actual failure theory.
That distinction matters. A lot of weak RCAs are really documentation exercises run by whoever owns the form.
Who should not be left out
Three omissions are especially risky for safety-of-flight cases:
- The person who knows the real shop-floor sequence. Formal travelers and system timestamps rarely capture workarounds, interruptions, re-clamping, tool swaps, or local decisions.
- The requirement owner. Teams sometimes investigate process variation before confirming the requirement, characteristic classification, and functional effect.
- The system or data owner when records conflict. If MES, ERP, PLM, QMS, calibration, and maintenance data do not agree, the RCA can be built on the wrong chronology.
Boundaries and controls for critical cases
For critical safety-of-flight nonconformances, the RCA team is only one part of the response. You also typically need explicit controls around containment, segregation, traceability review, shipped product impact assessment, and change control for any corrective action. If the proposed fix touches validated workflows, qualified equipment, approved process parameters, or controlled documentation, implementation will usually require formal review and may take longer than the urgency of the event would suggest.
That is normal in regulated environments. Fast action without controlled evidence and change discipline often creates a second problem.
Practical rule
If a role can answer one of these questions, it probably belongs in the RCA:
- What requirement was actually violated?
- How could the process physically create this condition?
- Can the detection method itself be trusted?
- What else, by serial, lot, process window, or supplier batch, may be affected?
- What system, document, or equipment changes happened near the event?
- Who has authority to contain risk and approve the corrective path?
For most critical safety-of-flight events, that means a small core team plus targeted subject-matter experts, not a giant meeting. Too few roles misses causes. Too many turns RCA into a status review.
