Event Investigation Guidelines

• Step Two:  Define Problem

While critically important, this step is oftentimes not given an appropriate amount of attention in the investigation process. After all, you know what occurred (the event itself), so the 'problem' is obvious, right? Not necessarily.

It's quite easy, particularly when emotions are still flaring, to jump to conclusions. At this early stage, you may have a perception of what the problem is; however, the actual problem may be something quite different.

For example, let's say you climb into the driver's seat of your car, insert the ignition key, turn it clockwise, and...nothing happens. What might logically be the problem? The battery is dead. You might therefore consider your 'problem' to be: "Car won't start due to dead battery."

The problem is that jumping to such a conclusion ("the battery is dead") could easily lead you down the wrong path. For example, the actual problem (based upon what is known thus far) might be a bad ignition module, or maybe the key connection has ceased to make contact, or maybe the interlock requiring the transmission to be in Park has failed.  Get the point?

An excellent well-thought-out problem statement forms the foundation (and determines the scope) of a good investigation. It helps you and your team to maintain focus.

Here are some pointers for developing a quality problem statement:

• Discuss the event with cognizant personnel to clarify the perceptions surrounding the problem, as well as the resulting consequences. This is a 'sifting through the chaff' process. Remember- perceptions of the problem may not reflect the actual problem, but rather, symptoms of the problem.
• Identify only WHAT went wrong (not WHY). For instance, in the "car won't start due to dead battery" example, the "due to dead battery" portion of the statement is jumping to a conclusion regarding the "why", and should not be part of the problem statement.
• It may be appropriate to include key condition(s) surrounding the problem. In our example above, adding, "When turning ignition key to the START position," in the problem statement clearly defines the condition at the time of the event. This will not apply in all cases, but should be considered during the development process.
• When an event involves multiple deviations, identify the problem that is specific to one issue, yet coincides with all deviations.
• Identify the adverse effects or consequences of the stated problem and the associated severity.
• Ensure the problem statement contains only one problem.
• Ensure that the problem statement is not confused with the consequences. For example, if you were late to work because your car wouldn't start, "being late to work" is a consequence of the problem and should not be included in the statement.
• Ensure that the problem statement is not confused with corrective or intermediate actions taken. For example, "causing me to have to walk to work" would be an action taken statement and should not be included in the problem statement.

So with all of this information in mind, what would be a quality problem statement for our example of the car not starting?

"When turning ignition key to the START position, the car did not start."

Hopefully you can see how such a statement will aid the investigation. It makes the problem very clear, and will keep your investigation team focused on the problem (vice being led to any potential cause or mere symptom).