Archives of Personal Papers ex libris Ludwig Benner, Jr.
rainbow line   - - - - - -Last updated 2/20/16.
    [Investigation Catalyst Software ] [ Investigation Research Roundtable Site ]   
[ Contact "me" at ludwigbenner.org ]


Project originally posted 2 Jan 98

MODEL OF HUMAN DECISION PROCESS FOR INVESTIGATORS

The Model

Making a decision is a process. This process has many common elements, whether made by people or objects. This model flow charts the general human decision process elements involved in accidents. The purpose of this model is to identify behaviors to change or emulate to reduce future safety risks. The model flow charts the general human decision process elements involved in accidents, in the sequence they must occur. Accidents are aborted when the decision maker directs the process to the no-accident outcome in an orderly way. The model was developed by consolidating observations during interviews with accident investigation witnesses. Guidance for applying the model in investigations follows the model.

Human Decision Process Model



Applying the
GENERAL HUMAN DECISION PROCESS MODEL
FOR MISHAP INVESTIGATORS

CAUTION:
DECISION ELEMENTS MAY BE AFFECTED BY CONCURRENT EVENT(S) DURING EXECUTION

For preparation, various human behavioral considerations that might be explored during the application of this model can be found in a reference describing what may affect behaviors. See Shappell, S.A., and Wiegmann, D.A., 2000, The Human Factors Analysis and Classification System-HFACS. . Document can be viewed at https://www.nifc.gov/fireInfo/fireInfo_documents/humanfactors_classAnly.pdf


This Model describes the general decision making process faced by people while interactions are occurring among people and objects during any kind of process. The model helps investigators discover and define changes, signals them emit; their detection, communication, and diagnosis; decisions required during the process, and the outcomes of those decisions. At each step, be alert for both unsuccessful AND successful behaviors.

By investigating effects of supervision, training, design, procedures, supervisory direction, and any other programmer input sources related to each of these elements, investigators can link specific prior actions or "human factors" to each element.

This tracking of each decision process element enables investigators to define specific relationships among actions as problems or needs. It then enables investigators to pinpoint the places to look for concrete actions (behaviors) that will change future performance, rather than describing problems and needs in subjective, ambiguous or abstract "human factors" terms such as errors, failures, causes, malfunctions, vigilance, attention, wrong, unsafe, skill errors, latent failures, active failures, etc.

To apply this Model during investigations or interviews, identify people who appear to have had a role in the incident process. Then begin to look for changes in the process or its environment that would have created an original need for action by some person (or object) to keep the process progressing toward its intended outcome. Determine the the extent possible the inputs which influenced each step. Then follow the same procedure for subsequent changes until the incident is understood and explained.

  1. When you identify a change, determine if it emitted or displayed some kind on signal, actuve or passive, that the person could have noticed. If it didn't explore why it didn't and what effect that had on the outcome.

  2. If it did emit a signal, determine whether the person saw, heard, felt or otherwise "observed" or captured the signal. If not, explore why not, and what effect that had on the outcome. If observed, try to undertand why also.

  3. If the person observed the signal, was the signal diagnosed correctly, in the sense that the person was able predict the consequence of the change from the signal and their knowledge of the system and its operation. Explore why or why not, and the effects.

  4. If the predicted consequences of the change were correctly identified, did the person recognize a need to do something to counter those consequences? Again explore why or why not, and the effects.

  5. If so, did the person identify choices for action that were available for successful intervention? Was this a new situation were the action had to be devised, or was this something that prior training anticipated and provided "cook book" responses to implement? In other words, was the person confronted by an adaptive or habituated response? (Here, you may begin to get into personal judgment issues, so explore this area with empathy toward the witness, particularly when faced with an adaptive responses.)

  6. If any response actions are identified, did the person chose the"best" or a timely effective response to implement? Explore why the response was chosen, or explore why none was. To this point, you are asking for observations during an interview.

  7. If a potentially successful response was chosen, did the person successfully implement the desired action? Explore why or why not.

  8. If a suitable response was implemented, the system adapted to the change without an accidental loss or harm. If the response did not achieve a no-accident outcome, explore why it didn't. Often this leads you to discovery of invalid system design assumptions or other design problems.

    After working with this model, you are in a much better position to describe and explain what happened when a so-called "human error" or"failure" is alleged. You will also be in a better position to identify concrete actions to improve future performance of that system.

    The model and its implementation will continue to evolve as new insights and demands surface.

      Source: FOUR ACCIDENT INVESTIGATION GAMES, Appendix V-F, Lufred Industries (now Ludwig Benner & Associates) Oakton, VA 1982 It was updated in INTRODUCTION TO INVESTIGATION, (1997) Fire Protection Publications, Oklahoma State University, Stillwell, OK. USA, now available at http://www.ludwigbenner.org/manuals/Guide-1%20ItoI.pdf

      Contact: Ludwig Benner, (luben) for support at ludwigbenner.org