The Lifelong Evolution of a Safety Case
Introduction

In The Lifelong Evolution of a Safety Case, we look at how to Review and revise a Safety Case and Re-Issue a Safety Case Report.

When it comes to ensuring safety throughout any Product, System, or Service lifecycle, reviewing and revising the Safety Case isn’t just a recommendation—it’s essential. The age or status of equipment isn’t simply about how old it is. Instead, it reflects an understanding of its condition, the effects of changes, and its performance in varying environments over time. Let’s dive into the key principles of maintaining and revising a Safety Case and the potential risks and strategies to avoid them.

Why Review the Safety Case?

Changes in operations, equipment condition, or organizational controls can disrupt the assumptions on which the original Safety Case was built. Recognizing when a review is needed ensures safety remains uncompromised.

Here are examples of scenarios that demand attention:

- Structural Modifications: Repairs or upgrades impacting safety.

- New Activities: Introduction of new tasks or uses for the equipment.

- Environmental Changes: Shifts in operational environments or equipment roles.

- Incident Data: Insights from accidents or maintenance inspections.

- System Evolution: Decommissioning, extended use, or technological upgrades.

Figure: Relationship between the Safety Management System and Safety Case in terms of Age and Status

Relationship between the Safety Management System and Safety Case

Challenging Assumptions: The Foundation of Safety

A Safety Case is never static—it evolves as evidence and conditions change. It’s vital to challenge existing arguments continually. If new evidence undermines the validity of the Safety Case, steps like obtaining further proof, implementing corrective actions, or, in extreme cases, halting operations may be necessary.

Consider this: what was deemed safe at one time might become risky due to wear, updates, or new findings. Regular reviews ensure the Safety Case remains robust and relevant.

Ownership and Administration: Who's in Charge?

The custodian of the Safety Case is the Project Safety Manager, the linchpin in ensuring safety throughout the lifecycle of the system. This individual must coordinate all safety activities, maintain the Safety Case, and oversee its interaction with the Safety Management System (SMS).

While contractors may handle the technical details, the responsibility for ensuring the integrity and adequacy of the Safety Case rests with the appointed safety delegation holder.

Records Matter: Documenting Safety

Every decision, from hazard mitigation to safety strategy adjustments, must be meticulously recorded. Key documents feeding into this process include:

- System Requirements Document: Detailing specific safety needs.

- Customer-Supplier Agreement: Outlining deliverables.

- Through-Life Management Plan: Ensuring continuity in safety oversight.

A central part of this process is the Hazard Log, which serves as the repository of all identified risks and their management status. (see Procedure SMP11 – Hazard Log).

Avoiding Pitfalls: The Warnings

The warnings and project risks identified in all the other procedures, from SMP01 to SMP11 can manifest themselves through effects on the Safety Case, as it brings their outputs together. Also, there are other project risks specific to the Safety Case.

Neglecting regular reviews or documentation can lead to significant issues, including:

- Delays in Safety Approvals: Failure to engage approval authorities early can result in unmet safety requirements and service delays.

- Outdated Safety Cases: A mismatch between documentation and the system’s current state undermines credibility.

- Inadequate Risk Analysis: Improper techniques during safety assessments may yield an incomplete Safety Case.

- Lost Records: Poor documentation management can erode trust in the safety process.

Completing the Circle: The Role of Collaboration

Maintaining a credible and effective Safety Case is a collective effort. Contractors, safety committees, and stakeholders must work in concert to identify and mitigate hazards. Sharing data, especially during transitions between contractors, is crucial to avoiding gaps in safety oversight.

Wrapping Up

The Safety Case is more than a set of documents—it’s a dynamic framework ensuring that safety risks are continuously managed throughout the lifecycle of a system. With proper reviews, updates, and collaboration, it provides confidence that safety remains a top priority, no matter the changes a system undergoes.

This blog article is Part 3 of a series. It follows on from Part 2.

Meet the Author of 'The Lifelong Evolution of a Safety Case'

Learn safety engineering with me, an industry professional with 25 years of experience, I have:

