Re: [SystemSafety] words you cannot use at GM

From: Matthew Squair < >
Date: Thu, 22 May 2014 06:42:23 +1000


I once was setting up a service bulletin system in a technology company (they were a fairly new company, only been going for a hundred years or so) and inadvertently sparked off a battle with the companies commercial/legal folk, who were very concerned about how issuing a service bulletin with 'safety alert' mentioned in it could be seen as admitting liability.

In the end we booted the issue over commercials heads and got the go ahead, with the proviso that the bulletins had to route through commercial for a language check. Which they faithfully did, for about a month. :)

Matthew Squair

MIEAust, CPEng
Mob: +61 488770655
Email; Mattsquair_at_xxxxxx
Web: http://criticaluncertainties.com

On 22 May 2014, at 2:24 am, Andrew Rae <andrew.rae_at_xxxxxx

Felix,

I confess I was being flippant in my previous post. Language does shape perception, and the way hazards and assurance deficits get discussed does matter.
There is no way that an environment that refuses to openly discuss risk is not going to harm perception and management of that risk. This is most serious when we have a
responsibility to communicate that risk to others, if language prevents us doing so.

I wasn't suggesting even flippantly that we should just do what we are paid to do though, but rather doing what we need to do to make things safe, using the language we are paid to use.
I do agree that there are times when even the language itself is problematic, but I think there are other times when its easy for academics to ignore industrial reality.

In the US there is certainly an industry perception (questionable just how real it is, but that's a side issue) that the use of certain language about risk increases legal liability.

Having a losing battle with company management about what language to use doesn't promote either the understanding or the management of risk.

Thanks for pulling me up. I was, after all, using questionable language to discuss risk :-).

Drew

My system safety podcast: http://disastercast.co.uk My phone number: +44 (0) 7783 446 814
University of York disclaimer:
http://www.york.ac.uk/docs/disclaimer/email.htm

On 21 May 2014 17:11, nfr <felix.redmill_at_xxxxxx

