INTRODUCTION

In 2005, while preparing the 1987 paper for posting on the Archives web site, I found in the old file folder several additional illustrations that were prepared while the 1987 paper was being developed. These graphics illustrate the development of the conceptual framework for capturing and organizing specific behaviors of individuals with a role in accident and incident processes, to determine human performance in accidents and incidents. The need for the framework and its application are described in the 1987 paper.

Each illustration is followed by commentary about its origins and development. Software supporting the framework and its application has now been developed.

THE BASIC FRAMEWORK

Early investigative efforts to identify and describe why things happened as they did during accidents led to what influenced individuals to do what they did during accidents and incidents. That quest resulted in, among other findings, my differentiating habituated responses from adaptive responses when individuals were trying to cope in real time with events that were occurring around them and to them. At the time, I was also experimenting with data organization and display efforts to help with the development of descriptions and explanations of accidents I was investigating.

A personal experience that further spurred the development of this technique occurred during an open NTSB meeting. A truck driver who was trying to disconnect a battery wire in his wrecked gasoline tank-trailer vehicle died in a fire that was ignited by his actions. Knowing from the investigation that the driver died because he did what he was trained to do, it was discouraging to hear a Member observe "That was a dumb thing to do" while discussing the driver's actions. I was frustrated that I had not demonstrated clearly enough so anyone could understand how the driver's "habituated" behavior was produced by his prior training. Narrative descriptions obviously were not getting the job done. I was trying to respond to that challenge when I started exploring the displays reported in the 1987 paper.

While pursuing attempts to identify what produced habituated responses, or what actions or experiences "programmed" the observed habituated responses, I had discussions with a few interested colleagues who were kind enough to listen to what I was trying to explain. This first illustration resulted from a challenge during a discussion with a friend who suggested that it was difficult to comprehend what I was talking about. So these illustrations were developed, leading, in part, to the illustrations and content of the 1987 paper.

The first illustration depicts the two kinds of "programming" behaviors that influence subsequent behaviors during an accident or incident process: external programming and self-programming. To program is to cause or absorb or incorporate automatic responses. attitudes or the like. in other words condition people or objects to behave in a particular way. Programming behaviors, for the purposes of assessing human performance, are the actions by people, objects or energies that are observed by an individual, and that influence subsequent actions by the individual, producing "habituated" responsive behaviors. External programming results from actions by other people or objects, and self-programming results from personal experiences from which individuals draw conclusions about future behaviors and thenact on those conclusions. The programming actions can be objectively identified in concrete terms by identifying the actions that "conditioned" specific subsequent actions. Identifying these specific programming actions should be a major objective for incident investigators. In the MES system, such actions are identified as "change makers."

It must be noted that programming actions do not usually, by themselves, result in process deviations or excursions, but rather, in combination with other changes, they require identification to fully understand why people or objects did what they did.

Figure 5 at the end of this addendum offers examples of "programming" behaviors which exerted such an influence on subsequent actions.

COMPARING ACTUAL VS EXPECTED ACTIONS

When actions during an accident or incident are being investigated, questions frequently arise about what actions were expected. This framework provides a way to organize and compare data about what someone or something did with what they were expected to do, by displaying both the actual actions during a current incident, and then display what they were expected to do based on expectations established before the occurrence.

If a divergence between actual and expected actions is found, the data point to specific actions that need further investigation, to determine what might have influenced this difference. Sometimes the expectations are valid and the actions were programmed differently from the expectations, and other times the expectations are incongruous for the process that actually occurred. The framework provides for stark comparisons in concrete action terms, rather than abstractions, leading the way to modify specific behaviors - by the individuals who established the expectations, or the individuals or objects that acted in accordance with the behavior actually programmed into them.

As the development progressed, it became apparent that this approach also lends itself to the assessment of the expected actions, whether prescribed by regulation or by private procedures, and by extension, the methods by which regulations or private procedures were determined to be needed. The assessment is based on whether and how or how closely expected actions relate to action actions disclosed during an investigation.

