When to Stop Breaking Down Tasks in an HTA


There comes a point in every task analysis where it is not worth redescribing particular tasks into any greater detail. With experience, you will be able to judge this point reasonably well. A stopping rule is a rule of thumb that you apply to your work in order to decide that more a detailed analysis of a task than the current level is not required in order to solve the current problem being studied.


A commonly quoted stopping rule is that you should only continue breaking down tasks as long as the consequences of undertaking an incorrect action were considered potentially critical, either because there was a very low probability that the action would be needed, or because the system cost of an error was very low. In general, the likelihood of something occurring times the severity is a description of risk.

In task analysis, we call this the P x C Rule. P is an estimate of the probability of inadequate performance at a task, and C is the cost of that inadequate performance including injury or commercial loss.   Redescription should stop at the point that the product of the probability of an error and its potential consequences fell below a particular criterion level.

While this is great in theory, it is often difficult to measure both the error probability and the error cost in reality. Therefore, it is seldom applied formally and is best treated as a guiding principle rather than an invariant rule.


As discussed in our blog series, 'The 7 Steps of Hierarchical Task Analysis', every task analysis has a goal or purpose.  You can make your stopping rule dependent on the purpose of your analysis. For instance, if it the purpose of your analysis is to describe the scope of a system to be designed, then an initial high-level analysis would be appropriate. The stopping rule might be 'Stop when sufficient level of detail has been discovered in order to understand the breadth and of the system.'


This is one of the most widely used stopping rules.  If you are designing a system, you continue to redescribe tasks until all the main interfaces or functional elements within the interface can be identified.


Workload is often measured by the amount of resources needed over a period of time.  Once you define the properties you are using to define workload, you would continue redescribing tasks until you are able to capture all the workload information you require.  This varies based upon the type of workload you are measuring.  If you are measuring the workload of many teams, you might stop when the measures for each team are know.  If you want to know how workload is distributed within teams, then you would keep redescribing tasks until the workload of each person can be assessed.


In planning manpower requirements, often described as job task analysis, you would continue to redescribe tasks until all the underlying knowledge and skills of the job description can be defined in sufficient detail.  For manpower planning purposes, you will only need to define skills and knowledge requirements at a relatively global level.


When you are developing a training program, you not only have to define the knowledge and skills needed to support task performance, but also you must review the information and decision-making necessary to support plans. This is the obvious stopping rule for Training Need Analyses (TNAs). 


What if you have more than one purpose in mind for your task analysis?  If your HTA is being used for more than one purpose, you should apply different stopping rules for the collection of different data. For example, if your HTA is to be used for both defining the training requirements and for assessing the interfaces, the data that are collected for a TNA could be obtained for higher-level tasks than that required to assess the interfaces.