•Worked on aircraft, ships, submarines, ATMS, trains, and software;

•Tiny programs to some of the biggest (Eurofighter, Future Submarine);

•In the UK and Australia, on US and European programs;

•Taught safety to hundreds of people in the classroom, and thousands online;

•Presented on safety topics at several international conferences.
#HazardLogBestPractices #LifecycleSafetyCaseReview #MaintainingSystemSafety #OperationalRiskManagement #ProjectSafetyManagerRole #RiskAssessmentLifecycle #SafetyCaseDocumentationTips #SafetyCaseManagement #SafetyManagementSystemIntegration #SafetyOversightinProjects
Simon Di Nucci https://www.safetyartisan.com/?p=4149

The Lifelong Evolution of a Safety Case
Introduction

In The Lifelong Evolution of a Safety Case, we look at how to Review and revise a Safety Case and Re-Issue a Safety Case Report.

When it comes to ensuring safety throughout any Product, System, or Service lifecycle, reviewing and revising the Safety Case isn’t just a recommendation—it’s essential. The age or status of equipment isn’t simply about how old it is. Instead, it reflects an understanding of its condition, the effects of changes, and its performance in varying environments over time. Let’s dive into the key principles of maintaining and revising a Safety Case and the potential risks and strategies to avoid them.

Why Review the Safety Case?

Changes in operations, equipment condition, or organizational controls can disrupt the assumptions on which the original Safety Case was built. Recognizing when a review is needed ensures safety remains uncompromised.

Here are examples of scenarios that demand attention:

- Structural Modifications: Repairs or upgrades impacting safety.

- New Activities: Introduction of new tasks or uses for the equipment.

- Environmental Changes: Shifts in operational environments or equipment roles.

- Incident Data: Insights from accidents or maintenance inspections.

- System Evolution: Decommissioning, extended use, or technological upgrades.

Figure: Relationship between the Safety Management System and Safety Case in terms of Age and Status

Relationship between the Safety Management System and Safety Case

Challenging Assumptions: The Foundation of Safety

A Safety Case is never static—it evolves as evidence and conditions change. It’s vital to challenge existing arguments continually. If new evidence undermines the validity of the Safety Case, steps like obtaining further proof, implementing corrective actions, or, in extreme cases, halting operations may be necessary.

Consider this: what was deemed safe at one time might become risky due to wear, updates, or new findings. Regular reviews ensure the Safety Case remains robust and relevant.

Ownership and Administration: Who's in Charge?

The custodian of the Safety Case is the Project Safety Manager, the linchpin in ensuring safety throughout the lifecycle of the system. This individual must coordinate all safety activities, maintain the Safety Case, and oversee its interaction with the Safety Management System (SMS).

While contractors may handle the technical details, the responsibility for ensuring the integrity and adequacy of the Safety Case rests with the appointed safety delegation holder.

Records Matter: Documenting Safety

Every decision, from hazard mitigation to safety strategy adjustments, must be meticulously recorded. Key documents feeding into this process include:

- System Requirements Document: Detailing specific safety needs.

- Customer-Supplier Agreement: Outlining deliverables.

- Through-Life Management Plan: Ensuring continuity in safety oversight.

A central part of this process is the Hazard Log, which serves as the repository of all identified risks and their management status. (see Procedure SMP11 – Hazard Log).

Avoiding Pitfalls: The Warnings

The warnings and project risks identified in all the other procedures, from SMP01 to SMP11 can manifest themselves through effects on the Safety Case, as it brings their outputs together. Also, there are other project risks specific to the Safety Case.

Neglecting regular reviews or documentation can lead to significant issues, including:

- Delays in Safety Approvals: Failure to engage approval authorities early can result in unmet safety requirements and service delays.

- Outdated Safety Cases: A mismatch between documentation and the system’s current state undermines credibility.

- Inadequate Risk Analysis: Improper techniques during safety assessments may yield an incomplete Safety Case.

- Lost Records: Poor documentation management can erode trust in the safety process.

