Applying Safety Critical Task Analysis (SCTA) to a hazardous task: Indoor Rope Climbing 

Recently, I started taking on indoor rope climbing. Having been on both ends of the rope, I was curious about how this would look from a Safety Critical Task Analysis (SCTA) perspective.

Since Fall/Autumn, I started taking on indoor rope climbing after doing indoor bouldering for over a year. Having been on both ends of the rope (climber and belayer*), I was curious about how indoor rope climbing would look from a Safety Critical Task Analysis (SCTA) perspective. 

Many critical steps are involved throughout a climb, such as tying the rope securely and doing a buddy check. If these steps are not done well, it could result in a severe injury. Hence, in this blog post, I will use the activity of completing an indoor rope climb, specifically a top-rope climb, to illustrate the SCTA process.  

*A belayer is an individual who is responsible for applying tension (by taking in slack) on the rope to ensure that the climber is safe when on a route.

What is top-rope climbing?

Figure 1: Top-rope climbing vs lead climbing (Photo source:

There are two types of rope climbing: top-rope climbing and lead climbing.

In top-rope climbing, the rope is already anchored at the top, whereas lead climbing requires the climber to clip in their rope as they climb. Top-rope climbing walls are between 10m to 18m tall, while lead climbing walls are at least 15m tall.

As you can imagine, falling from that height can be dangerous for the individual. Therefore, some steps are highly critical to ensure that the climb is as safe as possible. 

Stages of doing an SCTA

Figure 2: Workflow

There are six stages of conducting an SCTA. These are:

  1. Task identification – A subset of high-criticality tasks is selected for detailed analysis from the overall set of tasks. 
  2. Hierarchical Task Analysis (HTA) (See figures 3-5) – The task is broken down graphically to show the overall task objective (or goal), the subtasks required to achieve this goal, and the individual steps within each of these subtasks. Further breakdowns can be used if the steps require additional detail.  Normally the bottom level of the HTA consists of single steps such as opening a valve, which cannot realistically be broken down into finer levels of detail.
  3. Failure Mode analysis – Each step of the task is analysed for any potential human failures that could occur
  4. Performance Influencing Factors (PIF) analysis – Any factors that affect the likelihood of the identified human failures (both positively or negatively) are considered
  5. Evaluating the existing Hierarchy of Control (HoC) (See Figure 15)
  6. Improvements and Cost-Benefit analyses) Identifying the most cost-effective potential improvements and integrating them into the task

Hierarchical Task Analysis 

To start the analysis, the task was broken down into several sub-tasks. These sub-tasks depict the different phases of the task. 

  • Prepare to climb
  • Tie in the rope
  • Prepare rope for belaying
  • Check that the rope is secured
  • Commence climb
  • Lower the climber once the route is complete
Figure 3: HTA of a top-rope climb on a high level using SHERPA Software

In addition to the sub-tasks, the necessary preconditions for the task to be performed safely are also defined in a separate box. Typical preconditions could be adequate levels of competence for the personnel involved, the availability of effective PPE and required technical equipment.

Once the task was mapped out, we can assign each step to an Agent or Person, (the piece of equipment or person or required to perform the step). In this case, this was either the climber, the belayer, or both.

Figure 4: Example of a branch in the HTA using SHERPA Software
Figure 5: Example of a branch in HTA using SHERPA Software
Figure 6: Full breakdown of the task using SHERPA software

Once the HTA is created, we can start the next stage, which is the Failure Mode analysis

But where do I start? Focusing on risk.

Given that tasks often include a large number of steps, starting the analysis can feel overwhelming. One way to approach an HTA is to rank the components of the task (subtasks or task steps) in terms of the risk they pose if an error occurs. This is advantageous as it focuses analysis resources on the areas with the greatest risks. 

Before we start risk ranking, it is useful to list the possible hazards involved in the task. This helps gain a more complete understanding of where the risks are located. 

Unsecured rope during the climb (e.g. not tied in properly, not secured to carabiner/belaying device)Climber’s rope does not go through both tie-in loops Poor figure 8 knotBelayer’s rope does not go through the carabinerBelayer’s carabiner is looped into the wrong loop
Weak tension on the ropeBelayer not taking in slack during the climb
Damage to the rope due to setupFriction caused by crossed rope at the anchor point
Injury to climberClimber falling from the wall 
Injury to belayerBelayer being pulled upwards and towards the wall due to the momentum of the climber falling

Once we have a picture of the hazards, we can think about how the steps relate to the hazards identified and rank them based on the risk they provide. 

Figure 7: Example of risk ranking using SHERPA software

Failure Mode Analysis

The next step is to conduct a Failure Mode analysis for the task. This process consists of going through each step and exploring the potential human failures that could occur. v For example, the climber could fail to tie in the rope to their harness (“Action omitted”), or the belayer could partially complete their safety checks before commencing the next step (“Check incomplete”). 

Figure 8: Example of potential human failures from the “Action” activity type using SHERPA Software
Figure 9: Failure Modes selected for step 5.6

