Human Performance Tool Spotlight: Peer-Checking

Hello colleagues in the Human Performance Toolbox Community! I have recently been teaching some human performance fundamentals classes and have been asked to share content with my website visitors, and I love to share and trade human performance improvement information. So, I've made the decision that over the next few weeks, I will be publishing a lot of human performance tool (HPT) content specific to the tools field workers should be using.  As a reminder, tools are only part of a human performance improvement initiative and they are only to be used when they matter the most, which often is in preparation of managing a critical step, or recognizing you're in an error-likely situation.

Peer-Checking

Peer-checking (PC) is a series of actions by two individuals working together at the same time and place, before and during a specific action, to prevent an error by the performer. By my definition, a "peer" is someone you trust who is familiar with the task you're asking them to check you on.

Purpose

The purpose of PC is to prevent an error by the performer. Error prevention is the principal function of the PC technique. PC augments self-checking by the performer—it does not replace it. PC involves two people (performer and peer) self-checking in parallel, agreeing together that the action is the correct action to perform on the correct component.   Similar to concurrent verification (CV) but less formal, this technique takes advantage of a fresh set of eyes not trapped by the performer’s task-focused mind-set. The peer, an individual familiar with the activity, may see hazards the performer does not see.

Individuals often confuse PC with CV, and vice versa. Although both techniques help the performer avoid error for a specific action, the primary focus of CV is status control of the equipment, while the primary focus of PC is the performer’s action. PC focuses more on the correct act than the result of that act, although the peer is more effective as a checker if he or she is aware of the intended results. PC is usually requested by the performer to help him or her avoid a mistake. On the other hand, CV is typically specified in procedures or work packages and other guiding documents at vital steps in the sequence of activities.

Intended to be informal, people can apply peer-checks at any time to any work situation.   Peer-checks can be requested by anyone, and performed by anyone you trust and is familiar with the task and formally trained in the PC technique. In some cases, management establishes specific actions or classes of actions that require mandatory PC.

It is not recommended that PC be mandated for all human actions. Eventually, because of human nature, the PC practice will become mechanical, possibly leading to inattentive performance. Applying PC to relatively insignificant actions as well as important ones will likely degrade people’s rigor with the technique over time. Many activities are not necessarily important. The potential exists that PC may not be applied rigorously when it really counts during important steps. Recurring use of PC for all actions, regardless of their risk, will dilute the effectiveness of the tool in the long run.

When to use this Tool

Unless the guiding document already specifies CV, work activities involving tasks or situations such as the following could benefit from the use of PC:

• Critical steps which are irreversible actions
• Comparisons of test data with acceptance criteria
• Start or stop of major components
• Return to or removal from service
• Identification of correct parts or correct component before maintenance
• During installation of similar components or parts that could be interchanged or installed incorrectly
• Error-likely situations related to important actions

How to simply use this tool:

1. Two people (performer and peer) self-checking in parallel.
2. Both people agree together that the action is the correct action to perform on the correct component.
3. The performer takes the agreed-upon correct action.
4. The peer confirms that the action taken was correct.

A slightly more formal commonly accepted practice:

1. The performer self-checks the correct component.
2. The peer self-checks the correct component.
3. The performer and the peer agree on the action to take and on which component.
4. The peer observes the performer before and during execution, to confirm the performer takes the correct action on the correct component.
5. The performer executes the intended action on the correct component.
6. If the performer’s action is inconsistent with the intended action, the peer stops the performer.
7. If the performer’s action is consistent with the intended action, the peer informs the performer that the action taken is correct.

At risk practices to avoid:

• Peer is inexperienced with the task.
• Peer is not paying close attention to the performer.
• Peer is unable to view the component.
• Peer is significantly junior to the performer and may be reluctant to correct the performer.
• Peer is not prepared to prevent an error by the performer.
• Peer assumes the performer will not make a mistake.
• Performer acts before the peer is ready to perform the peer-check.
• Performer and peer swap roles during the task.
• Performer or peer does not self-check rigorously, assuming the other person will.
• Performer or peer uses verbal cues or observed actions of the other individual instead of personal confirmation or self-checking.
• Performer is less attentive to the action, believing the peer will catch any problems.
• Performer asks another person to peer-check, when that person is already engaged in a risk-important activity (such as transients).
• PC is over-used, eventually leading to complacency by both parties.

References:

With much gratitude, a lot of the above HPT basis comes from Department of Energy (DOE) and Institute of Nuclear Power Operations (INPO) research and collaboration, and the source document could be found by clicking here.

This article (you would have to purchase - sorry, it's not free to share) adds some more specificity to the discussion : Engaging Workers as the Best Defense Against Errors & Error Precursors by Jan K. Wachter and Patrick L. Yorio

Me. I've inserted a few twists and clarifications for users and myself.