Completing the Circle: The Role of Collaboration

Maintaining a credible and effective Safety Case is a collective effort. Contractors, safety committees, and stakeholders must work in concert to identify and mitigate hazards. Sharing data, especially during transitions between contractors, is crucial to avoiding gaps in safety oversight.

Wrapping Up

The Safety Case is more than a set of documents—it’s a dynamic framework ensuring that safety risks are continuously managed throughout the lifecycle of a system. With proper reviews, updates, and collaboration, it provides confidence that safety remains a top priority, no matter the changes a system undergoes.

This blog article is Part 3 of a series. It follows on from Part 2.

Meet the Author of 'The Lifelong Evolution of a Safety Case'

Learn safety engineering with me, an industry professional with 25 years of experience, I have:

•Worked on aircraft, ships, submarines, ATMS, trains, and software;

•Tiny programs to some of the biggest (Eurofighter, Future Submarine);

•In the UK and Australia, on US and European programs;

•Taught safety to hundreds of people in the classroom, and thousands online;

•Presented on safety topics at several international conferences.
#HazardLogBestPractices #LifecycleSafetyCaseReview #MaintainingSystemSafety #OperationalRiskManagement #ProjectSafetyManagerRole #RiskAssessmentLifecycle #SafetyCaseDocumentationTips #SafetyCaseManagement #SafetyManagementSystemIntegration #SafetyOversightinProjects
Simon Di Nucci https://www.safetyartisan.com/?p=4149

Q&A: Reflections on a Career in Safety

Now we move on to Q&A: 'Reflections on a Career in Safety'.



Q&A Session | Q&A Session | Q&A Session | Q&A Session



How do you Keep People Engaged with Safety?



Q.           I was thinking of an idea as I was walking here, and you did mention just in your slide about going with the flow that sometimes people who stop listening to you I've seen a lot of people come up with safety systems where there's a lot of forms and paperwork to fill out. And a lot of the people who are doing it just go. It's just paperwork. It doesn't do anything for safety. It's somebody else covering their butt.



Whereas what when I look at them, what they are is almost a prompt to get people to think about the things that can bite them. Yeah. Keep that idea of what's in front of them in their heads rather than letting that go into the. Is just paperwork for paperwork’s sake. Yeah. How do you keep them engaged in using that as a tool rather than a liability reduction?



A.           Yeah, I think, first of all, there's got to be a bit of education. They've got to understand that they're dealing with things that are potentially dangerous. I mean, that's required anyway. You've got to warn users and them the information that they need. But I think mostly it's about how you engage with people. If you show if you sell it to them, there's a benefit to doing this. And you talk in a language that they understand you're much more likely to get listened to.



I've been to lots of places where people have had awful procedures that don't help them get the job done, it's slow and clunky and they often get ignored. So the trick is to try and make the procedures as helpful to get the job done as possible. And of course, if you can build in safety so people don't have to follow so many procedures, that's even better. If they physically can't do something dangerous, then that's great.



That's much more effective than procedures anyway. But it is all about speaking the user's language. So, I learned that with pilots, pilots have got a particular way of thinking and you can give them a rule that says don't do this, but it might not actually make any sense in that context. So you've got to understand what their context is. You can they can only follow a rule if it's based on information that's actually available to them.



So you can say, don't go below 10,000 feet while doing this or don't exceed the speed. Otherwise, the wings might fall off. That that they understand. If you gave them a load of technical garble about stuff, they probably wouldn't pay much attention.



That said, you do sometimes have to tell people the bleeding obvious because I remember a known British pilot took off in a plane where the fuel warnings were showing on the wing tanks, but the pilot still took the plane and then got in the air and no fuel was coming out of the wing. So he had to land the plane pretty quickly before it ran out of fuel. And I was going to bring in some advice to our pilots to say: don't do that. If you see the yellow stripes on the wings, that's a bad scene on the display. That's a bad sign. And somebody said to me, oh, no British pilot would be stupid enough to do that. And like a fool, I believed him.



