• Skip to main content
  • Skip to primary sidebar

This view of service management...

On the origin and the descent of managing services. We put meat on the bones.

  • Kanban Software
  • Services
    • Kanban Software Solutions
    • Consulting & Coaching
    • Training and Seminars
  • Posts
  • Events
    • Events – Agenda View
    • Events – Calendar View
  • Publications
    • Our Publications
    • Notable Publications
    • Quotes
  • About us

The Sinking of the Sewol and “Root Cause” Analysis

29 July 2014 by Robert Falkowitz 5 Comments

O why why why why why?

Ohno Taiichi provides an oft-quoted example of using the five whys to perform root cause analysis. His neat little scenario of making durable improvements in the operation of an industrial machine gives a misleading view of the reality of understanding the causes of problems. An analysis of the sinking of the Sewol sheds more light on what really happens to cause problems.

A black day in Korea

In April 2014, the Korean ferry Sewol sank while transporting its load of passengers and cargo. 304 of those passengers died as a result, making it what the New York Times called “one of the worst peacetime disasters in the nation’s history.” The remainder of this analysis is based on information provided in the Times.

Issues of design and control

The ferry itself had an unstable design. It had been renovated to add a luxurious art gallery and cabins in the top level, making it top heavy. In fact, the renovation did not follow the approved design, adding 100 tons more than what was approved. Although an inspector was assigned to the renovation to ensure the seaworthiness of the ferry, it appears that a critical “incline test” was not performed. Presumably, this test would have been failed. There is further evidence that Coast Guard personnel, who should have intervened and preventing the sailing of the vessel, were treated to various favors by the ferry company and turned a blind eye to the obvious problems.

Operational Issues

On the fateful day, the ferry loaded twice as much cargo as it was approved to take. This was not an exceptional practice. It had been reported before by the longshoremen, who were be cheated out of their wages. They are paid per ton of loaded cargo, based on the ship’s manifest. But the manifest regularly reported much less cargo than the reality.

There was so much cargo loaded that it was impossible to tie down properly. In addition, the extra cargo caused the ferry to lie too low in the water. Not a problem for the ever resourceful ferry company, a large amount of the ballast water, normally needed to ensure the stability of the vessel, was drained away. As a result, the ferry did not lye too low in the water, an obvious indicator of being overloaded. A shipping association, funded by the shipping companies themselves, is supposed to check that ships are not overloaded with cargo and prevent them from leaving port in an unsafe condition. This check was not performed or, perhaps, the load line painted on the side of the ship was put in a misleading position, masking the overloading.

The Sewol had a regular captain, familiar with the vagaries of the ship and how to avoid problems. But this captain was not aboard that day. A maneuver was performed that the captain had previously indicated was not safe, causing the ship to tilt dangerously. The cargo, much of which was not tied down, started to slide to one side of the ship, exacerbating the situation. The ship started to sink.

There was still hope for the passengers, even though the ship sank much more quickly than might have been expected, had it a proper design and proper operations. However, the crew told the passengers to stay inside when they should have been organizing the evacuation. When questioned about this, the surviving crew members admitted that they had no idea what to do. It later came out that the shipping company had spent a grand total of the equivalent of $2 on safety training during the previous year.

A diagrammatic analysis of the causes and the effects that led to the death of 304 passengers may be found in Fig. 1. The purpose of this diagram is not to be an exhaustive analysis, but rather to show the relations among the various causes and effects.

Cause-effect diagram for the sinking of the Sewol
Fig. 1: Cause-effect diagram for the sinking of the Sewol

No single “root cause”

It should be clear that the loss of life due to the incident was not due to any single “root cause.” Rather, it was due to a highly improbable series of contributory conditions and events. Even though the ferry sank, the passengers could have abandoned ship safely, had the crew known what to do. Even though the ferry was unstable, a captain familiar with its condition could have avoided dangerous maneuvers. Even though the ship had a top-heavy design, it could have been much more stable had the ballast not been drained or the cargo overloaded. And even though the cargo was overloaded, had it been tied down, perhaps the dangerous maneuver could have been survived without leading to the sinking.

The same issues for IT

Information technology, like a ship, is a complex socio-technical system. Although some IT services might fail due to simple causes, such as unreliable components, many IT incidents are due to similar series of events, combining exceptional user practices with poorly thought out architectures, unrecognized or unpatched software bugs and exceptional operational conditions, such as redundant equipment shut down for maintenance. Poor user training, ineffective controls built into applications, maintenance done without consideration of risks, lack of technical experience by system administrators, over-reliance on ineffective controls, software that goes unpatched for long periods, no systematic reviews of available patches, lack of resilience and scalability in technical architectures, absence of personnel who have no backups – the list of what could go wrong goes on and on. But only when two, three, four or more situations combine, do those fatal incidents occur.

We need to stop thinking in terms of one-to-one relations between problems and root causes and start thinking more in terms of contributing, multiple factors.

Creative Commons Attribution-NonCommercial ShareAlike 4.0 International License.The diagrams in this posting are licensed to you under the terms of the Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International license.
Summary
The Sinking of the Sewol and "Root Cause" Analysis
Article Name
The Sinking of the Sewol and "Root Cause" Analysis
Description
Root cause analysis is a misunderstanding of how many incidents are caused. The sinking of the Sewol is a good case study to illustrate this idea.
Author
Robert S. Falkowitz
Publisher Name
Concentric Circle Consulting
Publisher Logo
Concentric Circle Consulting

Filed Under: Problem Management Tagged With: cause, cause-effect diagram, effect, five whys, problem, root cause analysis

Subscribe to our mailing list

Click here to be the first to learn of our events and publications
  • Email
  • Facebook
  • LinkedIn
  • Phone
  • Twitter
  • xing
  • YouTube

Reader Interactions

Trackbacks

  1. The Service Manager's Role in AI | This view of service management... says:
    21 January 2020 at 11:12

    […] See, for example, my discussion of causality in The Sinking of the Sewol and Root Cause Analysis2  I had exactly this problem with a company with which I worked. No matter how many times I […]

    Reply

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Primary Sidebar

Kanban eLearning

Kanban training online

Recent Posts

  • Verbs, nouns and kanban board structure
  • The role of the problem manager
  • The Three Indicators

Tag Cloud

lean service management tools priority context switching change management impact risk service request manifesto for software development knowledge management value stream tools lean management problem histogram incident Incident Management incident management tools leadership service manager Cost of Delay resource liquidity cause process metrics ITSM flow bias kanban training automation manifesto flow efficiency process definition process rigidity kanban waste kanban board agile ITIL knowledge work
  • Kanban Software
  • Services
  • Posts
  • Events
  • Publications
  • Subscribe
  • Rights & Duties
  • Personal Data

© 2014–2023 Concentric Circle Consulting · All Rights Reserved.
Concentric Circle Consulting Address
Log in

Manage Cookie Consent
We use technologies like cookies to store and/or access device information. Consenting to these technologies will allow us to process data such as browsing behavior or unique IDs on this site. Not consenting or withdrawing consent, may adversely affect certain features and functions.
Functional Always active
The technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user, or for the sole purpose of carrying out the transmission of a communication over an electronic communications network.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Statistics
The technical storage or access that is used exclusively for statistical purposes. The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes.
Manage options Manage services Manage vendors Read more about these purposes
View preferences
{title} {title} {title}