{"title":"举办安全检讨委员会会议的技巧及经验教训","authors":"Robert Smith","doi":"10.56094/jss.v56i2.22","DOIUrl":null,"url":null,"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: \n \nWhat is going to be uncovered, or discovered? \nWill they be able to provide sufficient responses to address questions and concerns and defend our safety assessments? \nWill the Safety Review Board process delay the schedule? \nAre they going to miss a test event milestone? \nWill they make their Critical Design Review (CDR)? \nWill they meet their certification process? \nHow much is this going to cost? \nWhy do they need to provide all of this Objective Quality Evidence (OQE)? \n \nThis 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.","PeriodicalId":250838,"journal":{"name":"Journal of System Safety","volume":"135 1","pages":"0"},"PeriodicalIF":0.0000,"publicationDate":"2020-12-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":"0","resultStr":"{\"title\":\"Tips and Lessons Learned for Conducting Safety Review Board Meetings\",\"authors\":\"Robert Smith\",\"doi\":\"10.56094/jss.v56i2.22\",\"DOIUrl\":null,\"url\":null,\"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: \\n \\nWhat is going to be uncovered, or discovered? \\nWill they be able to provide sufficient responses to address questions and concerns and defend our safety assessments? \\nWill the Safety Review Board process delay the schedule? \\nAre they going to miss a test event milestone? \\nWill they make their Critical Design Review (CDR)? \\nWill they meet their certification process? \\nHow much is this going to cost? \\nWhy do they need to provide all of this Objective Quality Evidence (OQE)? \\n \\nThis 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.\",\"PeriodicalId\":250838,\"journal\":{\"name\":\"Journal of System Safety\",\"volume\":\"135 1\",\"pages\":\"0\"},\"PeriodicalIF\":0.0000,\"publicationDate\":\"2020-12-01\",\"publicationTypes\":\"Journal Article\",\"fieldsOfStudy\":null,\"isOpenAccess\":false,\"openAccessPdf\":\"\",\"citationCount\":\"0\",\"resultStr\":null,\"platform\":\"Semanticscholar\",\"paperid\":null,\"PeriodicalName\":\"Journal of System Safety\",\"FirstCategoryId\":\"1085\",\"ListUrlMain\":\"https://doi.org/10.56094/jss.v56i2.22\",\"RegionNum\":0,\"RegionCategory\":null,\"ArticlePicture\":[],\"TitleCN\":null,\"AbstractTextCN\":null,\"PMCID\":null,\"EPubDate\":\"\",\"PubModel\":\"\",\"JCR\":\"\",\"JCRName\":\"\",\"Score\":null,\"Total\":0}","platform":"Semanticscholar","paperid":null,"PeriodicalName":"Journal of System Safety","FirstCategoryId":"1085","ListUrlMain":"https://doi.org/10.56094/jss.v56i2.22","RegionNum":0,"RegionCategory":null,"ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":null,"EPubDate":"","PubModel":"","JCR":"","JCRName":"","Score":null,"Total":0}
Tips and Lessons Learned for Conducting Safety Review Board Meetings
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.