So they did do that. And then right now we're having the rule that says, don't do that, because it was needed. So there's always a fine balance is a bit of give and take. Thanks for the questions. Yeah. Anyone else, anyone else?



Which Project was Most Influential on Your Life?



Q.           If you can share what's one of the projects that you worked on that was probably the most influential in your life or that you thought was definitely helpful for where you are now.



A.           That’s a really good question. Well, I suppose the big one in my life was Eurofighter because I spent 13 years, on and off, on Eurofighter and I got to work with some fantastic people; in theory, I was their manager. But in reality, they knew 100 times as much about the subject as I did and I learned a lot from them.



So, yeah, I would say because of that, the sheer number of people. But there were lots of jobs where I got a lot out of it professionally or personally … But yeah, I think it's the people, wherever you are.



I've seen a lot of teams. They've got terrible workplace conditions, work in an old dilapidated building. They haven't got enough spares. They haven't got enough tools or anything. Everything is against them. But if they're a good bunch of people, they'll still achieve great things and enjoy doing it.



How do you Make a Safety System Responsive?



Q.           OK. Oh, so you're talking about these very complicated systems where you permitted people to do work so really planned because they're so difficult. You've really planned how work has to happen. But the things that you're working on, stuff that theoretically most operations at the moment are small arms and things, but people can shoot holes in the things that you're working on. And if the 10,000 tanks come over, then you've got potentially a lot more holes all of a sudden.



How do you go from that very regimented system and then work out how to make it also really, really fast and responsive to something that keeps throwing up problems at a much higher rate than I'd imagine you can fill out the forms to give permission to the person to do the work as is the usual practice.



A.           So you're using the same system over and over and over again. And people will spend years using the same system, maybe on the same equipment or the same plane or whatever it is.



So people are well-practiced. Another technique is if people are overtrained and they got lots of experience, then they can often cope in adverse circumstances. So sometimes you just have to cut corners in order to get a job done. And it's having the experience and the knowledge to do that safely and still get the result you need that, that's the judgment side. That's the stuff that you can't write down. But mostly it's through practice.



So, we would follow a very regimented process. But once you've done it enough times, it became second nature.  It's like training an athlete. Once you've got the regular way of doing things down pat, it then becomes a lot easier to spot when you've got to do something a bit different and cope with it.



Q&A: How do you Determine Safety Requirements? How do you Detect Safety Issues in Software?



Q.           So I'll try and combine these because the time's getting on and I've got a lot of questions, you're talking about safety and software and safety being an emergent phenomenon, and you're not necessarily going to know that something you do in software is going to cause. An issue with the typhoon is very software-controlled aircraft, so the computer says is close to what's going to happen over the pilot in a lot of ways. You also talked about putting safety into requirements.



Some requirements may or may not like you could have a direct safety requirement, but there could be other requirements that can impact safety without it being explicit. Yeah, how do you detect that in a set of system or user requirements? And how do you detect safety issues in software systems that look like they're doing what they're supposed to do?



A.           Yeah, so do the requirements bit first.  Sometimes you get a bunch of requirements and you've just got to go through them and look for safety implications. Sometimes it's really obvious like the customer says, I want this safety system installed in my ship.  The ship has got to be built in accordance with certain rules, class rules, or whatever they might be. And you go, OK, a lot of that will be safety-related.



And sometimes you've got to do some work. You've got to decompose the requirements and look at how are you going to solve the problem and go, OK, the requirements are pushing us to have this high-energy system in my ship. OK, there are safety issues with managing that and making sure it doesn't get out of control. So sometimes it only emerges after you've done further work after you've kind of decomposed your initial requirements.



But if the people doing the requirements, you might have systems engineers on the client-side and on the provider side. If they're doing their job well, they’re processing the requirements. And these things will tend to emerge quite well. If you've got good systems engineering. So that's that one.