> Drew,
>
> Taking your advice - and doing what we are told to do by those who pay
> us - is certainly easier than struggling with moral conflicts in the belief
> that we have professional responsibilities and individual obligations,
> which include not knowingly writing lies onto legal (or any) documents. But
> I wonder if not lying to ourselves is sufficient sop to the consciences of
> everyone. And if our external lies created victims, would our saying, "They
> told me to do this," exonerate us from all blame? If no, is there another
> route that we could take?
>
> Felix.
>
>
> On 21 May 2014, at 10:52, Andrew Rae wrote:
>
> This isn't just a USA thing. Customers and companies do it to
> themselves all the time.
>
> Simple example: Insisting that every hazard must be marked "closed"
> before a contract can be completed. "Closed" never actually means closed,
> just
> that the next action to be taken on the hazard is beyond the
> scope/timeframe of the currently contracted task. Of course, after
> insisting that the word is used, the document then gets passed to someone
> who speaks English instead of hazard log legalese, and and thinks that
> nothing further has to be done.
>
> The best thing you can do in all these cases is "If the customer/lawyer
> insists that you use silly wording, do what they pay you to do. Just don't
> ever lie to you yourself about what the underlying reality is." If you're
> in the US and you can't use the term "acceptably safe", then every time you
> say safe you need to do an internal translation "and by safe I mean that I
> know that there is remaining risk, but I have considered that it is
> acceptable".
>
> No suggestions how you deal with that pesky ethical requirement to
> accurately communicate information about risk.
>
> My system safety podcast: http://disastercast.co.uk
> My phone number: +44 (0) 7783 446 814
> University of York disclaimer:
> http://www.york.ac.uk/docs/disclaimer/email.htm
>
>
> On 21 May 2014 10:23, Dewi Daniels <ddaniels_at_xxxxxx >
>> I thought it was infinitely recursive. One slide states that, instead
>> of Safety, use Has Potential Safety Implications. That suggests:
>>
>>
>>
>> Safety -> Has Potential Safety Implications -> Has Potential Has
>> Potential Safety Implications Implications -> Has Potential Has Potential
>> Has Potential Safety Implications Implications Implications -> Has
>> Potential Has Potential Has Potential Has Potential Safety Implications
>> Implications Implications Implications -> ad infinitum
>>
>>
>>
>> Yours,
>>
>>
>>
>> Dewi Daniels | Managing Director | Verocel Limited
>>
>> Direct Dial +44 1225 718912 | Mobile +44 7968 837742 | Email
>> ddaniels_at_xxxxxx >>
>>
>>
>> Verocel Limited is a company registered in England and Wales. Company
>> number: 7407595. Registered office: Grangeside Business Support Centre, 129
>> Devizes Road, Hilperton, Trowbridge, United Kingdom BA14 7SZ
>>
>>
>>
>> *From:* systemsafety-bounces_at_xxxxxx >> systemsafety-bounces_at_xxxxxx >> Hills
>> *Sent:* 21 May 2014 10:16
>> *To:* 'Bielefield Safety List'
>> *Subject:* Re: [SystemSafety] words you cannot use at GM
>>
>>
>>
>> RE ‘has potential safety implications’
>>
>>
>>
>> You can’t use “safety”
>>
>>
>>
>> So ‘has potential implications’…..
>>
>>
>>
>> Sorry not had my coffee yet J
>>
>>
>>
>>
>>
>>
>>
>> *From:* systemsafety-bounces_at_xxxxxx >> mailto:systemsafety-bounces_at_xxxxxx >> *On Behalf Of *Maier, Thomas
>> *Sent:* 21 May 2014 09:55
>> *To:* nfr; Bielefield Safety List
>> *Subject:* Re: [SystemSafety] words you cannot use at GM
>>
>>
>>
>> Reference to the GM-list only was made. Don’t know the paper you are
>> referring to, in particular how the term “safety” was employed by it.
>>
>> GM provides the following guidance, or whatever you want to call it:
>> “instead of ‘safety’, use ‘has potential safety implications”. So, is
>> “safety” forbidden or not?
>>
>>
>>
>> Med venlig hilsen / Best regards / Mit freundlichen Grüßen
>>
>>
>>
>> Thomas Maier
>>
>> E: Thomas.Maier_at_xxxxxx >>
>> T: +45 42 13 74 52
>>
>>
>>
>> *Fra:* systemsafety-bounces_at_xxxxxx >> mailto:systemsafety-bounces_at_xxxxxx >> *På vegne af *nfr
>> *Sendt:* 21. maj 2014 10:38
>> *Til:* Bielefield Safety List
>> *Emne:* Re: [SystemSafety] words you cannot use at GM
>>
>>
>>
>> "Safety" is not forbidden?
>>
>>
>>
>> Some years ago, when I edited papers for the annual System Safety
>> Symposium (in England), I received a call, rather close to the delivery
>> deadline, from an author in a US-based automotive company.
>>
>> "We've got a problem," he said. "The company reviewers have told me that
>> I have to remove every mention of the word 'safety'. What can we do?"
>>
>> I suggested replacing "safety" with "risk" and adjusting the wording
>> accordingly.
>>
>> "I've tried that," he replied, "but I'm not allowed to use the word
>> 'risk' either."
>>
>> It was too late for me to commission a replacement paper, and our
>> "solution" was to employ the word "reliability", which was not what the
>> paper was about.
>>
>>
>>
>> Felix.
>>
>>
>>
>>
>>
>> On 21 May 2014, at 09:14, Maier, Thomas wrote:
>>
>>
>>
>> A correction regarding IEC 615011:
>>
>> That minimum failure rate per IEC 61511 is specified in Part 1 clause
>> 8.2.2: “The dangerous failure rate of a BPCS (which does not conform to IEC
>> 61511) that places a demand on a protection layer shall not be assumed to
>> be better than *10-5 per hour*.”
>>
>>
>>
>> A question regarding legal damages by non-zero risk statements:
>>
>> The US National Electrical Code for machinery (standard NFPA 79)
>> normatively requires: “Where failures or disturbances in the electrical
>> equipment cause a hazardous condition or damage to the machine or the work
>> in progress, measures shall be taken to *minimize the probability of the
>> occurrence* of such failures or disturbances.” It informatively refers
>> to IEC 61508, IEC 62061, ISO 13849 in this context, i.e. to standards which
>> are based on probabilistic quantification of risk.
>>
>> How much legal protection do you actually get as a manufacturer in a
>> liability law suit under US jurisdiction by showing compliance to NFPA 79?
>>
>> And in the automotive domain: How about ISO 26262, which also allows
>> quantitative arguments in the safety case for programmable electronic
>> controls on board road vehicles, and which has been written and is
>> supported by the global automotive industry as state-of-science-and-art?
>>
>>
>>
>> A comment regarding the qualification as “Orwellian” of the 69 words (by
>> the way I was only aware of the “Milwaukee 7” so far, should these be
>> called the “Detroit 69”? …J):
>>
>> Even though the list looks a bit funny to me, I think this is the kind of
>> language regulation you generally want for technical / scientific writing.
>> I cannot see any corporate agenda of truth-hiding or any other evil
>> intention behind. And please note also that the word “safety” is not
>> forbidden. Guidance is provided, very much in line how “safety” is used in
>> functional safety standards.
>>
>>
>>
>> Med venlig hilsen / Best regards / Mit freundlichen Grüßen
>>
>>
>>
>> Thomas Maier
>>
>> E: Thomas.Maier_at_xxxxxx >>
>> T: +45 42 13 74 52
>>
>>
>>
>> *Fra:* systemsafety-bounces_at_xxxxxx >> [mailto:systemsafety-bounces_at_xxxxxx >> af * Peter Bernard Ladkin
>> *Sendt:* 21. maj 2014 09:20
>> *Til:* systemsafety_at_xxxxxx >> *Emne:* Re: [SystemSafety] words you cannot use at GM
>>
>>
>>
>> This would seem to be one of the disadvantages of not taking IEC/ISO
>> standards seriously. In European arbitration, the claim "the applicable
>> international standard says...." is mostly taken very seriously by the
>> arbitrators, I understand.
>>
>>
>>
>> Not that the standards are perfect, or even wonderful..... :-) But they
>> do tend to say " there is no such thing as zero risk". Indeed, in IEC 61511
>> you're only "allowed" to assume that an otherwise-unqualified process
>> control system has a failure rate of 1 in 10 ophours or worse.
>>
>>
>>
>> PBL
>>
>>
>> Prof. Peter Bernard Ladkin, University of Bielefeld and Causalis Limited
>>
>>
>> On 21 May 2014, at 00:02, Eric Scharpf <EScharpf_at_xxxxxx >>
>> Unfortunately this is not surprising. I have dealt with other US
>> companies which have indicated that any statement acknowledging a non-zero
>> risk from their equipment invites legal damages in potential product
>> liability lawsuits.
>>
>>
>> This e-mail may contain privileged or confidential information. If you
>> are not the intended recipient: (1) you may not disclose, use, distribute,
>> copy or rely upon this message or attachment(s); and (2) please notify the
>> sender by reply e-mail, and then delete this message and its attachment(s).
>> Underwriters Laboratories Inc. and its affiliates disclaim all liability
>> for any errors, omissions, corruption or virus in this message or any
>> attachments.
>>
>> _______________________________________________
>> The System Safety Mailing List
>> systemsafety_at_xxxxxx >>
>>
>>
>>
>> This e-mail may contain privileged or confidential information. If you
>> are not the intended recipient: (1) you may not disclose, use, distribute,
>> copy or rely upon this message or attachment(s); and (2) please notify the
>> sender by reply e-mail, and then delete this message and its attachment(s).
>> Underwriters Laboratories Inc. and its affiliates disclaim all liability
>> for any errors, omissions, corruption or virus in this message or any
>> attachments.
>>
>> _______________________________________________
>> The System Safety Mailing List
>> systemsafety_at_xxxxxx >>
>>
> _______________________________________________
> The System Safety Mailing List
> systemsafety_at_xxxxxx >
>
>



The System Safety Mailing List
systemsafety_at_xxxxxx


The System Safety Mailing List
systemsafety_at_xxxxxx Received on Wed May 21 2014 - 22:42:42 CEST

This archive was generated by hypermail 2.3.0 : Tue Jun 04 2019 - 21:17:06 CEST