Tips and Lessons Learned for Conducting Safety Review Board Meetings

Abstract

At some point during a safety program’s lifecycle, presenting to an Independent Safety Review Board is likely. For the program representatives, including their safety lead, program manager, and supporting representatives (e.g., design engineers, software developers, test directors, etc.), this could be comparable to a full-scale audit on their program - and in some cases, it is! The fear that program representatives have with presenting to Safety Review Boards is the unknown. They may ask themselves:

• What is going to be uncovered, or discovered?
• Will they be able to provide sufficient responses to address questions and concerns and defend our safety assessments?
• Will the Safety Review Board process delay the schedule?
• Are they going to miss a test event milestone?
• Will they make their Critical Design Review (CDR)?
• Will they meet their certification process?
• How much is this going to cost?
• Why do they need to provide all of this Objective Quality Evidence (OQE)?

This paper provides tips and highlights what programs should do, and should not do, based on lessons learned to have successful Safety Review Board meetings. The end goal of any successful Safety Review Board meeting is to ensure the safety program processes and analytical artifacts are adequate and well-established to properly identify and assess safety risks for the personnel, equipment and environment that will be exposed to potential hazards during the system’s lifecycle.