Social Sharing block
A horrific accident on Dec. 16, 2015, claimed the life of an airline service engineer: He was sucked into the live engine of an aircraft. The engineer had been standing on the ground supervising the aircraft being pushed in reverse from its parking bay.
|
ADVERTISEMENT |
“No one knew what happened,” said an Air India source. “All of a sudden we hear that the technician has been sucked into the engine. The body had been badly mutilated."
Aircraft can only move forward. Towing vans are used to push aircraft when they need to move in reverse. To supervise this process and be visible to the pilots, an engineer is positioned on the ground in front of the aircraft nose. During a regular startup, once the aircraft has been pushed back and is ready to start taxiing, the ground control gives startup clearance after ensuring that no one is near the engines.
…
Comments
No such thing as a root cause
Hi,
Unfortunately your pitch here is fundamentally flawed, which is odd if you come from the aviation industry where the following is "de riguer" in incident investigations.
There is no such thing as "a" root cause. The minimum number of causal factors is 2...one gap in the controls ("latent condition" in the Reason Model) and one behaviour ("unsafe act" in the Reason Model) that exploited it.
I commend you to Prof James Reason's two seminal books on the subject and to Dean Gano's small book about Apollo Root Cause Analysis.
This might help as an intro http://www.clearlineservices.co.nz/SiteAssets/qnewz-articles/1212Soluti…
Cheers
Generalization prevents improvement
Ian, you seem to have missed the whole point of my article.Nowhere have I said that there can be only "one" root cause.
Secondly, the main point of the article is about the "generalization" that sometimes follows such incidents - the article is not about the aviation industry, though a topical example has been used. I am sure your own statement that investigation is "de riguer" is true in "general", but the point I am making is that there is no evidence of any investigation in this particular instance. If you read the reports given as links in the article, they point to general statements (some of which may or may not have any link to the accident), without any investigation into this particular incident.
In my 30 years of working in quality across industries, I have come across a number of instances where there is a tendency to "explain away" a problem (which could be a customer complaint, a product defect, or an accident) with general statements, thus losing the opportunity for permanent improvement.
No such thing as a a root cause
Arun, your last sentence is "The message is simple: Keep asking why until you reach the root cause; don’t generalize or jump to conclusions."
This is wrong on two counts.
There as no such thing as the root cause, there are at least 2 causal factors, in fact two groups of causal factors. Second, simply asking why isn't enough either because it's linear in a binary model.
What you actually refer to I think, is what I call Solutions First Syndrome, where someone (or a team) jumps to a conclusion then makes their observations fit. The classic demonstration is the fishbone diagram, that requires the identification of cause areas first. In my 40 years, I have never known the fishbone deliver anything other than trivia and obfuscation.
Have a look at my paper..it might help....
Cheers
Focus on results, not jargon
Ian, please read my last reply. I don't think you have still got the message of my article. I have never said that there can be only "one" root cause. This article is also not about the relative merits and limitations of different methods of getting to the root cause (or causes).
The message of this article is "do NOT jump to conclusions or generalize" - I am sure even you will have no quarrel with that.
As far as the technique of getting to the root cause (or causes) of problems is concerned, may I refer you to my book Continuous Permanent Improvement (ASQ 2014) which has an entire chapter on the subject. This is based on actual implementation experience in a variety of companies, and provides actual examples of successful application and results. Again, I am not claiming that the method that the companies in the examples followed is the only method.
I would advise you not to get stuck up on terminology or jargon - what matters is application and lasting results.
No further correspondence in this matter from my side.
Add new comment