I wonder

I wonder.

In my current life, I teach applied quantitative statistical analysis to MBA students in the on line environment. A difficult proposition given the lack of face-to-face time in the classroom. I have been rather surprised though by the good student performance that I have experienced over the years in this rather difficult discipline. In a recent discussion with students, one of my students put forth the idea that the Theory of Constraints or TOC was applicable to her position within a certain company’s safety department. That caught my eye and my attention. How could TOC be applied to safety, or more specifically naval aviation safety?

A brief background here. The Theory of Constraints was developed by Dr. Eliyahu M. Goldratt in his book titled The Goal published in 1984 (North River Press, 4th Edition, 2014). The end state of the TOC process is to revamp the thought process of organizational problem solving and to improve the bottom line of the organization. In Naval Aviation, the bottom line isn’t dollars but mission accomplishment, the preservation of aircrew lives, and the preservation of airframes. Only the latter has a dollar value. The key points of TOC are that it helps to identify what needs to be changed, how to implement the change, and finally how to measure the process once changed. This is done in a rather simple five step process:

1. Identify the system’s constraint.
2. Decide how to exploit the system’s constraint.
3. Subordinate everything else to the above decision.
4. Elevate the system’s constraint.
5. If in the previous step the constraint has been broken, go back to Step 1.

So what is the system’s constraint? And no; the constraint isn’t the Safety Department saying no to something that you would like to do with the aircraft. This starts with an examination of the historical data, what were the factors that led to a mishap? Perhaps an analysis by Type/Model/Series over the past five or ten years would give a statistically significant database to examine. The causal factor assumptions are: pilot error, maintainer error, mechanical failure, software failure (did not think that I would ever write that), supervisory error, design (human error actually) error and the occasional divine intervention. Although I would argue that in my life time I have never actually seen the latter. Of these seven potential failure points, four are human induced. That is important to the discussion. All or anyone of these can be the cause of a mishap. In my experience, there have been very few aviation mishaps that had singular casual factors. There are usually multiples in play.

One other assumption that we must examine is how we classify these causal factors in an aviation mishap. These being a primary causal factor and contributing causal factors. This is how the mishap board investigates and reports out on a mishap. It is the next steps that TOC is put into play and that is resolution. How do we prevent this mishap from occurring again? This is perhaps a paradigm shift. Causal factors are just that causal factors. No more primary and contributory causal factors in the resolution phase. Prioritizing the solution set is the first step. If the primary cause was pilot error, it is a bit tough to solve the problem after the fact. For example; the pilot (or crew) applied incorrect procedures for landing in brown/whiteout conditions. Pilot error? Sure but why is the real question. This gets to root cause and is essential to actually preventing future mishaps of a similar nature. In this example, was it because the pilot (s) were not trained in the proper procedure (a T&R Manual issue or a Supervisory issue?)? Do changes need to be made in the T&R Manual? What, how, who initiates and or implements? Does currency with this skill set need to be tracked such as we do with NVG or boat currency?

Again, I wonder if it is time to shift how we think about this issue?