She’s a Menace!

The Titanic had two sister ships, the Britannic and the Olympic. There was a woman called Violet Jessop, a nurse and a cruise liner stewardess that worked on all three. (That’s her, to the right->)

1. The Olympic crashed into a warship whilst leaving harbor but was able to make it back.
2. She was on the Titanic as it sank and is referenced in the Titanic film, a stewardess that was told to set an example to the non english speaking passengers as the ship sank. She looked after a baby on lifeboat 16 until being rescued by the Carpathia the next day.
3. It’s not known what exactly caused the sinking of the Britannic but the lifeboats hit the water too early. As the ship sank, the rear listed up and a number of the lifeboats were sucked into the propellers. Violet had to jump out of the lifeboat she was in and sustained a serious head injury, but survived.

She was on board for all three incidents in the space of 5 years.

So it’s pretty safe to assume that Violet, a factor in all three events, is the cause of ships sinking.  Right?  It’s hard to argue the odds of that “factor” in all three incidents being random.  So since we are in a rush to improve ship safety we are banning the carrying of passengers or crew with the name “Violet.”

Sounds like a foolish conclusion and mitigative action.   But…  I imagine a lot of you reading this have seen the desperate search for the root cause of an issue lead to a premature conclusion and corrective action. It goes something like this.

1. Chronic issue in design/prototypes/manufactured units.
2. After weeks of desperate investigation and weekly team meetings, that include multiple levels of the organization, someone finally finds what looks like a common factor to all found errors.
3. It’s mentioned as an “idea”, “thought”, “possibility”, “observation” in an update meeting.
4. “Must be it!  We don’t have much more time left to solve this.  Do what it takes to correct it.”  The odds of this being present in all cases and not being the issue are unlikely at best.  “Sure do some testing in parallel to implementing the solution to prove we are right.”
5. Action is taken, the issue continues to appear in product, and mysteriously no-one remembers being in the group that gave the “go-ahead.”

How do we protect against “action” on incomplete information?  First we need to create classifications for information.  Without labels anything that is “hopeful” quickly get’s promoted to A “proven cause and effect relationship.”  This usually takes about one meeting cycle.  If specific terms are used for information with different levels of credibility/assuredness then this “promotion” affect won’t happen.  It is important for the “information” status changes to be reported and documented. All accountable team members need to have a say on status change.

Some suggested definitions:

• An “Observation”: An individual performing the investigation or data analysis has noted something of interest
• A “Hypothesis”:  A statement of cause and effect for an “input” and “response” that is yet to be proven
• A “Confirmed Hypothesis”: A hypothesis that has a statistical “p” value based on a completed “designed” test. (p-value indicates likelihood of results being random.)
• “Validated Relationship”: A statistically validated relationship between inputs and responses through experimentation

-Adam