In the example above, the failure modes “Check omitted”, “Check incomplete”, and “Check too late/early” were most relevant to reducing slack on the rope. Once these failure modes were identified, further elaboration of the error and its consequences was performed. 

For the purpose of this exercise, the failure modes chosen were based on my personal experience and observation at the climbing centre. However, during a typical SCTA, discussions with a group of experienced individuals (e.g. those working at the shop floor level) is crucial to ensure that all potential errors are considered. 

Figure 10: Failure modes with error description and consequences using SHERPA Software

This was repeated for the other critical steps.

Figure 11: Failure Mode analysis for other critical steps using SHERPA Software

Performance Influencing Factors (PIF) analysis

After identifying the various failures, we move on to looking at the Performance Influencing Factors (PIF). These are features of a particular task which determine the likelihood of such failures. 

Figure 12: Example of PIFs using SHERPA Software

Once the PIFs have been narrowed down, you can evaluate whether these could negatively or positively affect the probability of failures. Negative PIFs could increase this probability, while positive PIFs reduce it. 

Figure 13: Identified PIFs for step 5.6 using SHERPA Software
Figure 14: PIFs selected for FM 5.6.1

For FM 5.6.1 Check omitted in the above example, the following PIFs were selected and evaluated. 

The column headed ‘PIF Description of worst-case situation’ provides a definition of what would be regarded as the worst case for that PIF.  

The judgement regarding the actual state of the PIF in this scenario is made by the analyst and is documented in Column 3. 

Negative means that the state of the PIF is similar to the worst-case situation described in Column 2, and hence is unacceptable and requires improvements to be made. The description in Column 4 provides the evidence for this conclusion. ‘Positive’ means that the state of the PIF is acceptable and therefore no changes are required to minimise errors arising from any deficiencies. 

PIFDescription of generic worst-case situation for this PIFNegative or Positive in this particular situationDescription
Quality of instruction/informationInstructions describing the requirement for the check are poor/unclear/absent.PositiveThe belayer is trained and aware that it is crucial to keep tension on the rope
Training and competenceThe operator does not understand the requirement for the check.PositiveThe belayer is trained and aware that it is crucial to keep tension on the rope
Perceived redundancyThe value of the check is seen to be low because there are other checks/barriers that are perceived as able to recover / prevent errorsPositiveThe belayer is aware that it is crucial to keep tension on the rope, and that other barriers are not available to mitigate the risk of failure
Perceived importance of check relative to other demandsThe value of carrying out the check is perceived to be low compared with other competing prioritiesPositiveThe belayer is aware that the main focus is to minimise the slack
Time pressureThe pace of work is very highNegativeThere could be little time to check that the slack is minimal if the climber is moving quickly.
DistractionsDistractions are excessiveNegativeThere can be distractions around the climbing centre (e.g. noises, observing other climbers)
FatigueFatigue levels are very highPositiveIf this is the start of the session, the fatigue levels would be low. 

Risk Reduction and Improvement

Once the failure modes and their associated PIFs are considered, we can begin to evaluate whether the risk control measures (RCMs) in place are strong enough to prevent these failures from occurring. If they are not, improvements, based on the Hierarchy of Control (HoC), should be implemented to counter this.

Figure 15: Hierarchy of Control 

Briefly, the HoC is a valuable framework for addressing Risk Control Measures (RCMs). In the case of a failure to reduce slack during the climb, one of the potential improvements would be to use an assisted braking belaying device. This device is designed to have an extra level of locking should the climber fall, hence reducing the risk of injury.  This would be regarded as an engineering layer of protection. In general, engineering layers of protection are preferable, as they normally have a greater intrinsic level of reliability.  However, they are usually more expensive and can often only retain their integrity if they are correctly maintained, inspected and tested. These MIT task are often carried out by human operators and hence risk analyses also need to be performed on these tasks order to maintain the effectiveness of the layers of protection.

One of the PIFs identified was that the work pace could become quite high, which could impinge on the belayer’s ability to take in slack. If the climber is climbing quicker than the belayer can manage, this puts pressure on the belayer to work faster. While this seems fine, it could also lead to a fumble if not careful. An improvement we could suggest here would be encouraging the belayer to communicate if the climber is going too fast or if they need more time to take in slack.


To summarise, we illustrated the SCTA process to illustrate the potential risks when performing a top-rope climbing route. We graphically presented the task to showcase the different phases of the task. Then, we looked at some of the failure modes for the critical steps and the PIFs involved. Once these were identified, we looked at how we can reduce the risks highlighted. This exercise clearly shows that the SCTA process does not apply only to tasks in the process industry. In fact, it can be utilised in any sector where human error could impinge on safety, quality, or production outcomes. These have included pharmaceutical manufacturing, rail and aviation transport, healthcare, and even the sports industry.

Dominic Furniss has written another blog post about SYSTEMS Critical Task Analysis. The post introduces the idea of Critical Task Analysis (CTA), whereby the Safety Critical Task Analysis principles could be applied in other industries. 

We recently launched our rebranded Systems Critical Task Analysis handbook. Following this, we plan to run a SYSTEMS CTA course in 2024, so keep an eye out on this space.