Appropriate Uses

The method is useful when problems occur within a system but their cause (and sometimes their severity) is not known. However the method also takes account of helpful events that may have prevented loss or countered errors.

Procedure

1. Preparation: Arrange interviews with individuals who may have knowledge of hazards, unsafe practices, or events that could have or actually did result in injury or loss. It may also be useful if operators or maintainers write down firsthand accounts of what they observed. Critical incidents can also be collected using questionnaires, diaries, phone interviews, or computerized incident reporting systems. Develop consistent instructions for participants.
2. Obtain materials: Obtain records such as investigation accounts and accident records from departments or agencies that have responsibilities for safety and accident reporting. Possible sources include company safety departments, insurance companies or regulatory agencies
3. Gather facts: Interview individuals who have experienced problems or who have observed others who have had problems. Questions may be asked: ‘Tell me what you know about what happened’. A more structured approach may be adopted: ‘Please think of what was happening when you were carrying out activity X. Were any events particularly good or helpful to you. Were any events particularly bad or unhelpful to you? Ask participants to describe an event, what let up to it, and what happened as a result.
4. Analysis: Events and descriptions are stored in a database or spreadsheet. The analyst then looks for events that occur with some frequency, how often they occur and under what conditions the events occur. Create categories of these frequent events noting the kind of problem and the item that is associated with it e.g. a particular display on a control panel.
5. Interpret: Develop possible explanations for the source of the difficulty (e.g. user needs to know trend in values not just snapshot readings). With reference to improving performance, the results of a critical incident technique can be fed back into system design and the user interface to reduce or eliminate the cause of loss.

Participants and Other Stakeholders

• Personnel with experience of incidents to be surveyed or interviewed.
• An investigator or investigation team (possibly representing a regulatory body).
• System staff with the task of implementing recommendations.
• The media and the public who in serious situations will need to see that changes are being made.

Materials Needed

• Interview schedule or survey forms.
• Database or spreadsheet software to assemble and analyze recorded incidents.

Who Can Facilitate

Human factors personnel and task experts with interviewing skills and experience in analyzing human activities. It is helpful to have personnel who are not too close to the situation being investigated who may have difficulty in being objective.

Common Problems

• Respondents may be reluctant to reveal incidents that reflect badly on themselves.
• Respondents may reply with stereotypes, not actual events (using more structure improves this).
• A common questions is “How many incidents do you need to collect?” The number will vary depending on the complexity of the system.
• The wording of critical incident questions could influence the type of incidents reported (Flanagan, 1954).
• The meaning of “critical incident” must be clear to participants. Critical incidents can be minor or major events that led to negative or positive consequences.

Data Analysis Approach

This can be done using a spreadsheet. Every item is entered as an incident first. Each of the incidents is then grouped into categories. The analyst looks at the frequency of similar incidents and under what conditions are events occur. Possible explanations for the source of the difficulties are generated and validated with the systems staff or participants. The results of a critical incident technique are improvements in the procedures and system to reduce and preferably eliminate the chance of similar incidents re-occurring.

Next Steps

The implemented changes are audited to check that they are effective and similar incidents are not continuing to take place, or resulting in other problems elsewhere in the system.