The software one, it all depends on how safe or how dependable you want the software to be.  Ultimately, the Eurofighter had a software-controlled flight control computer, and the aircraft in certain aspects was unstable. So the pilot could not fly it without the computer. So that's as tough as it gets in terms of software safety, the computer cannot fail. OK, and to achieve that level of safety, the state of the art at the time was going through the source code in forensic detail, nailing down the compiler so that it was only allowed to do very basic things.



And then you produce the object code and then you go through the object code in forensic detail and then test it to death. So lots and lots of processes applied and there were still errors in the software because there always will be because there are so many. But you can at least say none of these errors will result in an unsafe outcome, provided, of course, that you've got a sufficiently detailed specification to say this is safe and this is not OK.



So if you're if you've got to go to that level of detail, you can forensically go through things. And then there are if you've heard of Safety Integrity Levels (SILs) or safety integrity requirements for different cells or different says, you can have a cookbook approach where you use different techniques. Usually, the toughest SIL is the state of the art at the time that the standard was created. That's very crudely how you do it, and hopefully, you've got some competent people as well.



Host: Thank you. Thank you so much for sharing your time with us and explaining your journey through safety. Something that I think was interesting is that you raised it here. 



How do you Deal with People Using Stuff in Ways it Wasn't Designed for?



Q.           I understand people's motivation, the context of people's motivations for using the equipment. And people might use it in ways that you don't even dream of. Right, you might have designed something to do this or something. And then people stand on it to reach something else, that kind of thing, isn't it?  I think when you move from being at university and going into industry and seeing how the equipment is actually used, you can blow your mind sometimes. Yeah.



A.           Yeah. Even people who had worked in the Ministry of Defence , my boss was horrified at the idea that the Air Force would fly a plane that wasn't totally serviceable. And to me, that was completely routine.  None of them worked totally as intended. There were some features that we just disabled all the time.



Host.     So, yes, that is also something that blows your mind.  Oh, thank you very much, Simon. Thank you and thank you, kind audience. Thanks for your participation.



Q&A Session | Q&A Session | Q&A Session | Q&A Session



This was part of a lecture to the University of Adelaide SEIP Course. You can the other sessions, as follows:



- Part 1 https://www.safetyartisan.com/2021/06/30/reflections-on-a-career-in-safety-part-1/

- Part 2 https://www.safetyartisan.com/2021/07/07/reflections-on-a-career-in-safety-part-2/

- Part 3 https://www.safetyartisan.com/2021/07/14/reflections-on-a-career-in-safety-part-3/

- Part 4 https://www.safetyartisan.com/2021/07/21/reflections-on-a-career-in-safety-part-4/

- Part 5 https://www.safetyartisan.com/2021/07/28/reflections-on-a-career-in-safety-part-5/



So that was 'Reflections on a Career in Safety: Q&A'. Did you find it useful?

#howdoyoumakeasafetysystemresponsive #howtodeterminesafetyrequirements #issafetyagoodcareer #Q&A #questionsandanswers #whichprojectwasmostinfluentialinyourlife #whychoosesafetycareer

Simon Di Nucci https://www.safetyartisan.com/2021/08/04/reflections-on-a-career-in-safety-qa/

Reflections on a Career in Safety, Part 5

In 'Reflections on a Career in Safety, Part 5', I finally get around to reflecting on personal lessons learned from my own career.



Reflecting on a Career in Safety



Very briefly, I just wanted to pick out three things.



Learning and Practice



First, at university in my first degree and in my master's degree and in studies I've done since then (because you never stop learning) you pick up a theoretical framework, which is fantastic.  You learn to understand things from an abstract point of view or a theoretical point of view.



But there's also practical experience, and the two complement each other. You can a job. You're usually doing the same thing over and over again. So you become very competent in that narrow area. But if you don't have the theoretical framework to put it in, you've got all of these jewels of experience, but you can't understand where they fit in in the big picture.



Wilhelmshaven, Picture by S. Di Nucci



And so that's what your course here does. Whatever courses you do in the future, whatever learning you do in the future, the two complement each other, and actually they work together. Whether I turn up and I understand something from a theoretical point of view, or I've actually done it and learned the hard way (usually doing it the hard way is painful), the two are complementary and they're very useful to help you in your career.



