The development and implementation of — and adherence to — standard operating procedures (SOPs) has been an important contribution to aviation safety. Human factors considerations affect both the philosophy behind SOPs and their design.
“Procedures are specifications for conducting predetermined actions,” the International Civil Aviation Organization says in Doc 9683, Human Factors Training Manual. “They specify a progression of actions to assist operational personnel achieving their tasks in a manner which is logical, efficient and, most importantly, error resistant. Procedures are not produced in a vacuum nor are they inherent in the equipment; they are based on a broad concept of operation.”1
A frequently used method for procedure development is hierarchical task analysis (HTA), which is solidly established in the field of human factors. Human factors expert John Annett says, that HTA is recognized as a difficult method, as analysts require training and possibly years of experience to acquire needed skills.2 The analysis does not simply list the physical or cognitive actions or processes involved in performing a task, although it is likely to refer to one or both. As opposed to task description, HTA aims at identifying performance problems or sources of error and proposing solutions.
Most Common Form of Task Analysis
According to human factors expert Neville Stanton, HTA is the most common form of task analysis.3 HTA was originally developed as a means of determining training requirements and has survived to represent a hierarchy of system sub-objectives for extended analysis. It is used for a wide range of applications, including interface design and evaluation, function assignment, job aid design, error prediction and workload evaluation, Stanton says.
HTA has the peculiarity of being functionally (goal) oriented rather than being descriptive. According to Annett, HTA does not start with a list of activities, but by identifying the goals of the task.4 “HTA is a flexible tool that can be adapted to a variety of situations and needs. Data may be derived from any number of different sources, the analysis can be continued to any desired level of detail, and there is no rigid prescription of how the results may be used,” he says.
Stanton says that HTA can be used to describe both teamwork and non-human activities performed by the system under analysis.5 HTA describes objectives for activities, such that each activity is described in terms of objectives (goals). HTA also requires the decomposition of sub-operations into a hierarchy of sub-objectives. To satisfy the objective in the hierarchy, its immediate sub-objectives must also be satisfied.
There is not really a “right” way to do HTA for SOP development as the technique is adaptable. There are, however, some main steps that define HTA as a process. In this article, we shall review the main steps of HTA from the perspective of their theoretical foundation and with an example from helicopter emergency medical service (HEMS) operations.
Scope and Boundaries
The first step is to define the scope of the analysis. The purposes of HTA include system design, interface design, operational procedure design, development of personnel specifications, analysis of workload and levels of personnel, and training planning, according to Stanton.6 All of these purposes may be accounted for in the context of HTA for SOP development.
After defining the scope of the HTA, the boundaries of the system must also be defined; depending on the purpose, the boundaries may vary, Stanton says.7 Typically, an air operator’s system boundaries are relatively straightforward; SOPs are documented in the operations manual, and regulatory references are rigidly prescribed, making it easy to define what is within the HTA’s scope and what is not.
Operations Review
An operations review as a main step of HTA for SOP development requires that current operations be observed to characterize how they are typically performed.
It is necessary to access a variety of sources of information about the system to be analyzed, including line observations by non-experts; interviews with subject matter experts, flight crewmembers, technical crewmembers, and others; operations manuals; walkthroughs; and simulations.8
Functional Decomposition
Together with data collection, there should be a description of the objectives and sub-objectives of the system. In fact, the general aim of the analysis is to derive a hierarchy of sub-objectives for the tasks under consideration. One should try to keep the number of immediate sub-goals under any superordinate goal small and to link the objectives to the sub-objectives and describe the conditions under which the sub-objectives are activated.9
When the level of detail is satisfactory, the analyst should try to verify the analysis with subject matter experts and be ready to review the analysis.10
A useful notation convention that can be used for HTA is that of functional flow block diagrams (FFBDs), which define the system functions and depict the sequence of functional events. According to the U.S. National Aeronautics and Space Administration (NASA), FFBDs identify what must happen but not how a function will be performed.11 FFBDs are functionally oriented, not solution oriented. Each diagram contains a reference to other functional diagrams to facilitate movement between diagram pages. Figure 1 illustrates the FFBD notation convention that can be used for HTA.
Annett points out that the decomposition of goal hierarchies and the redescription of operations and suboperations could continue indefinitely without the use of a stopping rule that specifies the level of detail beyond which no further redescription is useful.12 The definitive rule is to stop when one has all the information necessary to satisfy the goals of the analysis. However, since the overall purpose of HTA is to identify sources of actual or potential performance failure, a generally common stopping rule is to stop when the product of the probability of failure and the cost of failure is judged acceptable, he says.
When HTA has reached the desired level of detail, the result of functional decomposition is a hierarchically structured “instantiation” (representation) of the process within the scope of the analysis. Figure 2 shows an example of instantiation deriving from the functional decomposition of HEMS operations using the FFBD notation convention.
Risk Assessment
According to Annett, it is crucial to HTA to establish what the performance goals are and how one would know whether these goals have been attained.13 A common mistake is to assume that this question is about observed operator behavior, such as using a particular method, rather than performance results, such as the possibility of error. It is appropriate to identify such issues early in the analysis through in-depth discussion with all stakeholders. As the decomposition proceeds, more detailed objectives and more specific criteria are identified, and it may emerge that different operators with apparently the same overall aim have slightly different plans, which may imply different sub-objectives.
HTA provides a means to generate hypotheses regarding the likely sources of actual or potential failure to achieve the overall objectives of the task and to propose appropriate solutions. HTA does not in itself include a set of diagnostic categories or a set of acceptable solutions to identified problems. HTA simply provides an efficient procedure for identifying sources of actual or potential performance failures.14
A practical way for the task analyst to identify and address performance failure sources is to embed a risk assessment in HTA. Useful guidance on how to perform a risk assessment for SOP development can be found in European Union Aviation Safety Agency (EASA) regulations — in EASA AIR OPS SPO.OP.230 — and the related acceptable means of compliance (AMC) and guidance materials (GM). While these apply to specialized operations such as aerial work, they can be applied to any type of operation requiring SOP development.
AMC1 SPO.OP.230 requires the risk assessment to describe the activity in detail, identify the relevant hazards, analyze the causes and consequences of accidental events, and establish methods to treat the associated risk. AMC2 SPO.OP.230 establishes an SOP template, while GM1 SPO.OP.230 includes template forms for risk assessment, hazard identification and mitigating measures, as well as a risk register. All these forms ensure the full traceability of the hazards, risks and mitigations that apply to the various functions that make up the process under analysis, which, at the risk-assessment stage, will have already been functionally decomposed and drawn in accordance with the notation convention.
In a risk assessment for SOP development, some general points to consider for safety purposes are time, redundancy, and error management. The timing of the initiation of any part of the SOP needs to be carefully analyzed for risk. Redundancy needs to be embedded to address the factors affecting the quality of SOP conduct. Error management techniques need to be considered to address the stressors possibly affecting performance.
Once the risk assessment is completed, the instantiation of the functional decomposition should be redrawn to include the results of the risk assessment. At this stage, as several notes and safety precautions are identified, the diagrammatic format of the instantiation should be complemented by a tabular instantiation that includes the results of the risk assessment. According to Annett, the diagrammatic format often helps to make the functional structure of the task clear, while the tabular format is more economical in terms of space and makes it easier to record additional notes, questions, and recommendations.15
Documentation
A tabular format is useful in preparation for the documentation of the SOP and should specify the activities to the needed level of detail and clarify the responsibilities of those involved. SOPs need to be documented as work instructions for operators to perform tasks according to a clearly defined sequence of functionally oriented steps.
The starting point for SOP documentation will be tabular notations of the functional decomposition, updated to include the results of the risk assessment. These tables need to be revised to consider the phraseology and the ordering of tasks. When documenting an SOP, attention must be paid to the appropriate length and level of detail. Care must also be taken to limit vocabulary size, using phonetically balanced and frequently used words, and the sequential constraints between the various tasks. Table 1 illustrates an example of SOP documentation from HEMS operations; the documented procedure is the same as the functionally decomposed procedure in Figure 2. The documentation of SOPs is the final step of HTA for SOP development.
HTA is a method of procedure development that is solidly established in the field of human factors to provide guidance to SOP developers. The main advantages of SOPs are that that they enable standardization, they work well in environments characterized by structured processes and large workforces, and they can be operationalized through training.
Image: © rathke | iStockphoto
Mario Pierobon, Ph.D., is the owner and scientific director of a safety consulting and training organization.
Notes
- ICAO. Doc 9683, Human Factors Training Manual. 1998,
- Annett, John. “Hierarchical Task Analysis.” In “The Handbook of Task Analysis for Human-Computer Interaction,” edited by Dan Diaper and Neville Stanton. Mahwah, New Jersey, U.S: Lawrence Erlbaum Associates, Inc., 2004.
- Stanton, Neville. “Hierarchical Task Analysis: Developments, Applications, and Extensions.” February 2006.
- Annett
- Stanton
- Ibid.
- Ibid.
- Ibid.
- Ibid.
- Ibid.
- NASA. Systems Engineering Handbook, NASA/SP-2007-6105 Rev1.
- Annett
- Ibid.
- Ibid.
- Ibid.
