Task analysis
5.3 Hierarchical Task Analysis (HTA)
of information, or corroborating sources of information, such as upstream flow meters to confirm a valve position.
it or decreasing it. The sub-goals are subsequently redescribed in a similar way and this is continued to produce a hierarchy consisting of sub-goals at the higher levels and task descriptions at the lower levels, with each of these items given a unique hierarchical number.
In order to ensure that no important tasks are missed, it is recommended that each superordinate goal should not be broken down into more than seven or eight sub-tasks. This should ensure that an analyst can mentally visualise all the main goals/activities that might be required to successfully achieve the superordinate goal.
Thus, whilst in some conditions it may not be necessary meet all of the subordinate goals, an analyst should check that for each level of redescription the superordinate goal can always be fully met by some combination of the subordinate goals at that level.
Each task description should consist of a short, but clear and unambiguous sum- mary of the goals or tasks that would be sufficient to identify the essential elements of that task. Hence, general statements such asOpen valveshould be avoided and better identification of the valve or flowline should be provided. It is also necessary to ensure that the wording for each task description is unique. In particular, when a task is redescribed, none of the redescribed items should use the same wording as the original. However, it is acceptable to repeat the same wording between some of the lowest-level elements when they imply very similar tasks and where these are relatively straightforward.
At this juncture it is necessary to warn analysts to resist the temptation to blindly base an HTA directly upon an existing hierarchical structure, such as a written proce- dure. This is because HTAs developed in this way would use an identical framework to the written procedures, so that any errors or limitations in the procedures would be repeated. Thus, any such HTA would be unlikely to identify any important steps or actions that were not specifically mentioned in the source procedures. The author has seen many examples of HTAs produced in this way that have then been used to prove that the procedures are comprehensive, with no appreciation of the circularity of this argument.
Whilst the analysts must be permitted some flexibility in the HTA process, it is appropriate to provide some guidance about the way that task redescriptions can be organised. The following approaches to task redescription can be used:
• The most useful way to redescribe a superordinate task is by identifying the functions and sub-functions that have to be completed.
• At the lower levels in an analysis the different systems and equipments that are used can often serve as a helpful way to redescribe tasks(e.g. it may be useful to split the communication function dependent on the equipment used, such as phone, pager or public address).
• Once a set of redescriptions has been developed at a particular level, it is often helpful to arrange them into the sequential order in which they would normally be undertaken.
• In complex, multi-person tasks it is often helpful to keep tasks undertaken by the same person, or at similar locations, close to each other within an HTA.
5.3.2 Stopping rules
As the redescription process continues there comes a point at which it is no longer fruitful to redescribe the tasks in any greater detail. This level depends upon the requirements of the analyst and it is often very clear when this point has been reached.
Indeed, as task analysis is an iterative process, an analyst might well take a relatively arbitrary decision about where to stop redescription and then amend the HTA by undertaking further redescription at any points where subsequent analysis suggested that this might be useful.
Alternatively, an analyst could set criteria in advance to decide where redescription should be stopped. When HTA was first developed by Annett andDuncan [2] it was intended as a method of examining training requirements and so they suggested that redescription should only continue whilst the consequences of making an error were considered critical. Therefore, they argued that when there was a very low probability that an action was required or when the system cost of an error was low, no further redescription was needed. This was formalised into what is now known as theP ×CRule, which stated that redescription should cease at the point at which the probability of an error and the cost of its potential consequences fell below a particular criterion level.
Other stopping rules are directly related to the subsequent purpose of the analysis.
These criteria include continuing the redescription to the point at which:
• The main interfaces or functional elements within an interface can be identified.
• The tasks have sufficient detail to enable a workload assessment to be undertaken.
• The underlying knowledge and skills can be defined in sufficient detail. Thus for selection and manpower planning less detail is required than for developing a training programme.
5.3.3 Plans
At the end of the redescription process the task descriptions that have been obtained should provide a comprehensive picture of the tasks that are involved. However, in most situations, it is also necessary to understand how the constituent tasks are related to each other. For this purpose HTA plans are produced.Each time a superor- dinate item is redescribed, the relationships between all its immediately subordinate items is investigated and a separate plan is developed that explains the conditions necessary for undertaking that section of the plan. Thus, for example, if 1.2 was redescribed into three tasks,Plan 1.2 would describe the relationships between 1.2.1, 1.2.2 and 1.2.3. The simplest plan is for the tasks to be undertaken as a simple linear sequence, with no constraints, other than that the previous steps have been completed.
This is so common that, in order to avoid cluttering an HTA, most analysts do not specifically present these plans where all the tasks are undertaken as a simple linear sequence.
In other cases certain conditions may have to be met before a task can be left (e.g. ‘continue until the temperature reaches 100◦C’, or ‘continue for 10 mins’), whilst in other situations it may be necessary to undertake different actions dependent
upon the situation (e.g. ‘if the pressure rises above 5 bar, do this, otherwise do something else’).
All plans must involve at least one of the following structures and many may be a hybrid of them.
• Simple linear sequence.
• Constrained linear sequence, where progress to the next element depends upon particular conditions being met.
• Unordered list, where a person is free to undertake the tasks in any order.
• Conditional or free choice branching, where at each branch point a person must decide which branch to follow next.
• Condition attainment looping, where a task is continued until certain conditions are met.
• Continual looping, such as monitoring and control tasks that are undertaken intermittently in parallel with other tasks.
• Concurrent tasks, where a person has to attend to two or more tasks over a period of time.
If an analyst identifies tasks that are being undertaken as an unordered list, it is suggested that a check should be made to ensure that these should really be undertaken in this way. In the author’s experience, even when operators consider that tasks can be undertaken in any order, there are sometimes good reasons for adopting a specific approach.
5.3.4 Presentation of HTA information
It is extremely helpful, both for the analyst and for anyone reading an HTA report, to produce HTA diagrams like the one presented in Figure 5.2. This shows the hier- archical relationships between the tasks and makes it easier to see how sets of tasks interrelate. However, the value of HTA diagrams will be limited if they are too com- plex to enable the information on them to be readily assimilated. Therefore, in a complex HTA it may be helpful either to reduce the amount of supplementary infor- mation that is shown, to split the diagram on to several pages, or to remove the lowest level elements. However, the latter approach should only be taken when the lowest level elements are trivial or repetitive(e.g. if most communications tasks split into similar elements for using either the phone or a radio).
Where HTA is used, an HTA diagram should be considered as the reference point for the task analysis. Therefore, all other references to tasks shown in the HTA diagram should use identical wording. If possible, it will also be extremely helpful to show the hierarchical numbering at the top of each box on the diagram. However, this may not be practical if there are five or more levels, and in this case it may be sufficient just to show the numbering for the top-level boxes on each page.
Considerable flexibility is available in the way that HTA data are presented, espe- cially if colour is used. However, whilst there are no firmly established conventions, the following are recommended.
Reduce boiler pressure
4
4.1 Reduce boiler
Stop pump 4.2.1
Close isolation valves
4.2.2
4.5.1 Prepare steam
pump
4.5.2.1 Initiate flow through de-aerators
4.5.2.2 Stabilise de-aerator temps
4.5.2.3 Increase flow to
maximum 4.5.2
Warm de-aerators
4.5.3 Raise de-aerator
pressure 4.2
Shutdown pump 4.3
Ensure there is no excess steam
4.4 Reduce feed
flows
4.5 Put pump system in service
4.6 Control feed flows and control
boiler pressure C1
H7 Plan 4: Do 1 then 2, then start 3 and repeat as necessary.
Continue with 4 then 5. When 5 completed stop doing 3, then do 6 long term.
Plan 4.3: Do 1 at least once every 5 min.
If at any point pressure is above 100 psi do 2, then 3, then return to 1.
Plan 4.5: Do 1 and 2 in parallel.
Do 3 when de-aerators fully open
Plan 4.5.2: Do 1 then 2. When temp stable for 10min do 3
4.3.1 Monitor steam
pressure
4.3.2 If necessary, open steam valve
for short time
4.3.3 Ensure steam
valve fully closes
Figure 5.2 An HTA diagram
• Where plans are shown, these can be presented as plain text, as conditional logic statements, or as flow diagrams. However, for most audiences, plain text is preferred. In order to differentiate plans from other information, they should be presented in italic text. It can also be confusing to present plans within boxes and so this should not be done.
• Shading and colouring the text boxes can be used to differentiate task features that an analyst deems particularly important. Such features could include; safety critical tasks, tasks done by particular persons, tasks done at particular locations, tasks for which recommendations are made, tasks where potential errors are likely, or tasks that share particular characteristics(e.g. decision-making). However, no more than three classes of feature should be shown in this way.
• Repetitive tasks, such as monitoring, can often be shown very effectively by drawing their boxes with pecked lines.
• It is useful to indicate those tasks where no further redescription has been made;
this is commonly indicated by drawing a horizontal line below that box. This serves to differentiate these from task boxes where further redescription was carried out.
Replace faulty motor shaft
6.4
Disconnect motor shaft 6.4.1
Move motor to workshop
6.4.2
Effect repair 6.4.3
Isolate electrical supply
Unfasten connectors
Remove cover Draw shaft clear Unfasten retaining bolts
Ensure plant is left safe Transport shaft to workshop
Figure 5.3 Ladder style of HTA diagram
• Where further redescription is shown on another page, there should be a triangular box below that box with a clear reference to the page and the entry position on the next page. Then, on that next page, another triangular box should indicate the location of the superordinate tasks and the lowest level box from the previous page should be repeated.
Although HTA diagrams normally follow the box structure as presented in Figure 5.2, an alternative structure, known as a ladder, can be used in some cases to show the lower levels, so that more information can be shown. An example of this is given in Figure 5.3.
HTAs can also be presented in a tabular format(see [3] for further details).