Opportunism and Principles



Second, you've heard me say a couple of times I got into software by accident. I got into safety by accident. And it's all true. An opportunity comes up and you've got to grab it either because you think, well, maybe this opportunity won't come again or you're trying to get out of a job that you don't like or avoid doing something you don't want to do, whatever it might be.



If you have an opportunity, I would say grab it, go for it, be positive and say yes to as many things as you can. And, if I dare to give you some career advice, it would be that.



Photo by Aziz Acharki on Unsplash



But also, in safety, we've got to stick to our principles. And sometimes as a safety engineer or an engineer who does safety, you're going to have to stick to something that costs you, whether it be a promotion or, whether people no longer listen to you because you said, “no, we can't do that” when it's something that they really want to do.



You have to understand the difference between things that matter and things that don't. So if you end up in safety, if you're working with the safety of people, learn the things that cannot be negotiated.  There are certain requirements in the law and regulations, but they're often not as onerous as people think. They're often a lot simpler than people think. So understand: what has to be done and what is optional?  What is merely beneficial. And then you can make a sound judgment.



Simplicity



The final point. Einstein once famously said that if you can't explain something in simple terms, then you don't really understand it. And what you and I will all be doing for years to come is dealing with complexity, big projects, politics. A technical challenge, with not enough time to do something, not enough budget to do something. So lots of challenges.



I think it's always a struggle to reduce to something simple that you can understand and think: right, this is the essential point that we need to keep hold of. Everything else is kind of fluff and distraction.



So I would say my career in safety has been a constant effort to simplify and to understand the simple things that are important. And that's what we need to stick to. And again, all of you, whether you do safety or not, you're going to be dealing with complex systems. Otherwise, we're not needed as systems engineers.



'Decomposed' F1 Racing Car, Brooklands. Photo Simon Di Nucci.



Q&A (Part 6) will follow next week!



New to System Safety? Then start here. There’s more about The Safety Artisan here. Subscribe for free regular emails here.

#Careerinsafety #ishealthandsafetyagoodcareer #ishseagoodcareer #issafetyagoodcareer #issafetymanagementagoodcareer #Lecture #Part5 #reflections #safetycareer #safetyguideforcareerandtechnicaleducation #SystemsEngineering

Simon Di Nucci https://www.safetyartisan.com/2021/07/28/reflections-on-a-career-in-safety-part-5/

The 2024 Blog Digest - Q3/Q4
The 2024 Blog Digest - Q3/Q4 brings you all of The Safety Artisan's blog posts from the first six months of this year. I hope that you find this a useful resource!

The 2024 Blog Digest - Q1/Q2: 25 Posts!

The 2024 Blog Digest - Q3/Q4 is it for this year - thanks, everyone!

Meet the Author

Learn safety engineering with me, an industry professional with 25 years of experience, I have:

•Worked on aircraft, ships, submarines, ATMS, trains, and software;

•Tiny programs to some of the biggest (Eurofighter, Future Submarine);

•In the UK and Australia, on US and European programs;

•Taught safety to hundreds of people in the classroom, and thousands online;

•Presented on safety topics at several international conferences.
#coursesafetyengineering #ineedsafety #knowledgeofsafety #learnsafety #safetyblog #safetydo #safetyengineer #safetyengineertraining #safetyengineeringcourse #safetyprinciples
Simon Di Nucci https://www.safetyartisan.com/2024/12/26/the-2024-blog-digest-q3-q4/

The 2024 Blog Digest - Q3/Q4
The 2024 Blog Digest - Q3/Q4 brings you all of The Safety Artisan's blog posts from the first six months of this year. I hope that you find this a useful resource!

The 2024 Blog Digest - Q1/Q2: 25 Posts!

The 2024 Blog Digest - Q3/Q4 is it for this year - thanks, everyone!

Meet the Author

Learn safety engineering with me, an industry professional with 25 years of experience, I have:

•Worked on aircraft, ships, submarines, ATMS, trains, and software;