During development steps, the idea of presenting the ameliorative response actions in the fourth quadrant was considered, but abandoned when those actions were later deemed to part of the accident process. The reasoning was that harm continued to occur during those responses, and if the harm was contiguous, the response actions would be included as part of the accident process. If the harm is not contiguous, the response actions would be treated as a separate occurrence. Because of this uncertainty, the fourth quadrant was abandoned.

COMPARE THIS INCIDENT WITH PRIOR INCIDENT

When scenarios are developed over time for all incidents, a "corporate memory" is generated for users. This becomes available to investigators in the form of similar event sets that can be compared during an investigation. Overlays of similar event sets, for example, can indicate where data to support the current investigation is lacking, thus helping to identify what additional data might still be needed to complete the investigation tasks.

The corporate memory can also be used to compare problem event sets with proposed coupled actions in new designs, or their occurrence if procedural or design changes are implemented, to support change management decisions.

One of the challenges during investigations is to find and describe dynamic relationships among coupled interactions that sustained the process to achieve the outcome of interest. This was a tough nut to crack, but by using the matrix framework, the challlenge has been met.

This view provides a slightly different representation of how accident investigations might be facilitated by using the events overlay comparisons to verify, find or hypothesize events to complete events sets or process descriptions and explanations.

The main point is that events sets showing coupled, timed interactions, rather than just data points as are provided in typical data bases of accident data, enables investigators to view process dynamics instead of isolated data or statistical outputs. The presence of some like events in the two sets provides indicators of what additional like events might be present in the current process being examined. This holds true in any of the quadrants of the framework.

REAL TIME MONITORING

Another useful application of the Multilinear Events Sequence-based event sets was the realization that the developing corporate memory could be used for monitoring dynamic processes in real time, to determine whether coupled events in any of the sets are present, raising process risks. This can be accomplished by looking for specific combinations in action sets, whether coupled yet or not, while observing what people and objects are doing while they are doing it. Just as red lines on gages warn of looming problems, so can deviations from the documented expected interactions derived from the events displayed in the MES framework warn of problems. This provides a concrete procedure for preventing unwanted deviation from norms, by nipping unanalyzed or unauthorized deviations from expected actions in the bud before they blossom into full blown incidents.

Another aspect of this use is for assessing training in expected procedures by similar comparisons with intended versus actual behaviors, or performance to design using similar comparisons.

EXAMPLE OF PROGRAMMING ACTION DISPLAY

This simplified example was prepared during the development process, as can be seen by the title which refers to the use of "four quadrant" displays. However, only three quadrants are used. Also MES has replace the STEP designation because of the expanded functions in MES. Actual displays today are much more advanced, but this was a start that gives an indication of their form and use. The software now available provides many other capabilities not anticipated in 1986 when the developmental work was in progress.

In this example the accident process began with the first deviant action that started the process which produced harm, when the operator blocked the foot pedal safety switch on the press. This hypothetical scenario illustrates how actions by "programmers" and self-programming due to personal experience prior to the beginning of the actual accident process exerted an influence on actions during the accident process. By dismissing the importance of compliance with safety requirement, the trainer and supervisor actions helped produce a habituated response (blocking the safety pedal) among all operators exposed to these acts.

As can be seen, the display provides a way to identify concrete actions by specific individuals whose behaviors need to be changed, e.g., specific "actionable actions." Compare these results with those achieved by ambiguous causal factors, alleged errors, blame or root causes and other abstractions which lead to ambiguous proposals for changes, difficult to act on and monitor during operations, yet which are reported so commonly in current investigation practices and in safety research literature.

i have found that the ability to define needed actions with specificity, and limit the "wiggle room" for those who would resist needed change, offers major benefits for using this data organization and presentation framework.

Additionally, the discipline imposed by the display specifications forecloses unwarranted allegations and assumptions that can do irreparable harm to individuals or organizational entities resulting from ambiguous abstract charges like inadequate corporate safety cultures, or pilot error, to name two common examples.
>