In our last article we began looking at the high-level strategies for selecting mitigations, or risk controls, to reduce the risks associated with aviation safety hazards. This month we will examine how to record Safety Management System (SMS) data in a hazard log, as well as one of the less-obvious benefits of an effective SMS: the potential to use the safety risk management records to support effective change management.
Aviation Maintenance Magazine has been publishing a series of articles explaining how to establish and use a safety risk management (SRM) system to identify aviation safety hazards and assess the associated risk. SRM is one of the four key components of a complete Safety Management System (SMS). This (seventh) article assumes that you have some familiarity with the basic concepts of SMS that were covered in those first six articles. If you do not, then we recommend that you go back and read the past six articles (you can find all six at www.avm-mag.com).
In the past articles on SMS, we have discussed how to identify a hazard, how to assign values to the hazard correlating to likelihood of harm and consequence of such harm, how to assess the total risk posed by the hazard, and how to mitigate the risk. These are all part of the SRM component of an SMS. A robust SRM allows the user to assess the risks associated with hazards, and rank those risks, with the aim to focus limited resources on the hazards that pose the greatest risk, first. Once the hazards with the highest levels risks have been mitigated, then resources can be devoted to those with lower-level risks. This approach permits a risk-based approach to the development of a safety system, but it also encourages continuous evolution of the system that is used to manage safety.
SMS does more than merely help allocate limited resources. It also helps to document safety decisions, and it offers an opportunity to use those records to support elements of your safety system, including effective change management.
Recording the Results of Your SRM
One of the basic elements of SMS is documentation, and thus the system should document each of the four components of SMS, including SRM. The SRM documentation can be divided into two sets of records: (a) the records that describe the SRM processes, like the SMS manual, and (b) the records that are created as outputs of the SRM, like a hazard log. Note that this does not include the myriad records that are part of other systems, which nonetheless may be analyzed in the context of the SRM processes (like your existing component maintenance manuals used to support repair processes).
The hazard log is simply a compilation of the hazards that have been identified through the SMS, and the records concerning the way that each hazard was processed, including risk assessment data, identified/implemented mitigations, and the actual results of those mitigations.
I have a list of about 20 categories of fields that I recommend for capturing information in a complete hazard log. I don’t have enough space in this column to provide a full analysis of all fields, but a list of my preferred starting fields is being published as part of the scalability appendix in the next update to the SM-0001 Standard (expected late 2021). Pull up that standard if you want to see what I recommend. So I will just identify a few key fields that ought to be in your hazard log.
First you should identify the hazard and the details associated with it (this reflects multiple fields). Details can include information like scope: for example, if this hazard is only analyzed in a particular context, then that context should be identified. A missed-inspection hazard that arises in one repair, and also appears to arise in another repair, might have different consequences in each repair and therefore the hazards should be assessed as two different hazards, each with a different scope, because each has a different consequence.
As another example, proper calibration for ovens used to relieve hydrogen embrittlement is far more important than proper calibration for ovens in the break room (and the risk assessment for each will be different).
After identifying the hazard, you should record the risk assessment results. This typically means recording the likelihood, consequence/severity, and total risk (at a minimum). I typically like to record the risk assessment as it exists in at least four states:
• Risk assessment with no mitigations [as if there was no quality system at all – most existing businesses will already have some risk process controls in place before the SMS is created – such a processes required by the regulations – and it is important to recognize that those processes already mitigate risk and without them the risk would be worse];
• Risk assessment with current (existing) mitigations [recognizing that there may be risk controls — or mitigations — already in place in an existing system; if the risks shown between first and second assessment are the same then this might be an indication that the current mitigations are not having any appreciable affect, or it might suggest that your risk assessment categories are too broad to capture differences in risk level];
• Risk assessment with proposed (new) mitigations [before implementation, to identify anticipated results; once again, if the risk assessment shows that the risk level is the same in the second and third assessments, then this could suggest that either the mitigation is inadequate, or the risk-measurement-scale is insufficiently precise];
• Risk assessment with new mitigations [following implementation, to identify actual results and compare them to anticipated results; if the achieved risk level does not match the anticipated risk level, then this could be a signal that the mitigation is inadequate or improperly implemented; note that the goal is typically to reduce the risk to an acceptable level, so there remains the possibility of residual risk].
Each of these risk assessments would be compared to the business’ safety goals to determine when the risks of the associated hazard are satisfactorily mitigated. Obviously, the risk assessments may be performed (and recorded) at different times to reflect the process flow of the business’ SMS.
The mitigations should be listed in the hazard log as well. I like to recommend that the hazard log be established as a relational database. This allows one hazard to have more than one mitigation (recognizing that this is often the case in modern real-world quality systems) but it also allows a single mitigation to address more than one hazard. For example, a decision to purchase an alternative PMA part to support a particular repair might have been intended to mitigate the hazard of short supply from the original source, but if the PMA part also incorporates modifications designed to improve reliability, then it might also be claimed as a mitigation to a reliability hazard identified in the next higher assembly. In such a case the mitigation might reasonably be associated with both hazards. The importance of this arrangement in the hazard log will become clearer as we discuss the Change Management topic, below.
SRM and Change Management
I’ve spoken to many quality professionals who find the relationship between SMS and change management to be confusing. One of the reasons that this is confusing is because at the beginning of the SMS program, before a hazard log has been established, there appears to be no difference between a change management analysis and a typical SRM analysis. In each case you are identifying hazards and then analyzing them. This is frustrating to professionals who are seeking a systems-based approach to change management.
Simply applying SRM to the change generates multiple potential dangers within the system — there is a danger that the analysis will fail to predict a hazard associated with the proposed change. There is also a danger that the proposed change will lead to unintended consequences by impacting a mitigation that is associated with an unrelated hazard.
Luckily, a robust SMS can help to mitigate these two dangers; because as the hazard log is populated with data, it will become an important change management tool.
Remember that we are recording hazards, and their details, in the hazard log. If you are following my advice, then each hazard that needed to be mitigated is linked to one or more mitigations in the hazard log (e.g. through a relational database link). These are the mitigations that successfully reduce the risk to an acceptable level. If you look back at the recent article on risk mitigation selection strategies (https://www.avm-mag.com/sms-part-6-strategies-for-identifying-and-selecting-risk-controls/), you’ll see that there are multiple types of risk process controls and multiple strategies for implementing those risk process controls. These can range from written procedures, to training, to system design that drives safe behaviors. In each case, if you catalog those risk mitigations in your hazard log and link each one with the hazard(s) that it mitigates, then this will allow you to examine whether a change will impact risk mitigations (for example, a manual change that modifies the language of a procedure) and then you can identify the linked hazards. You can also examine how the mitigation affects those hazards. This permits you to begin your change management process by relying on analysis that has already been performed within the SMS. If you will change a risk mitigation, then examination of its connections in the hazard log allows you to identify the most likely consequences of that change (including the identification of unintended consequences).
This doesn’t take the place of a process that independently identifies likely hazards and performs safety assessment on each one, but it does provide a starting point, so that previously accomplished analysis can be reused, and so that known hazards can be assessed in the context of the change using the existing system information as a guide.
As the hazard log becomes increasingly more mature, it will capture the collected analyses of the past in a way that can directly support a systems-based approach to change management, allowing the safety department to identify likely consequences, and to develop new mitigations to ensure that previously identified hazards continue to be properly mitigated, particularly after a change.
Want to learn more? We have been teaching classes on SMS elements, and we have advised aviation companies in multiple sectors on the development of SMS processes and systems. Contact us if we can help you with your SMS questions.