•Tiny programs to some of the biggest (Eurofighter, Future Submarine);

•In the UK and Australia, on US and European programs;

•Taught safety to hundreds of people in the classroom, and thousands online;

•Presented on safety topics at several international conferences.
#coursesafetyengineering #ineedsafety #knowledgeofsafety #learnsafety #safetyblog #safetydo #safetyengineer #safetyengineertraining #safetyengineeringcourse #safetyprinciples
Simon Di Nucci https://www.safetyartisan.com/2024/12/26/the-2024-blog-digest-q3-q4/

Reflections on a Career in Safety, Part 4

In 'Reflections on a Career in Safety, Part 4', I want to talk about Consultancy, which is mostly what I've been doing for the last 20 years!



Consultancy



As I said near the beginning, I thought that in the software supportability team, we all wore the same uniform as our customers. We didn't cost them anything. We were free. We could turn up and do a job. You would think that would be an easy sell, wouldn't you?



Not a bit of it.  People want there to be an exchange of tokens. If we're talking about psychology, if something doesn't cost them anything, they think, well, it can't be worth anything. So we pay for something really does affect our perception of whether it's any good.



Photo by Cytonn Photography on Unsplash



So I had to go and learn a lot of sales and marketing type stuff in order to sell the benefits of bringing us in, because, of course, there was always an overhead of bringing new people into a program, particularly if they were going to start asking awkward questions, like how are we going to support this in service? How are we going to fix this? How is this going to work?



So I had to learn a whole new language and a whole new way of doing business and going out to customers and saying, we can help you, we can help you get a better result. Let's do this. So that was something new to learn. We certainly didn't talk about that at university.  Maybe you do more business focussed stuff these days. You can go and do a module, I don't know, in management or whatever; very, very useful stuff, actually. It's always good to be able to articulate the benefits of doing something because you've got to convince people to pay for it and make room for it.



Doing Too Little, or Too Much



And in safety, I’ve got two jobs.



First of all, I suppose it's the obvious one. Sometimes you go and see a client, they're not aware of what the law says they're supposed to do or they're not aware that there's a standard or a regulation that says they've got to do something – so they're not doing it. Maybe I go along and say, ah, look, you've got to do this. It's the law. This is what we need to do.



Photo by Quino Al on Unsplash



Then, there's a negotiation because the customer says, oh, you consultants, you're just making up work so you can make more money. So you've got to be able to show people that there's a benefit, even if it's only not going to jail. There's got to be a benefit. So you help the clients to do more in order to achieve success.



You Need to Do Less!



But actually, I spend just as much time advising clients to do less, because I see lots of clients doing things that appear good and sensible. Yes, they're done with all the right motivation. But you look at what they're doing and you say, well, this you're spending all this money and time, but it's not actually making a difference to the safety of the product or the process or whatever it is.



You're chucking money away really, for very little or no effect.  Sometimes people are doing work that actually obscures safety. They dive into all this detail and go, well, actually, you've created all this data that's got to be managed and that's actually distracting you from this thing over here, which is the thing that's really going to hurt people.



So, I spend my time helping people to focus on what's important and dump the comfort blanket, OK, because lots of times people are doing stuff because they've always done it that way, or it feels comforting to do something. And it's really quite threatening to them to say, well, actually, you think you're doing yourself a favor here, but it doesn't actually work. And that's quite a tough sell as well, getting people to do less.



Photo by Prateek Katyal on Unsplash



However, sometimes less is definitely more in terms of getting results.



Part 5 will follow next week!



New to System Safety? Then start here. There’s more about The Safety Artisan here. Subscribe for free regular emails here.

#Careerinsafety #ishealthandsafetyagoodcareer #ishseagoodcareer #issafetyagoodcareer #issafetymanagementagoodcareer #Lecture #Part4 #reflections #safetycareer #safetyguideforcareerandtechnicaleducation

Simon Di Nucci https://www.safetyartisan.com/2021/07/21/reflections-on-a-career-in-safety-part-4/