Collective TNA

Training Needs Analysis for Team and Collective Training
The investigation which is the subject of this Report was initiated by the Research Programme Leader Human Capability. BAE Systems 2011. All Rights Reserved. The authors of this report have asserted their moral rights under the Copyright, Designs and Patents Act, 1988, to be identified as the authors of this work.
Reference ............................................HFIDTCPIII_T13_01 Version ................................................................................. 2 Date ................................................................. 16 April 2011
BAE Systems 2011. All Rights Reserved. Issued by BAE Systems on behalf of the HFI DTC consortium. The HFI DTC consortium consists of BAE Systems, Cranfield University, Lockheed Martin, MBDA, SEA, Southampton University and the University of Birmingham.
HFIDTCPIII_T13_01 Version 2/ 16 April 2011
Authors
Jonathan Pike Dr John Huddlestone Cranfield University Cranfield University
ii
Contents
1 2
2.1 2.2 2.3 2.4
Executive Summary ................................................................................... 1 Introduction ................................................................................................ 3

Background ......................................................................................................................... 3 Scope of Team/Collective Training Needs Analysis ........................................................... 3 Training Needs Analysis ..................................................................................................... 4 Methodological Approach.................................................................................................... 8
3
3.1 3.2 3.3
The Team/Collective Training Model .......................................................... 9

Introduction.......................................................................................................................... 9 Definitions............................................................................................................................ 9 Development of a Teamwork Taxonomy .......................................................................... 10 3.3.1 Review of Extant Teamwork Models ...................................................................... 10 3.3.2 Synthesis of a Teamwork Taxonomy...................................................................... 15 3.3.2.1 Results ......................................................................................................... 15 3.3.2.1.1 Initial Coding .............................................................................. 15 3.3.2.1.1.1 Leadership ............................................................................... 15 3.3.2.1.1.2 Situational Awareness ............................................................. 17 3.3.2.1.1.3 Task and Resource Allocation ................................................ 17 The Teamwork Taxonomy ........................................................................... 17
3.3.2.2 3.4
Development of a Team/Collective Performance Model .................................................. 19 3.4.1 Review of Team Effectiveness Models ................................................................... 19 3.4.2 Environmental Task Demands................................................................................ 23 3.4.3 The Team/Collective Performance Model .............................................................. 24 3.4.3.1 3.4.3.2 3.4.3.3 3.4.3.4 3.4.3.5 Task Environment ........................................................................................ 25 Performance Outcomes ............................................................................... 26 Team Processes .......................................................................................... 26 Team Properties .......................................................................................... 27 Team Member Characteristics ..................................................................... 27
3.5
Development of a Team/Collective Training Model .......................................................... 27
4
4.1 4.2
Review of Team Analysis Methods Applicable to TCTNA ........................ 30

Introduction........................................................................................................................ 30 Evaluation of Methods ....................................................................................................... 30
iii
4.2.1 Hierarchical Task Analysis for Teams .................................................................... 30 4.2.2 Team Cognitive Task Analysis ............................................................................... 31 4.2.3 Team Task Analysis................................................................................................ 31 4.2.4 Task and Training Requirements Analysis Methodology ....................................... 32 4.2.5 Work Domain Analysis ............................................................................................ 32 4.2.6 Mission Essential Competencies ............................................................................ 33 4.2.7 Models for Analysis of Team Training (MATT) ....................................................... 33 4.3 Evaluation.......................................................................................................................... 35
5
5.1 5.2 5.3
The TCTNA Method ................................................................................. 36

Introduction........................................................................................................................ 36 The Team/Collective Training Model ................................................................................ 36 The Triangle Model of TNA ............................................................................................... 37
6
6.1 6.2
Constraints Analysis ................................................................................. 41

Introduction........................................................................................................................ 41 Constraints Tables ............................................................................................................ 41
7
7.1 7.2
Team/Collective Task Analysis................................................................. 43

Introduction........................................................................................................................ 43 External Task Context Description .................................................................................... 43 7.2.1 Generic Task Scenarios ......................................................................................... 43 7.2.2 Team Context Diagrams ......................................................................................... 45 7.2.2.1 7.2.2.2 7.2.2.3 Team Context Diagram Notation ................................................................. 45 Interaction Table Construction ..................................................................... 46 Example External Context Description ........................................................ 47
7.2.3 Environment Description Table Construction ......................................................... 50 7.3 Internal Task Context Description ..................................................................................... 53 7.3.1 Organisational Structure ......................................................................................... 53 7.3.2 Role Definitions ....................................................................................................... 54 7.3.3 Internal Team Context Diagram.............................................................................. 56 7.3.4 Team Communication Structure ............................................................................. 58 7.3.4.1 7.3.4.2 7.3.4.3 Communication Diagram ............................................................................. 58 Communications Description ....................................................................... 61 Communications Matrix ............................................................................... 61
iv
7.4
Task Analysis .................................................................................................................... 62 7.4.1 Hierarchical Task Analysis for Team & Collective Training - HTA(TCT) ................ 62 7.4.1.1 7.4.1.2 7.4.1.3 7.4.1.4 7.4.1.5 HTA(TCT) Diagram Notation and Format ................................................... 62 Example HTA (TCT) Diagram ...................................................................... 64 Task Sequence Diagrams............................................................................ 66 HTA(TCT) Task Description Tables............................................................. 67 Task Role Matrix .......................................................................................... 72
7.5 7.6
Capture Environmental Task Demands ............................................................................ 73 Teamwork Analysis ........................................................................................................... 74 7.6.1 Teamwork Process Priorities .................................................................................. 74 7.6.2 Teamwork Interaction Analysis by Role ................................................................. 74
7.7
Training Gap Analysis ....................................................................................................... 75 7.7.1 The Risk Management Approach ........................................................................... 76 7.7.2 The Training Priorities Table ................................................................................... 76
7.8
Team/Collective OPS and TO Development .................................................................... 80 7.8.1 Linking Tasks and Training Objectives to Mission Task Lists ................................ 80
8
8.1 8.2
Training Overlay Analysis ......................................................................... 83

Introduction........................................................................................................................ 83 Instructional Theory ........................................................................................................... 83 8.2.1 Clarks Content-Performance Matrix (Clark, 2008) ................................................ 83 8.2.2 Part-task training ..................................................................................................... 85 8.2.3 Reigeluths Simplifying Conditions Method (Reigeluth, 1999) ................................ 85 8.2.4 Team Training Methods .......................................................................................... 86 8.2.5 The Relationship between Tasks and the Operational Environment ..................... 87
8.3
Instructional Method Selection .......................................................................................... 88 8.3.1 Selecting Methods for Initial Instruction .................................................................. 88 8.3.2 Selecting Methods for Practice and Assessment ................................................... 90 8.3.2.1 8.3.2.2 8.3.2.3 8.3.2.4 Identification of Part-Task Training Requirements ...................................... 90 Identification of Simplifying Conditions Method Requirements.................... 91 Assessment and Feedback Methods........................................................... 91 Practice and Assessment Methods Table ................................................... 92
8.3.3 Training Scenario Specification .............................................................................. 94 8.4 Instructional Task Identification ......................................................................................... 97 8.4.1 Instructor Task Table .............................................................................................. 97 8.4.2 Training Overlay Requirement Specification .......................................................... 98
9
9.1 9.2
Training Environment Analysis ............................................................... 100

Introduction...................................................................................................................... 100 Training Environment Specification ................................................................................ 100 9.2.1 Training Environment Rationalisation ................................................................... 100 9.2.2 Fidelity Analysis .................................................................................................... 102 9.2.2.1 Specifying Fidelity Requirements .............................................................. 102 9.2.2.1.1 9.2.2.1.2 9.2.2.1.3 9.2.2.1.4 9.2.2.1.5 9.2.2.1.6 System Fidelity Requirements ................................................. 103 Resource Fidelity Requirements ............................................. 104 Human Element Fidelity Requirements ................................... 104 Manned Systems Fidelity Requirements ................................. 105 Physical Environment Elements .............................................. 106 Recording Element Fidelity Specifications .............................. 106
9.3 9.4 9.5
Training Environment Option Identification ..................................................................... 108 Training Environment Option Definition .......................................................................... 110 Training Environment Option Evaluation ........................................................................ 113
10
Training Options Evaluation ................................................................... 114
10.1 Introduction...................................................................................................................... 114 10.2 Estimation of Costs ......................................................................................................... 114 10.3 Estimating Effectiveness ................................................................................................. 114 10.4 JSP 822 Guidance .......................................................................................................... 114
11
Conclusions and Recommendations ...................................................... 115
11.1 Conclusions ..................................................................................................................... 115 11.2 Recommendations .......................................................................................................... 116
12
References ............................................................................................. 117 Teamwork Models................................................................. 120
Appendix A
A.1 A.2 A.3 A.4 A.5
Team Process Model (Annett, 2000) .............................................................................. 120 Team Coordination Dimensions (Bowers et al, 1993) .................................................... 121 The Models for Analysis of Team Training Taxonomy (Dstl, 2006) ................................ 122 Salas Big Five Model of Teamwork (Salas et al, 2005) ................................................ 124 Teamwork Behaviours (Rousseau et al, 2006) ............................................................... 125
vi
List of Tables
Table 1 Teamwork Models used in Teamwork Analysis .......................................................................... 12 Table 2 Integrative Teamwork Models...................................................................................................... 13 Table 3 Initial Teamwork Categories ........................................................................................................ 16 Table 4 TCTNA Teamwork Taxonomy ................................................................................................... 18 Table 5 Work Domain Analysis Abstraction Hierarchy (Naikar and Sanderson, 1999)........................... 33 Table 6 MATT Process Stages (Dstl, 2006) .............................................................................................. 34 Table 7 TNA Triangle Stage Sub-Components ......................................................................................... 38 Table 8 Example Constraints Table Format .............................................................................................. 42 Table 9 Generic Scenario Table Format .................................................................................................... 44 Table 10 Completed Generic Scenario Table ........................................................................................... 44 Table 11 Interaction Table Format ............................................................................................................ 47 Table 12 Example Tornado F3 Pair External Context Interaction Table .................................................. 49 Table 13 Environment Description Table Format ..................................................................................... 50 Table 14 Example Tornado F3 Pair Environment Description Table ....................................................... 52 Table 15 Example Role Definition for the F3 Pair Lead WSO ................................................................. 55 Table 16 Example Role Definition for the F3 Pair Wingman WSO ........................................................ 55 Table 17 Example Tornado F3 Pair Interface Interaction Table ............................................................... 57 Table 18 Tornado F3 Pair Environment Description Table Entries .......................................................... 57 Table 19 Example System Matrix ............................................................................................................. 58 Table 20 Example Tornado F3 Pair Communications Matrix................................................................... 60 Table 21 HTA(TCT) Diagram Element Symbols and Descriptions.......................................................... 63 Table 22 Syntax for plans and examples of use ........................................................................................ 64 Table 23 Task Sequence Diagram Notation .............................................................................................. 66 Table 24 HTA(TCT) Task Description Table Structure............................................................................ 68 Table 25 Task Description Table for F3 Pair Task 1.2.5 Meld Radar....................................................... 70 Table 26 Task Description Table for F3 Pair Task 1.2 Detect Bandit BVR ............................................. 71 Table 27 Task and Role Matrix Example .................................................................................................. 72 Table 28 Example Environmental Task Demands Table .......................................................................... 73 Table 29 Example Teamwork Process Priority Table ............................................................................... 74 Table 30 Teamwork Interaction Table ...................................................................................................... 75 Table 31 Example Training Priorities Table ............................................................................................. 78 Table 32 Factors Affecting the Likelihood of an Error and Indicators of High Severity Consequences ............................................................................................................................................ 79 Table 33 Training Content Performance Matrix with Application Level Elaboration Strategies, adapted from Clark (2008)......................................................................................................................... 84 Table 34 Suggested Content for Initial Instruction on Teamwork ............................................................ 89 Table 35 Example Initial Instruction Table for F3 Pairs Training ............................................................ 90 Table 36 Example Practise and Assessment Methods Table..................................................................... 93 Table 37 Example Training Scenario Table .............................................................................................. 95 Table 38 Environment Description Table Entries for Task Scenario Requirements................................. 96 Table 39 Example Instructor Task Table Format and Entries ................................................................... 98
vii
Table 40 Environment Description Table Training Overlay Requirements Entries ................................. 99 Table 41 System Fidelity Requirements .................................................................................................. 103 Table 42 Resource Fidelity Requirements ............................................................................................... 104 Table 43 Human Fidelity Requirements .................................................................................................. 105 Table 44 Manned Systems Fidelity Requirements .................................................................................. 105 Table 45 Physical Environment Fidelity Requirements .......................................................................... 106 Table 46 Tornado F3 Pair Environment Description Table .................................................................... 107 Table 47 Example Training Environment Option Description Table ..................................................... 111 Table 48 Example Training Environment Option Properties Table Entries............................................ 112 Table 49 Training Environment Options Comparisons Table ................................................................. 113 Table 50 Definitions of Team Coordination Dimensions (Bowers et al, 1993), ..................................... 121 Table 51 MATT Teamwork Behaviours (Dstl, 2006) ............................................................................. 122 Table 52 MATT Team Member Attitudes and Characteristics (Dstl, 2006) ........................................... 123 Table 53 MATT Teamwork Knowledge Requirements (Dstl, 2006) ...................................................... 123 Table 54 Definitions of the Core Components and Coordinating Mechanisms of the Big Five Model of Teamwork (adapted from Salas et al, 2005) ............................................................................ 124 Table 55 Teamwork Behaviours (Rousseau et al, 2006) ......................................................................... 125
viii
List of Figures
Figure 1 The Systems Approach to Training ............................................................................................... 4 Figure 2 MoD TNA Process Diagram (JSP822, 2007) ............................................................................... 7 Figure 3 TCTNA Development Sequence ................................................................................................... 8 Figure 4 Patterns of Team Interactions adapted from Tesluk et al (1997) ................................................ 10 Figure 5 Input-Process-Output (IPO) paradigm for analysis of group interaction as a mediator of performance outcomes (Hackman and Morris, 1975) ............................................................................... 19 Figure 6 Model of Team Effectiveness adapted from Tannenbaum, Beard and Salas (1992) .................. 20 Figure 7 The Command Team Effectiveness Model with Basic Components and Feedback Loops (NATO, 2005)............................................................................................................................................ 21 Figure 8 Information Transduction Model of Group Activity on the Task Environment (Roby, 1968) .......................................................................................................................................................... 22 Figure 9 Properties of Naturalistic Environments, Environmental Stressors and Environmental Task Demands............................................................................................................................................ 24 Figure 10 The Team/Collective Performance Model ................................................................................ 25 Figure 11 Team Training Cycle, adapted from Tannenbaum et al (1998) ................................................ 28 Figure 12 The Team/Collective Training Model ....................................................................................... 29 Figure 13 Example HTA (T) Chart............................................................................................................ 31 Figure 14 The Team/Collective Training Model ....................................................................................... 36 Figure 15 The Triangle Model of TNA ..................................................................................................... 37 Figure 16 Team Context Diagram Notation .............................................................................................. 45 Figure 17 Example Tornado F3 Pair External Environment TCD ............................................................ 48 Figure 18 Example Tornado F3 Pair Organisational Chart 1 .................................................................... 54 Figure 19 Example Tornado F3 Pair Interfaces TCD ................................................................................ 56 Figure 20 Example Tornado F3 pair Communications Diagram and Textual Description ....................... 60 Figure 21 HTA Diagram Format ............................................................................................................... 63 Figure 22 Example HTA for the F3 Pair Task Destroy Bandit beyond Visual Range .............................. 65 Figure 23 Task Sequence Diagram Format ............................................................................................... 67 Figure 24 Task Sequence Diagram for the F3 Pair Task 1 Destroy Bandit BVR ..................................... 67 Figure 25 Task Sequence Diagram for the F3 Pair Sub-Task 1.2 Detect Bandit BVR ............................. 67 Figure 26 General mapping of Tasks to METs ......................................................................................... 81 Figure 27 Mapping of Example ATC Role Group Summary Tasks to Military Tasks in the MTL(M) ..................................................................................................................................................... 82 Figure 28 Part Task Training Sequence (adapted from Wickens and Hollands, 2000) ............................ 85 Figure 29 Simplifying Conditions Method Training Sequence (Adapted from Reigeluth, 1999) ............ 86 Figure 30 Mapping of TOs to the Operational Environment .................................................................... 88 Figure 31 Information Inputs to Generic Scenario Specifications ............................................................ 94 Figure 32 Mapping of TOs to Training Environments ............................................................................ 101 Figure 33 JOUST Networked Flight Simulation System ........................................................................ 110 Figure 34 Team Process Model (adapted from Annett, 2000) ................................................................ 120
ix
List of Acronyms
ACM ATC BATUS BVR Cap JTES CAST CATT CDM CF CONOPS CONEMP CONUSE CTEF CWA DSAT Dstl ECG EDT FC HF HFI DTC HTA HTA(T) HTA(TCT) IPO JTIDS JSP KSAs MATT MCC MECs MSHATF Air Combat Manoeuvring Air Traffic Control British Army Training Unit Suffield Beyond Visual Range Capability Joint Training Experimentation and Simulation Combined And Staff Trainer Combined Arms Tactical Trainer Critical Decision Method Competency Framework Concept of Operations Concept of Employment Concept of Use Command Team Effectiveness Cognitive Work Analysis Defence Systems approach to Training Defence science and technology laboratory Electrocardiograms Environment Description Table Fighter Control Human Factors Human Factors Integration Defence Technology Centre Hierarchical Task Analysis Hierarchical Task Analysis (Teams) Hierarchical Task Analysis for Team and Collective Training Input Process Output Joint Tactical Information Distribution System Joint Service Publication Knowledge, Skills and Attitudes Models for Analysis of Team Training Maritime Component Command Mission Essential Competencies Medium Support Helicopter Aircrew Training Facility
MTL(M) MTDS MoD NATO OTA OTI PPE RAF RN RWR SA SAT SCM SME TCD TCTNA TES TO TNA TTA TTRAM UHF US USAF VHF WDA WSO
Military Task List (Maritime) Mission Training through Distributed Simulation Minstry of Defence North Atlantic Treaty Organisation Operational Task Analysis Operation Task Inventory Post Project Evaluation Royal Air Force Royal Navy Radar Warning Receiver Situation Awareness Systems Approach to Training Simplifying Conditions Method Subject Matter Experts Team Context Diagram Team/Collective Training Needs Analysis Tactical Engagement Simulation Training Objective Training Needs Analysis Team Task Analysis Task and Training Requirements Analysis Methodology Ultra High Frequency United States United States Air Force Very High Frequency Work Domain Analysis Weapons Systems Operator
RHWRRadar Homing & Warning Receiver
xi
1 Executive Summary
The research project described in this report was devised in response to a Royal Navy request for the Human Factors Integration Defence Technology Centre (HFI DTC) to provide guidance on the conduct of Training Needs Analysis (TNA) for Collective Training to support the TNA process being conducted for the Queen Elizabeth (QE) Class Aircraft Carriers. TNA is the systematic process of analysing training tasks and identifying suitable training option(s) that has been used in connection with acquisition projects for many years, however traditionally it has been focussed on individual training. The inherent complexity and scale of collective training puts it beyond the analytical reach of the techniques normally employed for individual training. Due to anomalies in how the three Services define team and collective training, the method developed is referred to as Team/Collective TNA (TCTNA) to make it clear that is applicable to both team and collective training however they may be defined. The TCTNA guidance provided in this document is designed to extend and amplify the extant guidance on TNA provided in JSP 822, not to replace it. In order to develop a TNA methodology, it was necessary to develop a model of collective training. This necessitated the development of an underlying model of team performance and supporting teamwork taxonomy. A review of extant teamwork and team performance models was conducted and, in the absence of suitable extant models being identified, a model of team performance and supporting teamwork taxonomy suitable for TCTNA were synthesised. A review of extant human factors methods devised to facilitate the analysis of team training was conducted. Of the relatively small number of models in existence, none were found to provide all of the analytical components required to support TCTNA, confirming that a new model had to be developed. The TCTNA method that has been devised is structured around an adaptation of the TNA Triangle model devised in a previous phase of HFI DTC research (HFI DTC, 2009). It is composed of five components: Constraints analysis, Team/Collective Task Analysis, Training Overlay Analysis, Training Environment Analysis and Training Option(s) Selection. Constraints Analysis provides a mechanism for the recording of all key constraints and analysis of their consequences in terms of limitations on potential training solutions. Team/Collective Task Analysis exploits adaptations of software design representational techniques to develop visual representations of the nature of the task environment. An extension of Hierarchical Task Analysis for Teams (developed under a previous Ministry of Defence (MoD) contract) is then employed as the core task analysis method. The teamwork taxonomy developed as part of the research is used to guide the analysis of the teamwork component of the task. Finally, training priorities are established using a risk management approach. During Training Overlay Analysis appropriate instructional methods are determined and generic scenarios are developed which are used to inform subsequent training
environment specification. Instructor functions are specified as are the requirements for data capture from the instructional environment. During Training Environment Analysis the training environment requirements are first rationalised and then a fidelity analysis is conducted for each environment required. Novel fidelity analysis templates are provided for specifying each of the manned systems, human elements, resources, systems and physical environment elements that are required within each training environment. Training environment options are then identified and characterised and technical suitability is assessed. Outline guidance on Training Option Selection is provided, with reference being made to the JSP 822 direction on seeking advice from MoD and industry for the costing and comparison of complex training systems. This research has delivered a methodology for the conduct of TCTNA. Worked examples and templates are provided for the components of each stage of the methodology. It is anticipated that this guidance will be used by military and commercial TNA specialists conducting TCTNA.
2 Introduction
2.1 Background
The requirement for this work originated in a request from the RN for the development of a methodological approach for the conduct of Training Needs Analysis (TNA) which could be applied in a set of TNAs to be conducted for collective training for the Queen Elizabeth Class Aircraft Carriers. The principal differences between individual training and team and collective training are associated both with scale and complexity. The issues include: Complexity of the task Complexity of the context in which the task is conducted Complexity of the start state of the training audience Complexity of exercise planning Complexity of the instructional task Complexity of evaluation Scale of resource requirements Costs of training
A TNA method for Team and Collective Tasks must be theoretically capable of covering any type of Collective Task from the smallest and simplest (two people working together) to large complex tasks that span multiple teams and organisations and involve integration of effort between them (such as ground-air integration in warfare). The experience of the Royal Navy (RN) TNA specialists was that, whilst the overarching approach to TNA mandated in Joint Service Publication (JSP) 822 was logical and applicable to collective training, there was an absence of appropriate guidance on techniques to deal with the complexities of the collective training problem. The purpose of this report is to fill this methodological gap.
2.2 Scope of Team/Collective Training Needs Analysis

The term collective training is often used differently by the three services. The RN uses the term to characterise training for individual units and multiple units or force elements. The Royal Air Force (RAF) considers collective training to be that which encompasses multiple aircraft types, with training for a single aircraft type being referred to as team training. The Army uses a six-level description to characterise the progression of training
from individual level up to Battle group and beyond, referring to these as collective training levels 1-6. The North Atlantic Treaty Organisation (NATO) definition of Collective training cited in NATO (2004) describes collective training as training which: involves 2 or more teams, where each team fulfils different roles, training in an environment defined by a common set of collective training objectives (CTOs) (p6.2) Given that the requirement for this work was to develop a methodological approach applicable to support TNA for the training of individual teams and collective training, and that there is the potential for confusion about the applicability of the method if it is simply labelled Collective TNA, the method described is referred to in this document as Team/Collective TNA (TCTNA) and is applicable to all levels of training above individual training.
2.3 Training Needs Analysis

Military training in the UK has been developed and managed following the principles of the Systems Approach to Training (SAT) with some success for many decades. The SAT approach in its simplest from is illustrated in Figure 1. The first stage is the analysis and definition of the training requirement. Training design follows on and embraces both the high level training strategy and the detailed design of training materials. Training delivery then takes place and is followed by evaluation. The results of evaluation are then fed back so that adjustments can be made to the analysis, design and delivery to ensure that optimal training is delivered and any weaknesses are corrected. Historically, the three services each had their own implementation of SAT and a set of associated documents defining the approach. This was rationalised with the publication of the Defence Systems Approach to Training (DSAT) Quality Standard in 2003.
Figure 1 The Systems Approach to Training
Notwithstanding the success of the application of SAT to the development and management of training within the RN, the Army and the RAF, for many years the development of training associated with the acquisition of new systems fell outside the scope of the SAT process of each individual Service. The TNA process was developed to provide guidance on the application of the principles of SAT to training developed within the acquisition process. The scope of TNA is illustrated by the red overlay in Figure 1. It embraces the analysis phase and sufficient high level design to facilitate the identification of a recommended training solution. In 1996 the Department of Internal Audit endorsed a common approach to TNA across the three services, achieved by the publication of JSP 502 TNA for Acquisition Projects. The output of the TNA is a document set that forms the inputs for subsequent stages of the instructional design process - such as specification of training equipment, development of lesson content and training material and training implementation, assessment and evaluation strategies. Historically, SAT and subsequently DSAT have only applied to individual training. Significantly, with the integration of DSAT and JSP502 into JSP 822 in 2007, the need to consider collective training requirements is specifically mentioned within the guidance on TNA (JSP 822). The current MoD TNA process is shown diagrammatically in Figure 2 TNA is conducted in three phases: Phase 1 - Scoping Study. The Scoping Study defines how the TNA is to be conducted and managed and identifies the constraints, assumptions and risks associated with the project. It also includes a target audience description which characterises who will need training, the annual throughput and the input standard. Phase 2 TNA Development. The TNA development constitutes the core of the analytical activity of the TNA and yields four key deliverables. These are: 1. Operational/Business Task Analysis (OTA). This deliverable reports the outcome of a task analysis to establish the performance conditions and standards for all affected job holders. It includes an Operational Task Inventory (OTI) with associated performance conditions and standards statements. It is recommended that the OTI is rationalized using a process such as Difficulty Importance Frequency (DIF) analysis. Notably, it identifies the requirement to identify interfaces between individuals and teams to include co-ordination, communication and backup activities, noting that they form a vital part of sub-team and command team training. 2. Training Gap Analysis. The purpose of this deliverable is to determine the additional training required to meet the gap between the performance level required as defined by the OTA and the existing performance level of individuals. Specific mention of unit and collective training requirements is required. A fidelity analysis is also required to identify the key cues and stimuli that support the requirement to train (Sect 2.30. The conduct of the fidelity analysis can continue into the next phase but has to be completed before method and media selection takes place.
3. Training Options Analysis. The purpose of this deliverable is to make a recommendation as to cost effective training solution(s) to meet the training requirement identified in the previous phases of the TNA. This includes a description of the training methods and media (or combinations thereof) that will partially or fully meet the training requirement along with an estimate of the relative training effectiveness of each costed training media option. 4. The Final Report. The final report draws together all the key elements from the previous phases of analysis. The output from this deliverable is an endorsed training solution, draft Operational performance Statement/Competency Framework, implementation plan and an evaluation strategy. If the final report is accepted the next stage of the process is the development of the training course and any required training devices. These may be partly or wholly contracted out. If the final report is not accepted then some or all of the analysis process will have to be repeated. The branching path in Figure 2 from the Final Report reflects these options. Phase 3 Post Project Evaluation. The Post Project Evaluation (PPE) should be conducted once training delivery and evaluation has commenced and reviews the effectiveness of the TNA process for the project. Historically, relatively few projects have had a PPE. The guidance for the conduct of the Phase 1 Scoping Study is comprehensive and does not appear to require any adaptation for team/collective training. Similarly, the Phase 3 PPE guidance is robust and applicable to any TNA. However, whilst the Phase 2 TNA Development guidance mentions the requirement to address team and collective training and highlights the requirement to capture communication, coordination and backup activities, there is no detailed guidance on how to apply the overall approach to this complex domain. Therefore, the requirement identified for this study was to develop an approach for Phase 2 TNA Development that addressed the complexities of team and collective training, and provided guidance in sufficient detail for the approach to be implemented.
RESPONSIBILITIES
Project sponsor to Contact Lead Training Authority MOD TNA steering group Phase 1 TNA Scoping Study
MOD or Contractor
Phase 2 TNA Development Operational/business Task Analysis OPS/CF Statement Deliverable 1
Training Gap Analysis
Training Objectives Deliverable 2
Training Options Analysis
Recommended Training Solution Deliverable 3
TNA Final Report Deliverable 4 No No Can trg equipment contract be awarded? Yes
Can trg design begin?
Yes Training Design & Development Training Equipment Design & Development Ready for Trg Date (RFTD)
Relevant Agencies
Other SAT Elements
Training Delivery
Training Evaluation
Training Authority
Phase 3 TNA Post Project Evaluation
Figure 2 MoD TNA Process Diagram (JSP822, 2007)
2.4 Methodological Approach

The TCTNA method was developed in four stages as illustrated in Figure 3. Firstly, a model of team/collective training was developed in order to provide a framework for analysis of team/collective tasks from a training perspective. A review of extant HF methods applicable to TCTNA was then conducted to determine if there was an extant method that would satisfy the analytical requirements of the team/collective training model or, if not, which extant methods would inform the development of a new model. A theoretical TCTNA model was then developed. Finally, the theoretical model was instantiated into a practical model with detailed implementation guidance.
Figure 3 TCTNA Development Sequence
3 The Team/Collective Training Model

3.1 Introduction
Successful TNA is founded upon a clear, robust analysis of the task to be performed, a considered evaluation of appropriate training strategies and instructor roles and a clear specification of appropriate training environments. Given the inherent complexities of team-collective tasks, the teamwork which underpins them, and the training methods and resources that are required to deliver training for them, it is necessary to develop a model of team training to guide the analysis. This has to be underpinned by appropriate models of teamwork and team-collective task performance. After first setting out some key definitions used in this report, a teamwork taxonomy is developed which is then integrated into a model of team/collective performance. Finally, a team training model is developed by the integration of a model of instructional functions and supporting system requirements.
3.2 Definitions
The teamwork literature suffers from the use of a multiplicity of definitions for commonly used terms such as team and teamwork. Furthermore, the definitions themselves often manifest a confusion of team member attributes, interactions, processes, functions, strategies, behaviours and products. For example, Nieva et al (1978), defined a team as: two or more interdependent individuals performing coordinated tasks towards the achievement of specific task goals whereas Salas et al (1992) defined a team as two or more individuals, who have specific roles, perform interdependent tasks, are adaptable and share a common goal In the Salas et al. (1992) definition, a team is defined as being adaptable and sharing a common goal. In a poorly performing team, team members may not necessarily be adaptable (or want to be adaptable) and may not necessarily share a common goal which is why inadequate conflict resolution is quoted as a factor in poor teamwork (Baker, Day and Salas, 2006). For the sake of clarity, the following definitions are used in this report: Team: a number of persons constituting a work group, assembled together for the purpose of joint action. Teamwork: the interactions and processes that occur between team members in response to environmental demands to help achieve the generation of team-collective task products.
Teamwork Interaction: a single instance of one team member causing an effect on another team member; actions that connect team members. Teamwork Process: a systematic series of coupled team member interactions directed to some end. Teamwork Competencies: the supporting Knowledge Skills and Attitudes (KSAs) that support teamwork directly. Collective Task: a task involving (most usually requiring) the performance of more than one individual in a work group; the performance of joint action between team members to a shared goal, generating a task product with specified value measures which may be evaluated in performance assessment. Joint action may be parallel (not dependant) or highly interdependent.
3.3 Development of a Teamwork Taxonomy

In order to meet the requirement for the provision of a teamwork taxonomy to be used to underpin a teamwork performance model, a number of contemporary teamwork models were reviewed to identify if a suitable taxonomy already existed. As no single model was considered adequate, a new model was synthesised from the models reviewed.
3.3.1 Review of Extant Teamwork Models

In a recent study, Salas, Sims and Burke (2005) identified 138 teamwork models that had been published in the previous 20 years. Conducting a full review of the extant teamwork models would have been a substantial undertaking. A full review was untenable in the timeframe of this study, so a more pragmatic approach needed to be adopted. A survey of the team training literature revealed that four teamwork models were used in the published methods related to the analysis of team training (Tesluk, Mathieu, Zaccaro & Marks, 1997; Annett, 2000; Bowers et al, 1993; DSTL, 2006). Furthermore, there had been two recent, meta-analytic studies of teamwork models (Salas et al, 2005; Rousseau, Aube and Savoie, 2006) which yielded integrative models of teamwork. Therefore, the initial review was focussed on these six models. The model put forward by Tesluk, Mathieu and Zaccaro (1997), was used by Arthur, Edwards, Bell, Villado and Bennett (2005) in their Team Task Analysis approach to identify tasks that were team-based. The model provides descriptions of generic patterns of workflow or teamwork interactions within teams as shown in Figure 4
Figure 4 Patterns of Team Interactions adapted from Tesluk et al (1997)
10
Whilst these patterns are of interest in that they facilitate characterisation of the dynamics of a team task in terms of interaction pattern, the model is of limited value from a TNA perspective, as an understanding of the nature of the interactions and the processes that they support is required in order to devise a training strategy and determine a suitable training environment. The remaining models identified provide detailed breakdowns of teamwork. These are summarised in Table 1 and Table 2. The full models are provided in Appendix A.
11
Table 1 Teamwork Models used in Teamwork Analysis

Annett (1997) Behavioural Processes Communication (send, receive, discuss) Coordination (Collaborate, synchronise, discuss) Cognitive Processes People, Team Plan & World models Affective Processes Morale Cohesiveness Bowers et al (1993) Communication (send, receive, acknowledge) Situational Awareness (identify souce / nature of problems, perception of location, detect situations requiring action) Decision Making (gather info required, identifying solutions to problems,evaluating consequences of alternatives, select best alternative) Mission analysis (monitoring, allocating & coord of people and resources, prioritising tasks, setting goals, developing plans, creating contingency plans) Leadership (directing others,monitoring and assessing performance, motivating,communication of mission requirements) Adaptability (alter course of action, maintain behaviour under pressure, adapt to internal or external changes) Assertiveness (willingness to make decisions, demonstrating intiative, maintian own position until convinced otherwise) Total Coordination Need for interaction and coordination DSTL(2006) Communication Behaviours Information Exchange (seek and pass relevant and timely) Communication Skills (use of formats & conventions) Co-ordination Behaviours Procedural Co-ordination (integration and sync iaw procedures) Collaboration (organising team resources, activities and actions tasks shared and completed on time) Leadership and Task Management (directing, coordinating team activities) Adaptive Behaviours Situation Assessment (develop common understanding of the situation) Decision Making (assessment of situation, choice of course of action through discussion and argument) Back-up Behaviours Performance Monitoring and Feedback (monitoring performance of teammates, providing advice, giving and receiving feedback) Mutual Support (providing assistance to team members) Attitudes Mutual Trust Shared Vision Team Orientation Collective Efficacy Knowledge Shared Task Models Accurate Problem Models Team Role Interaction Patterns Team Member Characteristics Task Sequencing Cue-Strategy Associations Teamwork skills Team Mission, Objectives and Resources Boundary Spanning Roles
12
Table 2 Integrative Teamwork Models

Salas Big Five (2005) Core Components: Team leadership (Direct & coordinate activities, assess team performance, assign tasks, develop team KSAs, motivate team, plan, organise, establish positive atmosphere) Mutual Performance Monitoring (monitor performance using appropriate strategy, develop common understandings of environment) Backup behaviour (anticipate other team members needs through knowledge of responsibilities, shift workload to achieve balance) Adaptability (alter course of action in response to conditions, use backup behaviour & reallocation of resources to adjust strategies) Team orientation (take others behaviour into account, belief in importance of team over individual goals) Coordinating Mechanisms: Shared mental models (relationships between tasks and how team will interact) Mutual trust (shared belief team members will perform roles and protect interests of team mates) Closed-loop communication Exchange of information Rousseau (2006) Preparation of work accomplishment Team Mission Analysis (identification of main tasks, environmental conditions and team resources available) Goal Specification Planning (Development of alternative courses of action) Work Assessment Behaviours Performance monitoring Systems monitoring (tracking team resources and state of environment) Task-related collaboration behaviours Coordination (integrating activities ref time) Cooperation (working together) Information Exchange Team Adjustment Behaviours Backing up Behaviours (providing task related help) Inter-team Coaching (feedback on task performance and behaviour) Collaborative Problem Solving (gathering information, identifying alternatives, select best solution, decision making, implementing solution) Team Practice Innovation (Invent and implement new ways of doing) Management of Team Maintenance Psychological Support (assistance to team mates) Integrative Conflict Management (resolution of conflicts tasks processes and interpersonal issues)
13
Annett (1997) proposed his teamwork model, shown in the first column of Table 1 as the theoretical framework for teamwork upon which his Hierarchical Task Analysis for Teams (HTA(T)) method was based. The cognitive process components are described as being the knowledge or beliefs that team members hold of the problem (world model), the what other team members are doing or capable of doing (people model) and the team plan. Arguably they might be better described as knowledge components rather than cognitive processes. Annett (1997) observes that affective components such as morale and cohesiveness, whilst regarded as important by many, are problematic as it is unknown if they are a cause of team behaviour, but suggests they should be incorporated for completeness. The application of this model in HTA(T) manifests as the capture of descriptions of teamwork requirements for goals and sub-goals in terms of the communication and co-ordination requirements. Bowers, Morgan, Salas and Prince (1993) devised a teamwork model which they used as the basis for a questionnaire to assess coordination demands in flight tasks in order to inform the further development of aircrew co-ordination training. The eight dimensions of their model are shown in the second column of Table 50. This model has many more processes than the Annett model but does not consider affective or cognitive elements. The Dstl (2006) model, shown in the third column of Table 2, was designed to underpin the Models for Analysis of Team Training (MATT) approach to the development of team training. It is notable in that it provides a much more extensive list of underpinning knowledge and affective elements than the other models, although the definitions of the affective elements appear to overlap. The Salas et al (2005) model, shown in the first column of Table 2 is structured differently from all the other models in that it is split into five core components of team work and three coordinating mechanisms. This model was developed on the basis of the analysis of twenty selected teamwork models. The Rousseau et al (2006) model, shown in the second column of Table 2 was developed on the basis of the analysis of twenty nine teamwork models. A notable difference between this model and the Salas et al model is that leadership is specifically excluded from the list of behaviours considered although a detailed reason for its exclusion is not offered. It is also the only model that includes conflict management as a teamwork behaviour. When all five models are compared, there are only two categories of behaviour, communication and coordination, which are common to all. Furthermore, in a number of instances behaviours with the same name are defined in different ways. For example, Rousseau et al (2006) define mission analysis as being concerned with the identification of tasks, environmental conditions and the team resources available for utilisation in undertaking the task, whereas Bowers et al (1993) include the development of plans and the allocation of people and resources to task. In addition, the similar sets of behaviours in different models are given different labels. For example, Rousseau et al (2006) use the term intra-team coaching as the label for the provision of feedback and distinguish it from backup behaviour, whereas it is explicitly labelled as feedback in the backup behaviours category in the DstlDstl (2006) model. Even the category of coordination, which is common to all of the models, is defined differently in every model.
14
Given the lack of standardisation of terms, the differences of scope of each model, and the fact that all of the models contained unique categories, there was no one model that was an obvious candidate to be used to underpin the analysis of teamwork for TCTNA. Therefore it was considered that a synthesis of the models was required.
3.3.2 Synthesis of a Teamwork Taxonomy

The six teamwork models reviewed in the previous section were used to synthesise a teamwork taxonomy using a grounded theory approach. A grounded theory approach was adopted as described by Strauss and Corbin (1990) using the implementation approach described by Huddlestone and Harris (2003). This was comprised of three main stages of analysis, open coding, axial coding and selective coding. Open coding was comprised of breaking down the data using a line by line analysis technique of the descriptions of the categories in each model (Strauss and Corbin, 1990), and then categorising them using a constant comparison technique as described by Partington (2000). This was followed by axial coding where connections between the categories were identified to form higher order categories. Then, selective coding was applied to identify the overarching category. Finally, to triangulate the analysis, a second coder used the hierarchical categories derived to re-categorise the data and any anomalies were discussed and resolved. 3.3.2.1 Results 3.3.2.1.1 Initial Coding The results of the initial application of open, axial and selective coding are shown in Table 3. Open coding initially yielded thirty two categories, including the decomposition of leadership and collaborative problem solving into subcomponents. During axial coding, leadership and collaborative problem solving were categories containing multiple elements, with teamwork KSAs, teamwork supporting processes, teamwork processes and team attributes identified as higher order organising categories. The unifying theme identified by selective coding was labelled as teamwork, which captured the notion of cooperation as an overarching descriptor of participation in teamwork. Triangulation of the data analysis identified four key areas of difference concerning leadership, situational awareness, task allocation and resource allocation. These are considered in turn. 3.3.2.1.1.1 Leadership Two issues were identified with leadership as a category. Firstly, there was overlap with other categories (for example, performance monitoring occurs as a separate element as well as a sub component of leadership). Secondly, there was the issue as to whether leadership is best considered as a role or a teamwork function. In the military context, all teams have appointed leaders who have specific responsibilities for task achievement, maintenance and development of the team and the development of individuals.
15
Table 3 Initial Teamwork Categories

Teamwork Teamwork Knowledge Skills and Attitudes (KSAs) Mental models Communication skills Team orientation Mutual trust Teamwork Supporting Processes Communication Performance monitoring Backup behaviour Teamwork Processes Team Attributes Adaptability Cohesion
Leadership Goal specification Planning Task prioritization Task assignment Control Coordination Monitoring Team Performance Performance assessment Motivating Team Creating positive atmosphere Situational awareness Task coordination Workload management Information coordination Resource coordination Collaborative problem solving Gathering required information Identifying potential solutions Evaluating alternative solutions Forming consensus on best alternative Collaborative planning Conflict management Task allocation Resource allocation
Adair (1997) identifies eight leadership functions: defining the task, planning, briefing, controlling, evaluating, motivating, organising and providing an example. These functions are identified as part of his action centred leadership model, which is commonly taught during leadership training in the British Armed Forces. The view was taken that whilst leadership is a role with responsibilities for ensuring that effective teamwork is taking place in order to secure task delivery, the role is greater than simply being a teamwork process. Therefore, leadership was removed from the teamwork process list.
16
3.3.2.1.1.2 Situational Awareness Situational awareness was challenged as a category in the light of the most recent HFI DTC research into the concept of Distributed Situational Awareness (DSA) published in Salmon, Stanton, Walker and Jenkins (2009). Salmon et al advance DSA as an alternative view to shared situational awareness (SA) and posit that DSA is a system held construct. They suggest that different individuals with different roles will form different mental models of the situation even if they are presented with the same information, the differences being attributable to their roles. They suggest that what is important is the alignment of their perceptions of the situation where their actions and activities are related. In their DSA model they assert that team attributes such as cohesion and team processes such as communication contribute to the achievement of appropriate DSA but it is not solely a teamwork process. Therefore, situational awareness was discounted as a teamwork process. 3.3.2.1.1.3 Task and Resource Allocation The issue concerning both task allocation and resource allocation were whether they were best considered as processes or interactions. The view that was advanced was that, based on observation of simple instances of teamwork, they should be characterised as interactions. For example, considering the example of two pilots operating an aircraft, the handling pilot may direct the non-handing pilot to take over responsibility for talking on the radio. This was considered to be different to the more extended process of workload management which may result in a revision of task allocations instantiated through a number of task allocation interactions. Similarly, resource allocation such as an infantry section commander directing a member of the section to take six grenades could be considered to be a simple interaction, different in nature to the larger process of resource coordination. Task and resource allocation were therefore re-categorised as teamwork interactions. 3.3.2.2 The Teamwork Taxonomy The final version of the taxonomy, with definitions for each element, is shown in Table 4
17
Table 4 TCTNA Teamwork Taxonomy

Team Attributes Adaptability Cohesion The ability of the team to react to changing circumstances. The degree to which the team actively engages in teamwork behaviour and coordinates its actions. Teamwork Processes Task coordination Workload management Information coordination Ensuring that task elements are synchronised as required. Evaluating the balance of workload across the team and changing task allocations if appropriate to achieve balance. Ensuring that information is passed from the most appropriate source and sent to appropriate destinations answering the questions who has got what we need? and who needs what we have got?. Ensuring that resources are deployed appropriately across the team The collaborative process of gathering required information, identifying potential solutions, evaluating alternative solutions and forming a consensus view (decision) on the best alternative. The collaborative development of plans and contingency plans by means of gathering required information, identifying potential solutions, evaluating alternative solutions, and forming a consensus about the best alternative. Resolving conflicts concerning tasks and interpersonal issues. Teamwork Supporting Processes Communication Performance monitoring Backup behaviour Resource allocation Task allocation Communicating with team members by any means. Monitoring the performance of other team members and assessing whether they need assistance or feedback. Providing advice or assistance with a task to another team member. Providing a resource to another team member. Directing another team member to undertake a task. Teamwork Knowledge Skills and Attitudes (KSAs) Mental models Mental models of the task environment, the team plan for conducting the task, team interaction patterns, team member strengths and weaknesses and how interactions with entities outside the team are managed. Using agreed conventions where appropriate and putting view forward assertively in a group context. Positive view of the value of the team approach and actively participating in teamwork activities. Belief that other team members will fulfil their roles in the interests of the team and task completion.
Resource coordination Collaborative problem solving
Collaborative planning
Conflict management
Communication skills Team orientation Mutual trust
18
3.4 Development of a Team/Collective Performance Model

Following a review of extant team performance models and a consideration of how the environment places demands on the team during task performance, Team/Collective performance model is synthesised.
3.4.1 Review of Team Effectiveness Models

Traditionally, team effectiveness models have focussed on inputs, processes, and outputs and are referred to as Input Process Output (IPO) models. Figure 5 illustrates a typical, traditional IPO model (Hackman and Morris, 1975).
Figure 5 Input-Process-Output (IPO) paradigm for analysis of group interaction as a mediator of performance outcomes (Hackman and Morris, 1975) This model shows that both individual as well as team factors influence team performance. It also identifies the nature of the task and environmental factors as inputs, including stresses imposed by the environment. One issue that was identified by Hackman and Morris (1975) is that there are other types of output apart from performance outcomes, represented in the dashed box in Figure 5. Some of these Other outcomes are in fact input variables, such as group cohesiveness. Outputs can be inputs as part of the group interaction process, this is not a particular surprise to anyone who has worked in a team and had their relationship change with other team members as a result. The lack of the representation of feedback would seem to be a limitation of the model. Later researchers extended the IPO paradigm for team effectiveness by including other sub-categorisations within the input, process and output categories and capture some notion of feedback between inputs and outputs. Figure 6 below shows a later model of team effectiveness, from Tannenbaum, Beard and Salas (1992), which was considered in a recent NATO study (NATO, 2005) to be the most appropriate to command team effectiveness of the models that they reviewed.
19
Figure 6 Model of Team Effectiveness adapted from Tannenbaum, Beard and Salas (1992) Whilst this model captures feedback to some degree, there are a number of surprising features about this model: Team changes and individual changes are not shown as fed back into the individual and team characteristics. Individual characteristics are shown as acting only indirectly through team characteristics on team processes and team performance. Organisational and situational characteristics are shown as somehow influencing the whole of the input, throughput, output process but explicit connections to the individual elements are not made. The work assignment and communications elements in work structure appear to be organisational factors Team norms (in work structure) would appear to be a team characteristic. The throughput component only captures teamwork processes and not taskwork processes.
One of the latest team effectiveness models is the Command Team Effectiveness (CTEF) Model developed by NATO (2005) shown in Figure 7.
20
Figure 7 The Command Team Effectiveness Model with Basic Components and Feedback Loops (NATO, 2005) This model captures both team and task related processes and shows task and team outcomes being fed back to the input conditions. It also illustrates the possibility of organisational learning if an after action review is conducted. The nature of the mission and task are captured as inputs but surprisingly the task environment is not mentioned explicitly. Marks, Mathieu and Zaccaro (2001) deal more explicitly with the notion of individual and team characteristics being both inputs to and products of team processes. They use the term emergent states to characterise the cognitive, motivational and affective states of teams, which they suggest are dynamic in nature and vary as a function of team context, imputs, processes and outputs. On first inspection, the notion of emergent states appears to have some utility from a training perspective, since it focuses attention on team performance as being a function of experience. This is pertinent since training events are designed to deliver experiences from which the team learn and modify their behaviour as required. From this perspective, capturing team emergent states in a team performance model has merit as it would be a component that an instructional team should be monitoring. However, there are certain aspects of the construct which are problematic. The principle issue is that it can be argued that cognitive, motivational and affective states are held at an individual level not at a team level. In the same way that Salmon et al (2009) argue that situational awareness is a function of differing elements of situational awareness being held by individuals and system elements, team properties may be construed as being a function of the state of the individuals that make up the team, each of whom may well be reacting differently at a given instant in time based on the specific experience they are having and their own KSAs and prior experiences. On
21
this basis. it can be argued that it is more useful to apply the concept of emergent states at the individual level within a team performance model. This has the advantage of focussing attention on how the strengths and weaknesses of individuals are contributing to team performance in a dynamic way. One of the few models that captures the notion of the team responding to cues from the environment and taking actions to affect the environment is that of Roby (1968) shown in Figure 8. Whilst the terminology used in the model is relatively unfamiliar, it is in essence presenting a straightforward information processing model cast in group terms.
Figure 8 Information Transduction Model of Group Activity on the Task Environment (Roby, 1968) Based on the analysis of the models reviewed, the following were considered to be the key elements that a team performance should capture: The nature of the environment in which the task is performed, including the demands that it places on the team The nature of the task The nature of the team in terms of its characteristics and organisation The characteristics of the individuals in the team and their emergent states Task and other outcomes The connections between all of the elements, including feedback loops
As none of the models reviewed captured all of these elements completely, a new model had to be developed.
22
3.4.2 Environmental Task Demands

One of the input factors identified that affects team performance is the stress which the environment places on the team. From a training standpoint, these elements of the environment must be accurately captured in order to be able to identify the generic properties of credible scenarios and so specify training environments that are capable of delivering these scenarios. From the literature, there are two relevant models that amplify this concept. Orasanu (1993) characterises naturalistic environments as having the properties shown in the lefthand column of Figure 9. Cannon-Bowers and Salas (1998), based on research experience with the United States (US) Navy, identified a list of stressors shown in the middle column of Figure 9. The lines between the two lists show the mapping between the items in the two lists. One of the notable features of the list of properties of naturalistic environments is that there are multiple items that are strongly related, such as dynamic environments, uncertain environments and shifting goals. By comparison, the items in the environmental stressors list appear to be discrete, self-contained entities. The discrete, self-contained nature of the environmental stressors list makes it a strong candidate to be used within the TCTNA approach as a framework for capturing data about the environment. However, the requirement for two amendments to the list was identified. Firstly, the auditory overload/interference category is explained by CannonBowers and Salas (1998) as capturing the problem experienced by US Navy warfare teams who had multiple radio channels, each used by different functional networks of people at the same time, fed into their headsets, with different channels fed into each ear (this is also the case for RN warfare teams). Whilst this remains a feature in contemporary operations rooms, advances in technology have led to an equivalent problem occurring in the visual domain. Mission support systems now provide chatrooms dedicated to different networks of operators and these chatrooms now take much of the load that the radio channels took previously. Consequently, warfare operators now have to scan multiple chat screens as well as listen to multiple radio channels. Visual overload is therefore identified as an additional category that is required. In a similar vein, the category of high workload/information load merits dividing into high workload and high information load as a consequence in advances in information systems technology. The concept of information overload is of particular concern in the context of operational information management and exploitation (HFI DTC, 2005; HFI DTC, 2007). Therefore this merits consideration as a separate entity from high workload in general. The extended list is shown in the right-hand column in Figure 9. The term, environmental task demands, is used to distinguish the list from the environmental stressors list.
23
Figure 9 Properties of Naturalistic Environments, Environmental Stressors and Environmental Task Demands
3.4.3 The Team/Collective Performance Model

The Team/Collective Performance Model shown in Figure 10 is designed to capture all of the essential elements identified in the previous section. It shows how team processes, influenced by team properties and team member characteristics, enable the team to deliver performance outcomes in order to achieve required changes in the state of the environment and ultimately it is hoped, goal achievement. The performance outcomes can also influence team properties, team member characteristics and the team processes. These elements and interactions are described in detail in the following sections,
24
illustrated using the example of a medical team deployed in a field hospital to give concrete examples of the constructs used.
Figure 10 The Team/Collective Performance Model 3.4.3.1 Task Environment The task environment is composed of the physical environment, human elements, systems, manned systems and resources. Also captured are the environmental task demands that place stress on the team. In the field hospital example the physical environment would include the tents that they work within. Environmental characteristics such as extreme temperature would also fall into this category. Human elements are all the people outside of the team that the team interact with. In the field hospital case this category would include patients and personnel at field dressing stations that they communicate with. Systems are all the elements that have interfaces that the team use and would include medical systems such as Electrocardiograms (ECGs) and ventilators as well as such items as communication systems. Manned systems are those elements external to the team that they interact with. For a field hospital this might include field ambulances and support helicopters providing casualty evacuation. Resources are all the
25
other items that the team use including equipment, such as hospital trolleys and forceps, and consumables such as dressings, drugs and water. Environmental task demands are the factors that in some way stress the team. In the field hospital case these might include high workload due to large numbers of casualties and performance pressure and time pressure caused by a critically ill patient requiring urgent, life-saving treatment. 3.4.3.2 Performance Outcomes Team Processes generate Task Products and Other Outcomes, both of which constitute a modification to the task environment. In the case of a field hospital example the principal task product is successfully treated casualties - this constitutes the achievement of the task goal. Other Outcomes are ancillary modifications to the task environment which are concomitant with task performance (though not necessarily goal achievement) i.e. what changes in the environment as a result of the task being performed which isnt directly goal related. These might include resources used such as bandages, dressings, syringes, units of blood etc, and human elements being affected such as untreated casualties worsening in condition. Other outcomes also include effects on individuals and the team as a whole. These might include team organisation having to be changed because of a team member being injured, team members becoming fatigued, knowledge gained by individuals from experiencing a new situation. Therefore, performance outcomes feed back to team properties and team member characteristics, as well as the environment. 3.4.3.3 Team Processes Team processes are the teams response to the environmental inputs and are composed of both teamwork and taskwork elements. Their purpose is to generate appropriate task outcomes to achieve the required goal. They also have the side effect of generating other outcomes. The connection between team processes and task products is shown as twoway, as the team may adjust its process in the light of success or failure to generate the required outcomes. Environmental task demands have a critical influence on team processes. For example, if a resource such as an item of equipment is limited in availability then the team will have to come up with an allocation or sharing mechanism for that resource. Another example would be team workload pressures. If the medical team is working under huge task environment input demands with large numbers of casualties to be treated, they will need to carefully manage task allocation in a way that enables that team to be effective in that situation. The conduct of team processes will be influenced by the characteristics of the team members (their KSAs) and the properties of the team both in terms of the organisational factors of the team (structure, roles etc) and attributes such as cohesion and adaptability.
26
3.4.3.4 Team Properties Team properties include both organisational aspects, such as organisational structure, roles and role allocation, team size, and team attributes such as cohesion, adaptability and morale. These are affected by the conduct of team processes and the outcomes of the processes as well as by the characteristics of the individuals in the team. In the field hospital there may need to be an adjustment to role allocation to handle particularly demanding casualty levels or to deal with a casualty who has come into contact with a chemical agent. Replacement of a team member with another who does not have the same degree of team orientation as his predecessor may affect team cohesion and morale. Successful treatment of large numbers of casualties who arrived in a short space of time may boost team cohesion and morale. 3.4.3.5 Team Member Characteristics Team member characteristics include their teamwork and taskwork KSAs and their emergent states. Emergent states reflect the dynamic nature of individual performance capabilities, influenced by the environment, the experience of carrying out the team processes including teamwork interactions, and the properties of the team. A senior surgeon coaching a junior surgeon may result in the junior surgeon extending his knowledge and skills and self-confidence. Similarly, working in a highly cohesive nursing team may engender greater team orientation in a newly trained nurse in the team. On the other hand, seeing severely injured young soldiers who have been victims of Improvised Explosive Devices may have a severe emotional impact on a team member, reducing their effectiveness in their task.
3.5 Development of a Team/Collective Training Model

The development of a team/collective training model necessitates the superimposing of instructional and supporting functions, and the systems and resources required to facilitate them, onto the team/collective performance model. The basic instructional functions that are required for team training practice are illustrated in the team learning cycle model advanced by Tannenbaum, Smith-Jentsch and Behson (1998) shown in Figure 11.
27
Figure 11 Team Training Cycle, adapted from Tannenbaum et al (1998) The set of instructional functions is completed by the addition of initial instruction. The supporting functions that need to be added to this model concern the configuration, control, monitoring and adaptation of the practice environment. All of these functions will typically require supporting resources and systems. For example, an instructor observing a tank squadron will probably not follow it on foot across the exercise area, using a four wheel drive vehicle would be somewhat more convenient. Observing the same tank squadron exercising in a synthetic training environment would require some means of accessing the virtual environment in which they were exercising to make equivalent observations. These requirements are illustrated in Figure 12 as aspects of the training overlay.
28
Figure 12 The Team/Collective Training Model Figure 12 shows the instructional functions applying to team processes, team properties, team member characteristics and performance outcomes. Environment management functions are connected to the task environment.
29
4 Review of Team Analysis Methods Applicable to TCTNA

4.1 Introduction
A review of analytical methods aimed at team training analysis was conducted to determine if there was an extant method that was suitably comprehensive to be used for TCTNA, or if not, which extant methods were suitable to be used as components of the TCTNA approach.
4.2 Evaluation of Methods

A previous HFI DTC review of Human Factors methods, published by Stanton, Salmon, Walker, Baber and Jenkins (2005), identified four methods applicable to TCTNA: Hierarchical Task Analysis for Teams Team Cognitive Task Analysis Team Task Analysis Task and Training Analysis Methodology
A further literature review identified a further two applicable methods: Mission Essential Competencies Models for Analysis of Team Training
These six methods are reviewed in turn.
4.2.1 Hierarchical Task Analysis for Teams

Hierarchical Task Analysis for Teams (HTA(T)), was developed by Annett, Cunningham and Mathias-Jones (2000) under a MoD research contract, of which one of the aims was to devise a procedure for identifying team skills. It is a simple adaptation of the original HTA method devised by Annett, Duncan, Stammers and Gray (1971). The HTA chart notation, shown in Figure 13, is extended to contain a list of the actors involved in the goal or sub-goal. Each sub-goal shown in the chart also has a supporting table which details the goal, the plan, the evaluation measures and a description of the teamwork required to enact the plan. Teamwork is characterised as comprising communication and coordination.
30
Figure 13 Example HTA (T) Chart Whilst the model of teamwork is limited, the tabular format supporting the HTA chart could be amended easily to contain other pertinent information. HTA has been described by Kirwin and Ainsworth (1992) as the best known task analysis technique (p 396). The representation of instructional scalers (maps of training objective hierarchies) as part of all MoD training documentation is based on the HTA chart format (without the plans) and so will be familiar to training needs analysts. As such it is a strong candidate for inclusion in any TCTNA method for the analysis of tasks and identification of teamwork components.
4.2.2 Team Cognitive Task Analysis

Team Cognitive Task Analysis (TCTA; Klein, 2000) is an adaptation of the Critical Decision Method (CDM; Klein and Armstrong, 2005). The essence of the method is the conduct of a set of semi-structured interviews with all members of a team, using a predefined set of questions (probes) following observation of a task. A timeline of the task observed is developed noting the critical decision points. The interviews develop a view of the decision making requirements, cues used, reasons for difficulty, possible errors, and strategies for effective decision making. It is suggested by the originators that HTA is conducted prior to use of the technique to develop an understanding of the task being analysed. Stanton et al (2005), characterise it as a method that is resource intensive and requires considerable training to use. It has potential for analysing complex, decision intensive tasks, but is unlikely to be of value for the main component of task analysis.
4.2.3 Team Task Analysis

Team Task Analysis (TTA; Burke, 2005) has been under development since the early 1990s as a method for identifying both the teamwork and taskwork components of a task. The procedure for conducting Team Task Analysis involves firstly analysing the taskwork requirements of the task, although no analysis methodology is specified, and
31
secondly conducting a coordination analysis. Coordination analysis involves selecting a teamwork taxonomy (none is specified) and getting Subject Matter Experts (SMEs) to rate each item on the taxonomy on a likert scale from 0-10 indicating the degree to which the item is required for each task that has been identified. Whilst the notion of rating teamwork processes in terms of their relative importance in a task appears to have merit, the absence of detailed guidance or a teamwork taxonomy makes TTA a weak candidate for inclusion as a component of TCTNA.
4.2.4 Task and Training Requirements Analysis Methodology

Task and Training Requirements Analysis Methodology (TTRAM) (Swezey, Owens, Bergondy, and Salas, 1998) was developed as a method to identify potential application areas for the use of networked simulations to supplement live training. For each task identified in the task analysis a skill decay analysis and a practice effectiveness analysis is conducted. The skill decay index calculation is based on ratings of task difficulty, degree of prior learning and frequency of task performance. The practice effectiveness index calculation is based on ratings of amount of task practice in the extant system, frequency of task practice and quality of task practice. These indices are used to identify training gaps. Further ratings of task skill requirements, task criticality level and teamwork level are established to guide the selection of training solutions. Unfortunately the guidance on identifying putative solutions is scant. Overall there appears to be little of value in this method for TCTNA.
4.2.5 Work Domain Analysis

The Australian Defence Science and Technology Organisation has applied the Work Domain Analysis (WDA) component of Cognitive Work Analysis (CWA) to TNA (Naikar and Sanderson, 1999). At the heart of the WDA process is the development of an abstraction hierarchy, the composition of which is shown in the first column of Table 5. The first three levels of the abstraction hierarchy (functional purposes, properties and values and purpose related functions) provide a technology agnostic description of the requirements for the system. The lowest two levels (physical functions and physical form) describe the physical implementation of the system as designed. There are many to many mappings between each level of the hierarchy. The novel element of the approach adopted by Naikar and Sanderson (1999) is the mapping of the abstraction hierarchy elements to training needs and functional specifications. The mappings are shown in the second and third columns of Table 5. The mapping to training objectives appears to make sense in terms of training an individual in the use and exploitation of a system, although it may prove challenging to integrate the different views on performance into a coherent set of training objectives. The most significant aspect of the approach is the mapping to functional specifications as it highlights the requirement for the ability to collect performance data in the training environment, the need to specify effective scenarios and the need to correctly identify the physical and functional attributes of the system in use and the environment. Furthermore they make the point that the specifications of physical and functional fidelity should focus on the functionally relevant aspects of fidelity.
32
This approach does not address instructional methods or the related instructional and supporting functions, although potentially the abstraction hierarchy approach could be adopted to identify the instructor functions and then map them into implementation for a given training environment. Table 5 Work Domain Analysis Abstraction Hierarchy (Naikar and Sanderson, 1999)
Functional Structure Functional Purposes: Why a domain exists or the reason for its design Properties and Values: Criteria for ensuring that purpose related functions satisfy system objectives Purpose-related Functions: Functions that must be executed and coordinated Physical Functions: Functionality afforded by physical devices in the work domain and significant environmental conditions Physical Form: Physical devices of the work domain and significant environmental features Training Needs Training Objectives: Purpose for training workers to fulfil the functional purposes of a work domain Measure of Performance: Criteria for evaluating trainee performance or the effectiveness of training programmes Basic Training Functions: Functions that workers must be competent in executing and coordinating Physical Functionality: Workers must be trained to exploit the functionality of physical devices and operate under various environmental conditions Physical Context: Workers must be trained to recognise functionally relevant properties of physical devices and significant environmental features Functional Specifications Design Objectives: training system must be designed to satisfy the training objectives of the work domain Data Collection: Training system must be capable of collecting data related to the measures of performance Scenario Generation: Training system must be capable of generating scenarios for practicing basic training functions Physical Functionality: Training systems must simulate the functionality of physical devices and significant environmental conditions Physical Attributes: Training System must recreate functionally relevant properties of physical devises and significant features of the environment
4.2.6 Mission Essential Competencies

The Mission Essential Competencies (MEC) approach to analysing training tasks was developed by the United States Air Force USAF Research laboratories in order to develop training interventions to enhance warfighter readiness. A series of SME workshops are held to firstly identify the competencies that are required to perform mission tasks effectively and then to identify the experiences that are considered necessary to exercise those competencies. This is probably the most significant aspect of the method in that it focuses on the required information to generate credible training scenarios. Whilst the method is focussed on the enhancement of existing training, then emphasis on scenario specification is particularly noteworthy.
4.2.7 Models for Analysis of Team Training (MATT)

MATT (Dstl, 2006) was developed with the objective of providing the RN with an approach to collective training that complemented the SAT process for individual training. Consequently, it attempts to address the analysis, design and evaluation of
33
training and is therefore the most comprehensive of the methods reviewed. The major stages are shown in Table 6. Table 6 MATT Process Stages (Dstl, 2006)
Team Task Analysis Stage One Stage Two Stage Three Stage Four Stage Five Establish principal features of the teams task and main measurement requirements Identify Team Goals, Team Tasks, and Supporting Team Tasks Identify Team Processes and Team Errors Identify Team Knowledge and Attitude Requirements Identify priorities for Team Training
Team Training Design Stage One Stage Two Establish principles of Team Training Specification of Team Training Media
Team Training Assessment Stage One Stage Two In Training Performance Assessment Post Training Performance Assessment
The task analysis method is based on HTA(T) followed by the identification of likely errors and consequences. Teamwork requirements are evaluated by rating the importance of the main categories of teamwork identified in teamwork taxonomy as high, medium or low. A table of suggested knowledge and attitude requirements is provided. Team training priorities are determined by a consideration of difficulty in learning tasks, ease of forgetting, when the task will be performed after training, task frequency and task familiarity (previous experience). It is suggested that the output of the analysis would lead to the construction of a description of principal features of the team task, of a set of matrices and prioritised list of training activities. Whilst the guidance provided is reasonably lengthy, it is surprising that there is no explicit guidance about how the suggested outputs are derived from the recommended analysis steps or how these outputs should be used subsequently. Although the analysis is comprehensive, the difficulty arises in then taking the data forward into the training design phase, as the guidance is limited to a list of training principles and some suggested environment options for different categories of training task. Teams are categorised as requiring training at stages equivalent to Fitts (1964) cognitive, associative and autonomous stages. The significance being that it is argued that novice and intermediate training requires lower fidelity training environments. Notwithstanding the validity or otherwise of this assertion, there is no guidance provided on fidelity analysis or training environment specification. Detailed guidance on the development of assessment instruments is provided appropriate to the detailed course design stage.
34
In summary the approach is strong from the perspective of the task analysis element, although there are no diagrammatic techniques used, so it is sometimes difficult to visualise the relationships between data collected at different stages of the analysis. However, it is weak in giving guidance on training methods, instructor tasks and the specification of instructional environments.
4.3 Evaluation
The review of the available methods shows that there is no one method already in existence that is sufficient in scope to satisfy the requirements of TCTNA. HTA(T) looks to be a promising method for conducting the core of the task analysis, and the principles of the WDA abstraction hierarchy look to have application for the identification of instructor functions and in the approach to specifying training environments and training scenarios. A TCTNA method was therefore developed, see section 5.0.
35
5 The TCTNA Method

5.1 Introduction
The TCTNA Method described in the remainder of this document is designed to supplement the guidance provided in JSP822, not replace it. Detailed guidance is provided on how to conduct the task analysis and subsequent option generation and selection. The scoping study and post project evaluation phases are not considered as the extant guidance is considered to be sufficient. A note of emphasis with regards to the scoping study is merited however. Given the complexities of team and collective tasks, access to documentation about the task (both doctrine and system data) and SMEs is imperative and must be considered in detail.
5.2 The Team/Collective Training Model
Figure 14 The Team/Collective Training Model The Team/Collective Training Model in Figure 14 provides the framework for data collection within the TCTNA method. Each component of the model is addressed during the analysis process.
36
5.3 The Triangle Model of TNA

The TCTNA method is structured around the Triangle Model of TNA shown in Figure 15, which is an extension of that developed previously by the HFI DTC (2009).
Figure 15 The Triangle Model of TNA Constraints on the final training solution have to be captured at an early stage to ensure that analytical effort is not wasted on exploring training solutions that are untenable. For example, a lack of available submarines might preclude live training for anti-submarine warfare therefore leading to a synthetic training solution being the only feasible solution. Constraints analysis (described first) is an ongoing process through the analysis. The Team/Collective Task Analysis component combines operational task analysis and training gap analysis from the extant TNA model, along with their outputs. At the start of this analysis a number of models are made that capture the nature of the environment that the team operates in as well as the organisation of the team and its communications structure. Modelling techniques derived from software engineering are exploited to provide useful visualisations. This ensures that the analyst develops a clear understanding of the context of the task as well as providing valuable information for the subsequent specification of training environments. The core of the task analysis is conducted using an extension of HTA(T). The teamwork elements of the task are characterised based on the teamwork taxonomy developed to underpin the Team/Collective Training Model. The identification of training priorities is conducted using a risk management approach. Training Overlay Analysis consists both of identifying appropriate methods for facilitating the required training along with generic scenarios that the training environment must ultimately support if effective training is to be delivered. Borrowing
37
from the concept of the abstraction hierarchy from Work Domain Analysis, instructor functions are identified that are required to set up and deliver training In team and collective training there are frequently many instructional staff involved with a variety of roles. It is essential that these roles are identified and consideration given as to what facilities are required to support those roles (such as capturing performance data and conducting After Action Review). Training Environment Analysis focuses on the specification of the required training environments. This includes a fidelity analysis (fidelity analysis cannot be conducted until the training method has been identified (for example, a part task training environment will have very different fidelity requirements to an environment for full mission training)). The analysis also considers the identification of the interfaces that instructors would require to control training devices such as simulators and other tools that they may require to fulfil their role, such as tools to support data capture about student performance during exercises. The sub-components of each stage of the TCTNA method are shown in Table 7 along with a list of the supporting templates that are provided. Table 7 TNA Triangle Stage Sub-Components
Constraints Analysis Element & Description Constraints Analysis Supporting Templates Constraints table: Team/Collective Task Analysis Element & Description External Task Context Description Supporting Templates/Notation Generic Scenario Table External Team Context Diagram Interaction Table Environmental Description Table Environmental Task Demands Table Internal Task Context Description Organisational Chart Role Definition Table Internal Team Context Diagram Interaction Table System Matrix Communications Diagram Communications Matrix Hierarchical Task Analysis for Team/Collective Training (HTA (TCT)) HTA (TCT) Diagram Task Sequence Diagram HTA (TCT) Task Description Tables Task Role Matrix
38
Teamwork Analysis
Teamwork Process Priority Table Teamwork Interaction Table
Training Gap Analysis Team/Collective OPS and TO Development
Training Priorities Table
Training Overlay Analysis Element & Description Instructional Methods Selection Training Scenario Specification Supporting Templates/Notation Practise and Assessment Methods Table Training Objective Generic Scenario Table Environment Description Table Instructional Task Identification Training Overlay Requirement Specification Instructor Task Table Environment Description Table Training Environment Analysis Element & Description Training Environment Specification Training Environment Rationalisation Fidelity Analysis Training Environment Option Identification Training Environment Option Definition Training Environment Option Description Table Training Environment Option Properties Table Training Environment Option Evaluation Training Environment Options Comparison Table Environment Object Specification Tables Supporting Templates/Notation
A Tornado F3 Pairs training example is used to illustrate various elements of the analysis phases. The background to this example is shown in the box below.
39
Tornado F3 Pairs Training Example The use of a coordinated pair of mutually supporting aircraft has been central to fighter tactics since WW1. The example used as a case study running through the three analysis phases is based on the requirement to provide enhanced training in pairs tactics for Tornado F3 pilots and Weapons Systems Operators (WSOs) in training. The detail is derived from research data from a transfer of training trial conducted to establish the effectiveness of a networked desktop computer system for training pairs tactics. This example has been chosen as it is a highly demanding task which places extreme demands on the teamwork skills of the crews. The context is a pair of fighters patrolling an area of airspace searching for bandit fighters or bombers. The pair consists of a lead aircraft and a wingman aircraft. The lead aircraft controls the intercept. The search is conducted by the WSOs using the air to air radars. The search space is divided between them to improve the efficiency of the search. A ground based or airborne Fighter Controller if present can also give vectors to a bandit aircraft. If bandits are detected and the pair have a tactical advantage an intercept ensues. As the WSOs are looking at different sectors of airspace, the WSO who has detected the bandit has to give directions to the other WSO so that he can get the same radar picture. This is referred to as the radar meld. The aim of the pair is initially to destroy the bandits Beyond Visual Range (BVR) with radar guided missiles. If there is a single bandit, the leader will engage it whilst the wingman flies in support ready to take a back up shot if required. If there are two bandits, then both aircraft will engage a bandit after agreeing who is going to attack which one. The WSOs direct the radar based intercept. If the BVR intercept is unsuccessful but the pair still have a tactical advantage a visual intercept ensues. The WSO talks the pilots eyes onto the bandit location during the merge into the visual. Once the pilot can see the bandit he takes over the intercept aiming to shoot the bandit down with heat-seeking missiles. During the visual intercept the WSOs provide an extra pair of eyes to watch for threats at visual range.
40
6 Constraints Analysis
6.1 Introduction
Constraints analysis is a simple but critical component of TCTNA. Accurate identification of the constraints on the choices of training method and environment prevent nugatory analytical effort in exploring training options which are not viable. Typical categories of constraints include, but are not limited to: a. Safety Safety can be a significant constraint on the choice of training environment. A typical example would be limitations on live firing. Invariably weapons effects have to be simulated. b. Cost Cost of the use of training assets (a Tornado F3 costs between 10K and 40k per hour to operate depending on what is included in the cost model) and consumables (missiles can cost from tens to hundreds of thousands of pounds each depending on type). c. Training audience availability There may be limits on how long a training audience is available for training and when that availability falls. d. Resource availability Limitations on the availability of training areas, equipment required for training, daily and seasonal weather conditions (for example, the British Army Training Unit Suffield training area in Canada is unavailable during the winter months as it is frozen over) can all limit training options. It may also be difficult to present credible threats if the weapons platforms required are not within the current Order of Battle. e. Policy There may be policy constraints on how training is conducted such as the qualifications required for instructors to be able to conduct certain types of training and the requirement for simulation to be explored as an option.
6.2 Constraints Tables

It is recommended that at the start of the TCTNA process a constraints table is constructed and that it is maintained throughout the analysis. It should capture both the constraints and their consequences. An example format is shown in Table 8.
41
Table 8 Example Constraints Table Format

Constraint Live firing cannot take place against manned targets Instrumented ranges are not available for F3 Pairs training Limited aircraft hours are available for training Consequence Instrumented Ranges are required for weapons effects to be simulated in live flying. Missile success has to be determined by instructors evaluations of launch parameters and intercept geometry. Additional training time would have to be provided using simulation or training hours would have to be cut from elsewhere.
42
7 Team/Collective Task Analysis

7.1 Introduction
The Team/Collective Task Analysis (TCTA) stage is composed of a sequence of six activities: 1. External Task Context Description 2. Internal Task Context Description 3. Task Analysis 4. Teamwork Analysis 5. Training Gap Analysis 6. Development of Team/Collective Operational Performance Statements and Training Objectives. This sequence allows for a progressively detailed understanding of the task to be developed. The products at each stage are designed to have value in the subsequent stages of analysis and be of utility for subsequent training design.
7.2 External Task Context Description

The first analytical step is to capture the key elements in the environment within which the team operates, how the team interacts with those elements and why i.e. what effect is the team aiming to deliver. The recommended approach is to capture narrative descriptions of the requirements for team performance, in the form of generic scenario descriptions, and develop supporting context diagrams.
7.2.1 Generic Task Scenarios

Generic task scenarios provide a narrative description of the environment within which the team is required to operate and the teams purpose in terms of the effect that it is required to deliver. Source documents for identifying scenarios would include Concept of Operations (CONOPS), Concept of Use (CONUSE), Concept of Employment (CONEMP) and doctrine. At the early stages of the acquisition cycle for new systems these may not be fully matured or in some circumstances may not have been produced. Given that any system or organisation is put in place to deliver a required capability, SMEs form the Capability Area in MoD should be able to assist in defining scenarios, particularly as similar approach is used to determine capability requirements in the first place. The generic scenario table structure shown in Table 9 provides a format for representing scenario information which can be extended as required. Table 10 shows a completed scenario table.
43
Table 9 Generic Scenario Table Format

Scenario Reference Effect Required Timing Location & Environment Title (and reference number if required) Description of the output required from the team When the scenario takes place may be relative to a specified preceding event Geographical area (if relevant) and description of the physical environment in which the task is undertaken. This should cover both the immediate environment in which the team is operating and the larger environment in which the effect of the team is delivered (if different). Enemy force disposition and capabilities Friendly force type, numbers, locations Neutral forces and civilian population elements present of significance to the scenario The start state for the scenario Potential events and event sequences that could occur
Enemy Forces Friendly Forces Neutral Elements Initial Conditions Events
Table 10 Completed Generic Scenario Table

Scenario Reference Effect Required Combat Air Patrol forward of deployed ground forces Combat identification of unknown aircraft entering the area of responsibility and interception of enemy aircraft to maintain air superiority of friendly forces area of operations. Day/night Over any geographical area where ground or littoral forces may be operating. Fighter aircraft with similar performance and weapons capabilities to the Tornado F3. Bomber aircraft with similar performance and weapons capabilities to the Tornado GR1. AWACS providing fighter control for the area of the CAP None No enemy aircraft reported in the vicinity. Intelligence brief for the mission suggests enemy bomber packages with fighter support may attempt incursion into the area of responsibility. Fighter aircraft fly into the CAP area but turn away when illuminated by fighter radar. Bomber aircraft fly into the CAP area but turn away when illuminated by fighter radar. Fighter aircraft fly into the CAP area and take aggressive action when illuminated by fighter radar.
Timing Location & Environment Enemy Forces
Friendly Forces Neutral Elements Initial Conditions
Events
44
7.2.2 Team Context Diagrams

Context diagrams in the form of system context diagrams have been used as a representational method in Structured Analysis (a form of analysis in software engineering) since the 1960s. A context diagram is used to represent agents or actors external to a system that can interact with the system. System context diagrams show interacting systems and environments, and generally do not show internal structure of systems. The particular notation that is suggested is derived from that used in a real-time software design method called Structured Development for Real-Time Systems (Ward and Mellor, 1985) and the product is referred to as a Team Context Diagram (TCD). Detail about the nature of the interactions shown in the TCD is compiled into a related Interaction Table that provides more detail about the interactions in terms of the nature or content of the interaction and how it is mediated (such as the passing of orders by signal). The significance of the context diagram and its associated tables is that they provide: a high-level definition of the conditions within which the team carries out its task which informs the construction of the conditions statements for training objectives and the specification of training environments the inputs and outputs to the team which informs subsequent fidelity analysis
7.2.2.1 Team Context Diagram Notation The notation for drawing a TCD is shown in Figure 16. The TCD shows two types of information of interest. These are the elements in the environment that the team interacts with and the nature of the interactions themselves.
Figure 16 Team Context Diagram Notation The TCD is constructed using the following components: Team Circle The central circle is labelled with the name of the team or collective unit that is under analysis. Environment Element Boxes the rectangular boxes are labelled with the names of the elements in the environment that the team interacts with. A single box can
45
be used to represent a set of elements of the same type provided the interactions between the team and every element in the set are the same. A diverse range of element types can be represented in the diagram including, but not limited to: o Superior organisation/team o Subordinate team(s) o Peer organisations/teams (entities directly under the control of the superior organization such as other companies in a battle group) o Coalition forces o Enemy o Civilian elements (Non Government Organisations, Civilian Authorities, Media) o Neutral forces o Systems the team operate (such as sensors and weapons) o Physical environment (such as terrain, weather etc.) Data Stores Data stores show where a team and an environmental element (such as a sub-unit) can access a shared data area such as an intranet page or filestore to post or retrieve information. Interaction Arrows The arrows on the diagram show whether the interactions are one or two way. An arrow can represent multiple interactions (this avoids cluttering the diagram with multiple arrows between elements). Multiple interaction arrows are used where the team can interact both directly and indirectly through a data store. Interaction Label Having reduced the complexity of the diagram by using a single arrow to represent one or more interactions between the team and a given environment element, it is necessary to have a cross-reference to the interaction arrow so that more detail can be referenced to the diagram in the Interaction Table. A textual description could be used but this would only be effective for a single, one-way interaction. It is recommended that numbers are used for simplicity.
7.2.2.2 Interaction Table Construction The Interaction Table captures the detail of the various interactions shown in the TCD in terms of the content/nature of the interaction and the mode of interaction. The entries in the table are referenced by the interaction labels used in the TCD. The format of an Interaction Table is shown in Table 11.
46
Table 11 Interaction Table Format

No 1 From Team Element 1 2 3 4 Team Team Team To Element 1 Team Element 2 Element 3 Element 4 Content/Nature Content description Content description Content description Information type Content description Content description Element 4 Team Content description Content description 5 Team Element 4 Element 4 Team Information type Information type Mode Mode description Mode description Mode description Data store name Mode description Mode description Mode description Mode description Data store name Data store name
The columns contain the following types of information: From/To These columns capture the direction of the interaction being described, noting that there will be separate entries for each direction on a twoway interaction arrow (as shown for interaction 1), and potentially more than one entry for the same direction if multiple interactions are captured by an interaction arrow (as shown for interaction 4). Content/Nature the heading content/nature has been used to reflect the fact that the interaction may be either communication including the passing of an information product (such as sending an order or requesting information) or some form of action or effect (such as firing a missile or the effects of weather). Mode The mode of interaction is a description of how the interaction is mediated. For communication it will be the communication channel (such as voice by secure radio or email). In the case of indirect communication through a data store then the data store should be identified such as a web page where documents are posted (as shown for interaction 5).
7.2.2.3 Example External Context Description Figure 17 shows a TCD and for the Tornado F3 Pairs Air Combat training example. The TCD in Figure 17 shows all of the elements external to the aircraft that interact with the pair and has therefore been labelled the external environment TCD. Weather and terrain have been included in the diagram, as the pair has to take these into account during the intercepts: close proximity to the ground affects the geometry of intercepts and visibility affects target detection and influences tactics. The bandit missiles aids have been shown separately from the bandit aircraft because the missiles act independently to a greater or lesser degree once released. In most if not all training situations where weapons are
47
involved, weapons effects have to be considered and separate analysis of weapons is therefore required to specify a training environment.
Figure 17 Example Tornado F3 Pair External Environment TCD Table 12 is the corresponding Interaction Table and shows a representative set of interactions associated with the interaction arrows in the external context TCD. These illustrate the use of one-way and two way interactions in single and multiple form and interaction via data stores. Interaction 2 shows communication of information via the Joint Tactical Information Distribution System (JTIDS). JTIDS is a complex, secure communications system and arguably it is something of a stretch to represent it simply as a data store. However, it broadcasts messages and there is no explicit reply from receiving systems in so far as one user does not know if another user has received the data from their system or has chosen to view it. The issue from the training perspective is that there is the potential for erroneous action if another user has not received or viewed information that is posted without requiring a receipt.
48
Table 12 Example Tornado F3 Pair External Context Interaction Table

No 1 From F3 Pair FC 2 FC F3 Pair 3 4 Weather F3 pair To FC F3 Pair F3 Pair FC F3 Pair Bandit Fighters Content/Nature Request for target information Target information Tactical Picture Target assignment Visibility - affecting sighting of bandit aircraft Engage with radar guided missiles Engage with heat seeking missiles Evade Mode Radio Radio JTIDS JTIDS Cloud and haze and sun position SkyFlash missiles Sidewinder missiles Air Combat Manoeuvring (ACM) ACM and use of chaff ACM and use of flares ACM ACM and use of chaff and flares Manoeuvre and warhead detonation in range SkyFlash missile Sidewinder missiles ACM ACM and use of chaff ACM and use of flares Manoeuvre aircraft Proximity and topology
Bandit Fighters
F3 Pair
Evade radar guided missiles when detected on radar warning receiver Evade heat seeking missiles when seen Manoeuvre into attacking position
F3 Pair Bandit Missiles
Bandit Missiles F3 pair
Evade and deploy defensive aids Pursue F3 and destroy
F3 pair
Bandit Bombers
Engage with radar guided missiles beyond visual range Engage with heat seeking missiles Evade
Bandit Bombers
F3 pair
Evade radar guided missiles when detected on radar warning receiver Evade heat seeking missiles when seen Evade RWR indicates radar illumination by fighters
Terrain
F3 pair
Bounds intercept geometry, causes radar clutter
49
7.2.3 Environment Description Table Construction

Even at this early stage of analysis it is possible to capture information about the functionality of elements in the environment that will inform the specification of training environments. For example, the capability required of an element such as a sub-unit will determine if it is something that requires the element to participate in training or if it can be represented by a role player or computer generated entity for instance. Further information about the nature of the actions of the environmental elements is compiled into an Environment Description Table, a suggested format of which is shown in Table 13. The Environment Description Table is a table that will be populated with a variety of data during the whole of the analysis process, the aggregation of which will provide the necessary detail to define training environments. The entries recommended at this stage are: Element Description The element description should provide a brief overview of the role of the element in the environment, in other words what does it do? Action/information required to generate interaction to the team a description is required of how the element generates the interaction in terms of what information must be available to it and what knowledge is required. Action on receipt of interaction from the team a description is required of how the element should react to the interaction from the team, providing an understanding of the purpose of the interaction. Table 13 Environment Description Table Format
Element Element Description Outputs to the Team Inputs received from the team Element 1 Description of element 1 Description for interaction 1 Description for interaction 1 Element 2 Description of element 2 None Description for interaction 2 Element 3 Description of element 3 None Description for interaction 3 Element 4 Description of element 4 Description for interactions 4 and 5 Description for interactions 4 and 5
The information about the element and how it interacts with the team is critical from a training perspective both in terms of comprehending the team task, but also informing how an element would be represented in the training environment, including the resources it would require. For example, a warfare team training in a synthetic environment may need to be fed sightings of enemy units attacking the ship from a bridge watchkeeper. Since the bridge does not exist (there is no window for a watchkeeper to look out of) whoever is roleplaying the watchkeeper needs a representation of the environment (such as a top down display showing the range and bearing of an enemy unit) in order to provide the information.
50
Given that there are likely to be numerous entries in the environment description table, it is most likely that a spreadsheet will prove a more appropriate tool for recording the data than a text document table. Table 14 shows Environment Description Table entries that correspond to the elements in the External TCD Figure 17. Not all elements have an entry in every cell. In this case, it is not meaningful to describe what information the weather or terrain needs to interact with the team. Standard voice procedure and codewords are used in the communication between the Fighter Controller and the Team. This is recorded in the Fighter Controller column.
51
Table 14 Example Tornado F3 Pair Environment Description Table

Element Element Description Fighter Controller The FC interprets and air defence radar display to provide target location and vectors to the target Bandit Fighters Bandit fighters have equivalent performance to the F3 and are armed with radar guided and heat seeking missiles and have radar warning receivers Offensive and defensive manoeuvre, heat seeking and radar guided missile shots, deployment of defensive aids Bandit Missiles Radar guided and heat seeking missiles Bandit Bombers Bandit bombers have similar performance to the F3 and are armed heat seeking missiles and have radar warning receivers Defensive manoeuvre BVR, offensive and defensive manoeuvre in visual range, missile shots, deployment of defensive aids Weather Clouds, haze, precipitation, sun position and light levels Terrain Ground topology
Outputs to the Team
Target location and vectors to the target by voice (note : standard voice procedure and codewords used) Updates to tactical picture via JTIDS Requests for target information. Target assignment information via JTIDS
Pursuit of pairs aircraft based on radar and heat signatures and aircraft manoeuvre, detonation of warheads within range Deployment of defensive aids
Visibility of bandits affected
Affects intercept geometry and can cause radar clutter
Inputs received from the team
Offensive and defensive manoeuvre, heat seeking and radar guided missile shots, deployment of chaff and flares
Offensive and defensive manoeuvre, heat seeking and radar guided missile shots, deployment of chaff and flares
N/A
N/A
52
7.3 Internal Task Context Description

Having determined the external context of the team in terms of the entities it interacts with and the nature of the interactions the next logical step is to determine its internal structure and the role that each of the elements of that structure. If the team occupy a dedicated space or spaces it may be useful to obtain a seating plan for the team roles. One would expect to find organisational structure charts already in existence either because the team already exists, or because its composition would need to have been identified to design the spaces it is to operate in (in the case of a team manning equipment) or because its composition would need to have been defined for manning purposes. Similarly one would expect role information to be readily available. However, in complex acquisitions such as for the QE Class Carrier, concepts evolve over time and the currency of documents may need to be checked. Experience shows that changes may be made in one area of structure and team organisation that impact elsewhere and the impacts may not have been rippled through. Examples include changes in manning levels not being reflected in seating and workstation allocation in spaces and mismatches between allocation of roles. The TNA process can often highlight such anomalies to appropriate SMEs.
7.3.1 Organisational Structure

A first step in understanding how a team or collective organisation works is to determine its organisational structure. Where a large team is broken down into sub-teams, these sub teams have to be identified. Where a team membership may exist in a number of forms, such as manning states (e.g. Harbour watches, Cruising Watches, Action Stations), then each manning state will need to be mapped out. Figure 18 shows an organisational chart for the Tornado F3 Pair. Whilst it appears trivial to construct as there are only four individuals involved, complexities can arise because of the number of potential roles and how those roles can be re-allocated. The formation leader may be either the pilot or WSO of the lead crew (usually determined by experience) and has overall command responsibility for the pair. However, during the search for bandit aircraft and in a subsequent beyond visual range engagement of the bandits, the formation will be led tactically by the lead WSO. If the engagement develops into a visual fight, then the lead pilot takes over tactical control. However, if the wingman aircraft has the tactically superior position to the lead aircraft when it comes to engaging the bandit beyond visual range, the wingman WSO will take over the tactical leadership of the formation with tactical control passing to the wingman pilot for the visual phase of the engagement.
53
Figure 18 Example Tornado F3 Pair Organisational Chart 1
7.3.2 Role Definitions

Role definitions for each sub team or team member should be populated. Useful headings include: Team Name e.g. Flight Deck Management Team 1a Team Role Name e.g. Flight Deck Officer Role Rank Lt/Cdr / Lt Location (if relevant) Role Description Interfaces Role Allocation
Table 15 and Table 16 show example role definitions for the Lead and Wingman WSOs respectively. These roles are complementary and this becomes apparent in the role description. As these roles can also be dynamically reallocated during an intercept this is captured in the role descriptions by adding an extra field to the role descriptions concerning role allocation. This information can inform the subsequent analysis of the team task.
54
Table 15 Example Role Definition for the F3 Pair Lead WSO

Team Role Rank Location Role Description F3 Pair Lead WSO Flt Lt/Sqn Ldr WSO Cockpit Interfaces Role allocation Managing the radar search for bandits including allocation of radar search areas Liaising with Fighter Controller Performing radar meld with wingman WSO once bandits identified Tracking bandits once identified Directing the beyond visual range engagement Guiding pilots eyes to bandits during visual merge Conducting visual search for bandits and bandit missiles during visual engagement
Radar, JTIDS, RHWR, Radio, Intercom, Weapons System, Visual Scene Usually held by the WSO in the Lead crew but can be allocated to the wingman WSO by the lead WSO at the start of an intercept if the wingman has the tactically superior position in formation against the bandit
Table 16 Example Role Definition for the F3 Pair Wingman WSO

Team Role Rank Location Role Description F3 Pair Wingman WSO Flt Lt / Sqn Ldr WSO Cockpit Conducting radar search for bandits in search area directed by Lead WSO Performing radar meld with Lead WSO once bandits identified Conducting radar search for other bandits whilst lead WSO tracks bandits identified Directing the beyond visual range engagement Guiding pilots eyes to bandits during visual merge Conducting visual search for bandits and bandit missiles during visual engagement Interfaces Role allocation Radar, JTIDS, RHWR, Radio, Intercom, Weapons System, Visual Scene Usually held by the WSO in the wingman crew but can be taken by the lead WSO if the wingman has the tactically superior position in formation against the bandit
55
7.3.3 Internal Team Context Diagram

Drawing a TCD can be a useful way of capturing the essential features of the immediate or internal operating environment that the team operates in, particularly in capturing the systems that they operate. Figure 19 shows an Interface TCD for the Tornado F3 Pair. It should be noted that this diagram shows the interfaces for each crew in the pair. There is no need to duplicate the diagram for each aircraft as they are the same. There are many more systems on the Tornado F3 than are shown on the diagram. Those shown have been selected based on their relevance to the training of pairs tactics. Items such as electrical systems, hydraulics systems and ejector seats have been omitted as they are not relevant to tactics training, whereas fuel gauges have been included as low states are a cue to disengage from an intercept and return to base.
Figure 19 Example Tornado F3 Pair Interfaces TCD Table 17 is the corresponding Systems Interaction Table and shows a sample of the interaction descriptions. The challenge at this stage in the analysis is deciding on the level of detail to record. Interactions with systems tend to be quite complex as the data output is often complex as are the input interactions. Ultimately a lot of detail may be needed, particularly if a synthetic training environment has to be specified. It is suggested that a relatively high level description is used at this stage as there is no point in doing extensive analysis until the decision has been made that there is a training requirement and training objectives have been established. If, during further stages of analysis, it is found that more detail is required the table can always be amplified. It is likely that that much of the detail will appear as amplification in the mode column.
56
Table 17 Example Tornado F3 Pair Interface Interaction Table

No 2 From F3 pair Radar 5 F3 Pair To Radar F3 Pair Radio Content/Nature Control of radar scan area Radar picture Transmit selection Mode WSO radar hand controller WSO and pilot radar displays Pilot and WSO, press to transmit buttons on joystick and nav radar hand controller Helmet Microphones Pilot and WSO headsets
Outgoing voice comms Radio F3 Pair Incoming voice comms
Table 18 shows the corresponding entries in the Environment Description Table (noting that this is not a new table, these are additional columns in the table constructed for the previous TCD). The same issue about level of detail applies to this table, the guidance being to try to capture sufficient detail for the level of analysis being conducted. It is useful to include a reference to the appropriate technical document(s) should further detail be required. Precise descriptions of cockpit fields of view may become relevant if simulation is required as a training solution. Table 18 Tornado F3 Pair Environment Description Table Entries
Element Element Description Radio VHF and UHF radio with control panel, transmit buttons on pilot stick and WSO radar hand controller (Technical Reference) Radar Foxhunter multi-mode radar controlled through control panel, WSO hand controller and pilot hand controller with front and rear cockpit displays (Technical Reference) Outputs to team Inputs from team Voice comms Radar picture and current settings Radar configuration settings View of terrain, weather, bandits, bandit missiles and flares, other aircraft in pair N/A Visual Scene Tandem seating limits WSO field of view forwards through the canopy. Head up display central in pilot field of view. Terrain and weather can be seen. Sighting of bandit aircraft, missiles and defensive aids depends on range and visibility
Channel settings, press to transmit, outgoing voice comms
In the Tornado example use and access to the various systems is distributed between the pilot and the WSO in each aircraft. Some systems are accessible to both (radios, RHWR displays) whilst others are seat specific (e.g. flying controls for the pilot). With larger teams this distribution gets more complex. At this stage it can be useful to compile a matrix of who has access to which system to aid understanding of team functioning. A systems matrix is one way to do this as shown in Table 19
57
Table 19 Example System Matrix

System User Pilot Flying Controls RHWR Radio Head up Display JTIDS X X X X X X X WSO
7.3.4 Team Communication Structure

It is useful at this stage to identify how communications can be supported within the team and with external agencies outside the boundary of the team. There are a number of ways that this information can be portrayed. The suggested methods are a Communications Diagram, a communications Matrix and a Textual Description. 7.3.4.1 Communication Diagram The notation for a Communications diagram is illustrated in Figure 20 which shows a Communications Diagram for the Tornado F3 pair. The use of a diagram is particularly powerful when sub-teams or team members are in different locations (including split from their sub team or team and located within another sub team). The notation is the same as that for a TCD with the following additions: Nested boxes are used to show sub-teams and team members within a sub team The arrows represent lines of communication and can represent multiple modes (not shown in the example, but for a single-seat fighter the pilots could communicate using radio and wing waggling and these two could be represented with a single arrow) An arrow terminating at a sub-team box indicates all members of that sub-team can be communicated with by the mode(s) represented by that arrow (e.g. arrows 9 and 10 for wing waggling) An arrow originating from a sub-team box indicates that all members of the subteam can communicate with the recipient using that communications mode(s) represented by the arrow (e.g. arrow 6 for radio communication) A dashed box indicates an element outside the team boundary (e.g. the Fighter Controller)
58
The arrows on the diagram could be labelled with the communications mode but even on a small diagram such as Figure 20, this could make the diagram too cluttered to read. The arrows have therefore been numbered so that the detail can be recorded in an associated Communications Description or Communications Matrix.
59
Communications Description The crews (Pilot and WSO) communicate internally using intercom (7,8). Each crew member can communicate with both members of the other crew and the fighter controller using the radio (1,4,6) (radio transmissions are heard internally over the intercom by the other crew member). The WSOs can also communicate with each other and the Fighter controller using JTIDS. (2,3,5) Pilots can communicate with the other crew visually by wing waggling. (9,10)
Figure 20 Example Tornado F3 pair Communications Diagram and Textual Description Table 20 Example Tornado F3 Pair Communications Matrix
Communications Channel Role Lead Pilot Lead WSO Wingman Pilot Wingman WSO Fighter Controller Visual X Rx only X Rx only Intercom (leader) x x x x Intercom (wingman) Radio x x x x x x x x JTIDS
60
Ultimately, the communications diagram can be extended to form an Internal Context Diagram for the Team by including other, non-communications interactions. However, this necessitates the determination of: which internal communications connections are actually used and the content of the interactions on these connections. the source (sub-team or team member) of interactions with external environment elements. the recipients (sub-team or team member) of interactions from external elements.
Whilst some of this information may be available at this stage and therefore the Internal Context diagram could be started, it is likely that much of the information will be determined during the subsequent task analysis stage and its construction is probably best left until that stage. 7.3.4.2 Communications Description The communications description provides a simple way of presenting the information about the communication modes related to the arrows in the Communications Diagram. The numbers in brackets cross-refer to the numbers on the diagram. An example of such a description is shown alongside the Communications Diagram in Figure 20. For relatively small Communications Diagrams this is probably the most efficient way of presenting this information. 7.3.4.3 Communications Matrix A Communications Matrix provides a tabular representation which captures the modes of communication which are possible both internally between team members and between team members and external elements. Table 20 shows an example Communications Matrix for the Tornado F3 pair that corresponds to the Communications Diagram shown in Figure 20. The orientation of the matrix (whether the channels are shown as rows or columns) is simply a matter of convenience based on the number of channels and the number of people/roles that are communicating. A Communications Matrix is of particular value when the communications network is large or complex and Communications Description would become unwieldy.
61
7.4 Task Analysis

Having characterised the context of the team/collective task, the next stage is to conduct a task analysis.
7.4.1 Hierarchical Task Analysis for Team & Collective Training - HTA(TCT)
The Hierarchical Task Analysis for Team and Collective Training HTA(TCT) approach is adapted from the approach developed by Annett (2000) under a previous MOD research contract. Tasks are hierarchically decomposed and represented in an HTA diagram. Supporting detail is recorded in a task description table. Task sequence diagrams are also produced to provide a temporal view of task execution. Finally a Task Role matrix is constructed to provide a quick reference to participants in each task and sub-task. Data sources for the HTA(TCT) would typically include documentation (such as CONOPS, CONUSE, CONEMP and role group summaries if available) and discussions with SMEs. Observation of the task may be possible if the TNA is being conducted to update extant training. For new systems this will not be possible. One of the more challenging questions when conducting any form of HTA is at what point do you stop? The technically accurate answer is when it is fit for purpose. In practical terms for Team and Collective training the decomposition can stop when sufficient information about how the team interacts has been gleaned. Typically this will be when an individual task has been reached or a multi-actor task is sufficiently simple that further decomposition is not needed. 7.4.1.1 HTA(TCT) Diagram Notation and Format The format used for the HTA(TCT) diagrams is shown in Figure 21.
62
Figure 21 HTA Diagram Format The HTA(TCT) diagram presents two sorts of information. The bulk of the diagram is made up of a hierarchical presentation of the overarching task and sub-tasks that must be met in order to achieve it. The format will be familiar, as it is essentially the same as that used for an organisational chart or instructional scalar. In addition to the task hierarchy, plans are shown which describe the sequencing for each set of sub-tasks. The notation used for constructing the diagrams (adapted from Stanton, 2006) is detailed in Table 21. Rounded boxes are used for the plans so that they are easily distinguished from sub-tasks. Similarly, diagonal lines are used to link plans to the node where they apply to avoid confusion with task and sub-task connectors. Table 21 HTA(TCT) Diagram Element Symbols and Descriptions
Element Symbol Contents/description Tasks and subtasks Task and sub-task connectors Plans Task/sub-task number Sub-teams and team members conducting the task Task description These connect tasks to their sub-tasks Plan + number of task/sub-task that it refers to Sequence in which the sub-tasks are executed These connect plans to the node where the subtasks connect to the task which they are amplifying
Plan connectors
The use of separate boxes to show plans is recommended simply on the grounds of clarity. The plan information could be shown in the task box but the box could become rather large. That said, if charting software is used for drawing the HTA it may not have the necessary facilities for showing the plans separately, in which case the plan information can be located in the associated task box. Plans can be quite complex and, as a consequence, a textual description could be quite large and unwieldy on the HTA diagram. A suggested syntax for expressing plans more tersely (adapted from Stanton, 2006) is shown in Table 22. The choice between using the suggested syntax, or text or a mixture of both for describing a plan lies with the analyst. However, the guiding principle must be that of clarity a triumph of syntactical dexterity over clarity serves no useful purpose to the reader of the HTA.
63
Table 22 Syntax for plans and examples of use

Text then and or Any of If condition X then 2 Symbol(s) > + / : X? > Example of use and text equivalent 1>2 1+2 1/2 1:2:3 Thirsty? > 2 Do 1 then 2 Do 1 and 2 together Do 1 or 2 Do 1, or 2 or 3 If thirsty then do 2
7.4.1.2 Example HTA (TCT) Diagram An example of an HTA diagram for the Tornado F3 pairs task Destroy bandit beyond visual range is shown in Figure 22. This shows the goal as being sub-divided into five sub-tasks, numbered 1.1 to 1.5. With the exception of sub-task 1.1 (Check for bingo fuel), these sub-tasks are decomposed to another level. Sub-task 1.4 (Engage Bandit BVR) has two further levels of decomposition. One of the challenges in constructing an HTA diagram is deciding how to lay it out and how much information to put on one page. Even with only three levels of decomposition, it can be seen from Figure 22 that the HTA diagram becomes quite large and that it is not always possible to show all items at the same level of decomposition on the same line. The decomposition for task 1.4 has been shown on the bottom half of the page to avoid having to split the diagram across more than one page. Figure 22 is pretty much at the limit in terms of the amount of information that can be shown on a single page and still be readable. Where a diagram needs to be split across multiple pages, appropriate subtasks should be selected to be decomposed on other pages. In this example, sub-task 1.4 would be a candidate for decomposing on another page as it is as complex as all the other sub-tasks put together and is the only one that has two levels of decomposition. Plan 1 and plan 1.4.3 illustrate the use of a mix of plan syntax and free text to describe the plans. This choice was made as, in each case, it was difficult to capture the complexity of the plan by use of the syntax alone and a free text description would have taken up too much room. Abbreviations for the names of the sub-team and team member roles have been used to conserve space in the task boxes. These are expanded in the legend at the bottom of the diagram.
64
Figure 22 Example HTA for the F3 Pair Task Destroy Bandit beyond Visual Range
65
7.4.1.3 Task Sequence Diagrams HTA diagrams are a particularly effective means of representing the breakdown of a task into sub-tasks as they capture both multiple levels of detail of decomposition and detail about task sequencing. However, they have one limitation in that it is difficult to get a visual appreciation of the relative sequencing of tasks. This is of particular significance from the perspective of workload as sub-teams or team members may be involved in multiple tasks which are concurrent. To address this issue, the use of a supplementary representation of sub-task sequencing not usually constructed during HTA, is recommended. The structure and notation recommended is adapted from that used for Pert Charts (often used to show task sequencing for project management purposes). The diagrams have been termed Task Sequence Diagrams. This choice of technique was in part based on the observation that SMEs, when asked to draw a diagram showing the stages in a task, will often draw this style of diagram. Constructing such a diagram may therefore be helpful in eliciting information from SMEs for the purposes of constructing the HTA diagram. The notation is shown in Table 23. The notation for tasks and sub-tasks is the same as that used for HTA diagrams for consistency so that they can be copied from one diagram type to the other. Table 23 Task Sequence Diagram Notation
Element Terminators Symbol Contents/description These are placed at the start and end of the sequence and contain a description of the initiating and terminating conditions for the task Task/sub-task number Sub-teams and team members conducting the task Task description These horizontal arrows show how a task extends over time , the arrow head being aligned with the end of the last task in the sequence that the activity occurs in parallel with These are used for linking tasks in sequence
Tasks and subtasks Continuation arrows
Task connectors
The format of a Task Sequence diagram is shown in Figure 23. This diagram shows how three tasks are sequenced. Sub-task 1.1 has a horizontal arrow extending to the right of it indicating that its execution continues until task 1.3 terminates. Sub-tasks 1.2 and 1.3 are shown as being conducted in sequence.
66
Figure 23 Task Sequence Diagram Format Figure 24 shows a Task Sequence for the F3 Pair Task 1 Destroy bandit BVR). This captures the sequencing of the high-level sub-tasks 1.1 to 1.5, showing very clearly that sub-task 1.2 is conducted in parallel with firstly sub-task 1.2 and then sub-tasks 1.3 and 1.4 which are also conducted simultaneously. Further diagrams can be drawn to show successive levels of detail as illustrated by Figure 25 which shows the sequencing decomposition for sub-task 1.2 Detect Bandit BVR.
Figure 24 Task Sequence Diagram for the F3 Pair Task 1 Destroy Bandit BVR
Figure 25 Task Sequence Diagram for the F3 Pair Sub-Task 1.2 Detect Bandit BVR 7.4.1.4 HTA(TCT) Task Description Tables Task Description Tables capture the full range of detail required about the tasks and subtasks that will be used in subsequent stages of the TNA process. A suggested template for HTA task tables, with a description of the contents of each field, is shown in Table 24. This is an adaptation and extension of the approach used by Annett (2000). A task table should be completed for each sub-task in the HTA hierarchy.
67
Table 24 HTA(TCT) Task Description Table Structure

Task: Number and task statement Purpose: Brief description of why the task is required Initiating condition: When should the activity be started Terminating condition: When should the activity be terminated Sub-tasks and participants: List of the sub-tasks and the sub-teams and/or team members that execute them Plan: Narrative description of the sequencing of the sub-tasks involved Teamwork Description: Description of the teamwork requirements to fulfil the task. Communications modes should be included and cross-checked with the communications diagram and matrix/description Inputs External Content/Nature, Source & Mode Inputs from elements outside of the team (should tie up with inputs shown in the context diagram(s)). The mode of the input should tie up with the mode listed in the interaction table(s) Inputs received from other sub-teams or team members Communications should match a link shown in the communications diagram. The mode of the input communications should match a mode shown in the communications matrix/description Content/Nature, Destination & Mode Outputs to elements outside of the team (should tie up with outputs shown in the context diagram(s)). The mode of the output should tie up with the mode listed in the interaction table(s) Outputs to other sub-teams or team members. Communications should match a link shown in the communications diagram. The mode of any output communications should match a mode shown in the communications matrix/description.
Internal
Products External
Internal
Other Outcomes: Description of the side effects of the activity e.g. use of resources, attrition Critical Errors and Consequences: A description of the critical errors that could be made and their consequences Assessment measures and data requirements: A description of the criteria for evaluating the task (process and product) and the data that is required to make the assessment
The structure of the table is designed to provide a logical breakdown of the task or subtask, with related items located together. Specifically: The task number and task statement cross-refer to the HTA Diagram. The statement of the tasks purpose and initiating and terminating conditions put the task into context. The listing of sub-tasks and participants, the plan and the teamwork description provide an overview of the mechanics of the task and how it is executed. Including the communications modes for teamwork ensures that
68
required modes that have to be supported in training are not overlooked. If the task is not decomposed any further, the fields for sub-tasks and the plan will be left blank. If the task is performed by an individual then the teamwork field will be left blank. The fields for inputs, outputs and other outcomes capture the detail of which inputs and cues the team is responding to and how the responses are mediated. These should be cross-checked against the context descriptions. Other outcomes are included as they may impact on how the task and other tasks are achieved. Issues such as consumption of fuel and munitions and weapons effects are also significant from the perspective of training cost and safety, and may therefore influence the training option selected. Not all fields will have entries. Critical errors and consequences are included for two reasons. Firstly, this information will be required at the gap analysis stage to inform the decision about whether the task needs to be trained. Secondly, consideration of how a task can go wrong and the consequences of such an event can illuminate subsequent discussion of how performance of the task can be evaluated and what measures are appropriate. Potential consequences of errors in the conduct of a task could include: o the loss of positive effect that would have stemmed from successful task completion o loss of capability o mission failure o personnel may be injured in the completion of the task o damage to essential equipment o collateral damage or injury to 3rd parties o a breach of law or military regulations (such as Rules of Engagement being improperly applied). Assessment measures and data requirements are put last as they are best considered once a complete understanding has been developed of the process by which the task is performed and the nature of the inputs and outputs of the task.
On first inspection, completing a task table for each sub-task may appear to be an onerous and intimidating task. However, the table structure has been designed not only as an output of this stage of analysis, but also to provide an analytical framework to use during the information gathering. The table can be used both to guide analysis of documents which describe the task being analysed, and to frame discussions with SMEs. It is suggested that completing the tables as the HTA diagram is developed provides an expedient method of ensuring that information collected is not lost or forgotten and should expedite the analytical process. Difficulty in completing fields in the form is a
69
strong indicator that the task is not completely understood and needs to be revisited in the analysis. Table 25 shows a Task Description Table for the F3 Pair Task Meld Radar which has not been decomposed further. Consequently, no sub-tasks are listed and the plan field is left blank. Table 26 shows the Task Table for the Detect bandit BVR task from which the Meld Radar task was decomposed. A point to note is that information from the lower table (such as assessment measures) can be aggregated up into the table for the higher level task. Table 25 Task Description Table for F3 Pair Task 1.2.5 Meld Radar
Task: 1.2.5 Meld Radar Purpose: Both WSOs need to have the same radar picture and confirm that they have both identified the same aircraft as the bandit in order to plan and execute the intercept effectively Initiating condition: Bandit located Terminating condition: Melded radar pictures Sub-tasks and participants: L-WSO, W-WSO Plan: N/A Teamwork Description: The WSO who has located the bandit has to communicate the bandit location to the other WSO, and they then have to ensure that they are both identifying the same aircraft as the bandit. Inputs External Content/Nature, Source & Mode Target Manoeuvre Bandit Fighters Radar pictures radar, JTIDS display - JTIDS Internal Products External Internal Other Outcomes: Time taken is time available to bandit to break radar lock and manoeuvre Critical Errors and Consequences: Slow radar meld gives bandit more time to break radar lock and evade or move into an offensive position (loss of tactical advantage by F3 pair) Assessment measures and data requirements: Time taken to meld radar pictures requires recording of radar pictures, recording of WSO comms during meld. Standard: Radar meld achieved accurately and sufficiently quickly as not to lose tactical advantage. Communication between WSOs Content/Nature, Destination & Mode Melded radar pictures - radar
70
Table 26 Task Description Table for F3 Pair Task 1.2 Detect Bandit BVR
Task: 1.2 Detect Bandit BVR Purpose: The bandit has to be located in the patrol area in order to intercept it Initiating condition: On arrival in the search area Terminating condition: When the bandit has been located, or if the formation becomes defensive or if bingo fuel (fuel required to return to base) is reached Sub-tasks and participants: 1.2.1 L-WSO Allocate radar search bands 1.2.2 L-WSO, L-P, W-P Manoeuvre formation 1.2.3 L-WSO, W-WSO Liase with fighter Controller (FC) 1.2.4 L-WSO, W-WSO Locate bandit 1.2.5 L-WSO, W-WSO Meld radar Plan: After radar search bands have been allocated (1.2.1) the formation is manoeuvred (1.2.2) whilst liaison with the FC (1.2.3) and location of the bandit (1.2.4) take place. Once the bandit is located the radar meld (1.2.5) takes place. Teamwork Description: The main aspect of team work is communication between the WSOs as they search the airspace for the bandit. The radar meld is the critical phase of communication once the bandit is detected. Inputs External Content/Nature, Source & Mode Target location from the FC via radio/JTIDS Vectors to target from the FC via radio Target location via radar display Target manoeuvre Internal Products External N/A Content/Nature, Destination & Mode Request for target information to FC via radio Target location to FC via JTIDS/radio Internal Melded radar pictures
Other Outcomes: Fuel is consumed during the search and aircraft location changes. Time taken for the radar meld is time available to the bandit to break radar lock evade or move into an offensive position Critical Errors and Consequences: Slow radar meld gives bandit more time to break radar lock and evade or move into an offensive position (loss of tactical advantage by F3 pair) Assessment measures and data requirements: Efficiency and effectiveness of search requires recording of manoeuvre of F3 pair and bandit and radar pictures. Standard: Systematic search conducted in accordance with SOPs Time taken to meld radar pictures requires recording of radar pictures, recording of WSO comms during meld. Standard : Radar meld achieved accurately and sufficiently quickly as not to lose
71
Task: 1.2 Detect Bandit BVR tactical advantage
7.4.1.5 Task Role Matrix The Task Role Matrix provides a simple look up table of which roles are involved in which tasks and sub-tasks. This can be useful for analysing teamwork and can inform training overlay analysis An example Task Role Matrix is shown in Table 27. Indenting sub-tasks and sub-subtasks in the task listing aids clarity. Identifying which sub-team an individual is in is also useful as interactions across sub-team boundaries become more obvious. In this instance, the table clearly shows that the Leading WSO is involved in all of the tasks listed in the table fragment and that many of these involve the Wingman Crew. Table 27 Task and Role Matrix Example
Roles Participating Task List Lead-Crew L-P 1.1 Check for Bingo Fuel 1.2 Detect Bandit BVR 1.2.1 Allocate radar search bands 1.2.2 Manoeuvre formation 1.2.3 Liaise with Fighter Controller 1.2.4 Locate bandit 1.2.5 Meld radar 1.3 Check if Defensive 1.3.1 Check wpns and defensive aids states 1.3.2 Evaluate tactical status 1.4 Engage Bandit BVR 1.4.1 Allocate lead 1.4.2 Agree tactics 1.4.3 Intercept bandit 1.4.3.1 Give vectors to pilot Etc. X X X X X X X X LWSO X X X X X X X X X X X X X X X X X X X X X X X X X X X X WingmanCrew W-P X X W-WSO X X
72
7.5 Capture Environmental Task Demands

Capturing an overview of the environmental task demands provides useful background to the analysis at this stage as it helps conceptualise the task. The completion of an Environmental Task Demands table provides a convenient format for recording key information. An example Environmental Task Demands Table is shown at Table 28. Table 28 Example Environmental Task Demands Table
Scenario Reference Environmental Demand Name/Reference number of the scenario for which the demands are being described. Significance Rating (H/M/L) Threat H Bandit fighters are armed with radar guided and heat seeking missiles and radar, posing a lethal threat both BVR and in visual range. Bandit bombers are equipped with heat seeking missiles and pose a lethal threat in visual range Performance pressure is high because any error may result in the lethal threat posed by the bandits being realised Air combat intercepts happen in a short time frame given that the closing speed of the fighters is in the order of 1000 knots. From detection of a target at 100 nm to the completion of a visual fight may be a matter of minutes The crews have to operate complex systems whilst making tactical judgements during fast moving intercepts and can reach the limit of their capacity during an intercept Information sources include: Radar, RHWR, JTIDS weapons systems display, aircraft systems displays, flight instruments, intercom, radio and the visual scene All the sources listed above may be providing necessary information at the same time If the radars are configured differently in each aircraft and the scan patterns between aircraft are uncoordinated, the overall view of the search space may be incomplete. Air combat is a highly dynamic, fast moving environment where fighter status can change from offensive to defensive in a matter of seconds. Team co-ordination within crews and between crews is fundamental to the execution of intercepts Air combat manoeuvring can involve turning G-forces of 7- 9 G making it challenging to operate weapons and aircraft systems There are 5 auditory sources: intercom, radio, RHWR warnings and aircraft systems warnings Radar, RHWR, JTIDS weapons systems display, aircraft systems displays, intercom, radio and the visual scene, Radar and the visual scene Description of how demand occurs
Performance pressure Time pressure
H H
High workload
Multiple information sources High information load Incomplete, conflicting information Rapidly changing, evolving scenarios Requirement for team coordination Adverse physical conditions Auditory overload/ Interference Visual Overload
M M
H H M M M
73
7.6 Teamwork Analysis

During the TCHTA the basic mechanics of the teamwork involved in the task have been determined. This stage of the analysis captures the higher order teamwork process priorities for the team/collective tasks and consolidates the descriptions of teamwork interactions by role.
7.6.1 Teamwork Process Priorities

The teamwork process priority table as shown in Table 29 facilitates the capture of the critical teamwork processes. Judgement is required as to what level of task (TO) process priority tables are constructed for. The guidance is to complete the tables at as high a level as possible as their main purpose within the TCTNA is to inform the definition of scenarios. They will also be of use during training design to inform assessment priorities for teamwork processes. Table 29 Example Teamwork Process Priority Table
TO: BVR intercept of multiple bandits Teamwork Processes Task coordination Workload management Information coordination Resource coordination Collaborative problem solving Collaborative planning Conflict management Priority (H/M/L) H L H M H H L Determining the most appropriate intercept tactics is a key success factor The plan has to be determined by both crews in the shortest possible time Radar meld and multiple target discrimination is fundamental to a successful intercept. Multiple aggressive fighters provide the greatest challenge. Task conditions/environmental requirement for the process task demands that create the
Pairs tactics are conducted in a highly dynamic environment and coordination is fundamental to success
7.6.2 Teamwork Interaction Analysis by Role

Teamwork interactions are the low-level observable behaviours of teamwork that occur between two team members. It therefore makes most sense to capture the priorities for interactions by role for situations where training is occurring at a team level. When training is aimed at a higher collective level, collecting this level of detail would be merited if collective level operation has a particular impact on members of a particular team or sub-team. The Teamwork Interaction Table as shown in Table 30 provides a means of recording the appropriate information. Supporting KSAs and taskwork can be
74
captured as appropriate. The example in Table 30 is for the wingman WSO. Recording the supporting KSAs that are required facilitates a cross check that individual training provides the necessary underpinning KSAs. The resource allocation line has been left blank as resources cannot be passed between individuals in a tandem, two-seat aircraft cockpit. It is more meaningful simply to think of passing responsibility for using available resources (task allocation) such as use of radios or defensive aids. Table 30 Teamwork Interaction Table
Role Teamwork Interactions Performance Monitoring Wingman WSO Actions Supporting KSA / Taskwork
Monitoring lead aircraft tactical advantage during BVR engagements
Pairs tactics
Task Allocation
Giving evasive action directions to pilot during visual engagements
Air combat manoeuvering, fighter tactics, threat assessemnt
Resource Allocation Reporting radar contacts to formation leader. Communicating radar picture to Lead WSO during radar meld Employing defensive aids during visual combat
Communication
Standard voice procedure
Backup Behaviours
Defensive aids employment parameters
7.7 Training Gap Analysis

Having developed a complete description of the tasks that the team or collective organisation has to perform, the next step is to identify which tasks potentially need to be trained and what their relative priorities are for training. If resources or time are limited then it is possible that only the highest priority tasks will be trained. The do nothing option has to be considered, in other words the acceptability of providing no training has to be evaluated. If it is determined that doing nothing is an acceptable course of action, then the remaining stages of analysis are not required. A positive decision to train necessitates the specification of training objectives and the subsequent analysis of the training overlay and the training environment. In the individual training context, the term gap analysis is used because the issue can be described as determining the difference or gap between an individuals current capability and the capability required to carry out the task. Deficiencies in legacy training may also widen the gap or difference between the input standard and the required output standard determine what must be trained. Training priorities may be determined by analysis of the
75
difficulty, importance and frequency of the tasks concerned. Tasks of high difficulty and importance would be high priority candidates for training with tasks of low difficulty and importance being of the lowest priority. The frequency of conduct of the task is also relevant in that there is the possibility that high frequency tasks may have some potential for being trained on the job. This is meaningful in the individual training context as there is the potential for mentoring and instruction by a more experienced operator in the job context. The collective training context is more complex. Typically a team or collective organisation will have a mix of people at different levels in the organisation with a variety of backgrounds and experience levels. This is further complicated by the fact that often people are posted in and out of the organisation at different times, so the overall experience level of the group may be constantly changing. Therefore, defining an input standard is problematic. Similarly, training on the job is more problematic as an idea since there is no team to mentor and train the team itself.
7.7.1 The Risk Management Approach

The approach recommended for identifying priorities for team and collective training is to use a risk management approach predicated on the do nothing option. In other words, the risk associated with not providing training for a given task is estimated based on the likelihood of errors being made and the severity of the consequences of those errors. Those tasks with a high level of risk associated with them not being trained would be high priority tasks for training. From a risk management perspective, the decision as to whether or not a task requires training is essentially a statement as to whether or not training is required as mitigation for the perceived risk.
7.7.2 The Training Priorities Table

To apply the risk management approach it is necessary to construct a table containing the following entries for each task: Critical errors Likelihood of each error Consequences of each error Severity of each error Risk associated with each error The decision if training is required in mitigation
A suggested format for such a table, described here as a Training Priorities Table, is shown in Table 31. The information concerning the critical errors associated with each task is already available in the Task Description Tables produced during Training Task Analysis and simply needs to be copied across. Guidance for rating the likelihood and
76
severity of errors is shown in Table 32, in the form of factors affecting the likelihood of an error and the indicators of high severity errors. These ratings, along with the assessment of the overall level of risk and recommendations about the requirement for training as mitigation are matters of subjective judgement and require SME input.
77
Table 31 Example Training Priorities Table

Task Critical Error Likelihood (H, M, L) Consequences Severity (H, M, L) Risk (H, M, L) Training required as mitigation (Y, N) 1.0 Destroy Bandit Fighter BVR Ineffective search Slow radar meld Poor use of pairs tactics Ineffective search Slow radar meld 4.0 Destroy Bandit Bomber in Visual Range Poor use of pairs tactics L M H L M H Bandit not detected and able to attack Bandit has additional time to evade or take the offensive Bandit able to evade and take offensive Bandit not detected and able to continue to target Bandit has additional time to evade Bandit able to evade and take offensive H M H M M H M M H L M H Y Y N Y
2.0 Destroy Bandit Fighter in Visual Range 3.0 Destroy Bandit Bomber BVR Range
78
Table 32 Factors Affecting the Likelihood of an Error and Indicators of High Severity Consequences
Factors Affecting the Likelihood of an Error Task complexity (the number of steps within the task). Degree of teamwork required (the required degree of communication between team members in task completion is a reasonable proxy for this). Judgement of Task success - whether the task can be judged to have been completed successfully by team members (if this is not the case, there is no possibility for team performance self-correction). Task recoverability/reversibility there are examples of tasks which are difficult (such as threading a needle) however because lack of success in task execution can be easily judged and the task reattempted, this reduces the likelihood of an uncorrected error occurring. Time pressure (task delay tolerance) operating under time pressure increases the likelihood of error. Task performance expected under conditions of stress or physical fatigue is more prone to error High task loading - occurs if the task is performed concurrently with other tasks. Information Availability if information to perform the task may be incomplete or of uncertain quality. Time after Training time between training and task execution. Mission Failure Loss of capability Injury to personnel Damage to essential equipment Collateral damage or injury to 3rd parties Breach of law or military regulations (such as ROE being improperly applied). Significant financial loss Indicators of High Severity Consequences
79
7.8 Team/Collective OPS and TO Development

Operational Performance Standards (OPSs) and Training Objectives (TOs) have essentially the same format of performance, conditions and standards. The difference between the list of OPSs and the list of TOs is that the OPS list will contain all tasks whereas the TO list will only contain TOs for those tasks that are to be trained. Because of the way that the analysis has been structured and recorded, all of the data is already available to construct the list and much of it can be simply copied from the appropriate tables. The performance statements and standards can be copied from the Task Description Tables directly. One judgement that has to be made is the level of decomposition of the objectives that is presented. The HTA process yields a detailed decomposition of the tasks which could be used to populate an instructional scalar that covers both training objectives and enabling objectives. It may be appropriate to limit the OPS list and the corresponding list of TOs to the top level of the decomposition. The detail is not wasted, as it provides the training designers with the enabling objectives and saves further analysis. The conditions for the tasks are in fact defined by the system context descriptions the description of each environmental element in the Environment Description Table. Noting that not all elements will necessarily apply to all TOs and OPS statements, an expedient way of dealing with the complexity of the environmental conditions is to copy the element descriptions into a numbered list and refer out to the list.
7.8.1 Linking Tasks and Training Objectives to Mission Task Lists

There is a current aspiration to generate a coherent structure to link collective task performance and the associated training objectives to the tasks listed in the Mission Task Lists (MTLs) so that the contributors to Operational Performance can be identified and training costs justified. It is also of significance from the perspective of change management, facilitating the identification of changes that are required to training as a consequence of changes to the MTLs.
80
Figure 26 General mapping of Tasks to METs The issue which this presents is that many of the tasks and related training objectives may well link to many tasks listed in the MTL. This is illustrated diagrammatically in Figure 26. The consequence of this issue is that many checks have to be made to identify all the linkages. To put the magnitude of this issue into context, in each of the QE Class Role Group summaries prepared by the Aircraft Carrier Alliance there are in the order of 110 tasks identified for Air Traffic Control (ATC) roles and approximately 310 listed tasks in the MTL(Maritime) (MTL(M)). Potentially, in excess of 30,000 cross-checks would have to be made to determine how the tasks link to the MTL(M) Careful inspection of the MTL(M) shows that there are five tasks which the ATC tasks support (see Figure 27), reducing the number of cross-checks required to 550. In information systems engineering this problem is resolved with a linking object (in database design this is a join table) which avoids the duplication of redundant information. In the ATC example the linking object which connects all ATC collective tasks is the function that is delivered through the synergy of all ATC collective tasks in this case the ATC Service itself. Multiple ATC collective tasks (launch, recovery, handovers, overflight etc.) support the function Operate ATC Service. Likewise the Operate ATC Service contributes to multiple military tasks. Figure 27 expresses this idea graphically.
81
Figure 27 Mapping of Example ATC Role Group Summary Tasks to Military Tasks in the MTL(M) This approach avoids the situation of having to cut and paste all the MTL(M) references into each of the ATC task descriptions and training objectives. All that is required is to identify which function is supported by the collective task, and then what METs that function (in this case Operate ATC Service) supports. Therefore, the recommended approach is to identify the top-level functions, under which the tasks and training objectives can be grouped, and map these to the MTLs.
82
8 Training Overlay Analysis

8.1 Introduction
The Instructional Overlay is the totality of all instructional methods and functions and associated hardware, software and communication channels which deliver those instructional functions. For example the instructor station in a flight simulator constitutes part of the instructional overlay as this is the device that generates alterations to the task environment (e.g. the hardware and software that enables engine fires to be simulated and weather to be selected). The purpose of training overlay analysis is to determine appropriate instructional methods for the tasks to be trained, the instructional functions that have to be supported to deliver the methods identified and the specification of how these instructional functions have to be supported. In individual training the selection of instructional methods and the identification of instructor tasks is relatively simple, often with a single instructor employing a range of methods with a group of students. It becomes more complicated when individual training has to take place in a group context as more instructors and more resources may be required. For example, training platoon commanders usually requires students on the course to act as platoon members whilst one individual is practising the platoon commander role. Such training requires a training area, people to role-play enemy and multiple instructors to run the training. Team and collective training takes this complexity to another level. Taking the example of Fleet Synthetic Training which is run by the US Navy for training Carrier Battle Groups which RN warfare teams and battle staffs participate in, the training audience is approximately 2000 strong and the instructional and support staff number in the order of 250. Of the 250 instructional and support staff, 50 are instructors engaged in observing the teams at work on-board ship or in warfare team simulators. Another instructional team manages the running of the scenario. They in turn are supported by a team of role players who interact with the training audience and manipulate the elements in the simulated environment (such as enemy vessels and aircraft) to cause the injects to happen. The approach described in this chapter is designed to provide a logical method for both determining appropriate instructional strategy and identifying instructor tasks.
8.2 Instructional Theory

This section provides a short overview of instructional theory that can easily be applied to Team and Collective Training.
8.2.1 Clarks Content-Performance Matrix (Clark, 2008)

There are a number of taxonomies available that guide the classification of training content but not all provide related guidance on suitable elaboration strategies. Clarks
83
Content-performance Matrix both guides the classification of content and has related guidance on elaboration strategies (Clark, 2008). The matrix is reproduced at Table 33. Table 33 Training Content Performance Matrix with Application Level Elaboration Strategies, adapted from Clark (2008)
Content Type Performance Remember Facts Concepts Remember the facts Remember the definition N/A Classify new examples Apply N/A Provide the definition Provide examples Provide counter examples Provide practice examples for classification Process Remember the stages Solve the problem Make inferences Explain key concepts of the process Explain the stages of the process Provide practice exercises requiring application of process knowledge Assessment by observation of performance Procedure Remember the steps Perform the procedure Clear statement of the steps of the procedure, with illustrations A demonstration of the procedure Hands on practice, using the actual equipment, with feedback Assessment by observation of performance Principle Remember the guidelines Perform the task Solve problems State guidelines or show examples of guidelines being implemented Present nonexamples Practice application of guidelines in realistic circumstances, with feedback. Assessment by observation of feedback Elaboration Strategy for Apply
What makes the matrix particularly useful is that elaboration strategies are offered for both remembering content and applying it. The table shows a high level synopsis of the recommended elaboration strategies for application, as team training is focused on skills application. Team training is typically concerned with teaching the application of procedural skills and the application of principles (such as doctrine). The point of note is that the recommended elaboration strategies require the teaching of the underpinning knowledge before practice takes place.
84
8.2.2 Part-task training
Figure 28 Part Task Training Sequence (adapted from Wickens and Hollands, 2000) Part-task training is a familiar approach used widely in individual training. A typical parttask training sequence adapted from Wickens and Hollands (2000) is shown in Figure 28, which illustrates subtask A being trained, followed by subtask B and then the whole task (A and B together) being trained. The key criterion for the utility of part task training is that it is only successful if the subtasks are loosely coupled. If there is a high degree of interconnection between the tasks then part task training is unlikely to be suitable. The part-task approach is potentially of use in team and collective training where difficult subtasks exist that are not highly connected to other subtasks and could therefore be practiced separately. Such tasks can be identified from the TCHTA diagram and Tasks Description Tables. The difficulty of the task is reflected in the critical errors and consequences fields and the description of the teamwork requirements, and the degree of connection to other tasks can be evaluated based on the complexity of the plan that describes its relative sequencing (also shown in the Task Sequence Diagram) and the inputs from other tasks.
8.2.3 Reigeluths Simplifying Conditions Method (Reigeluth, 1999)

The essence of Reigeluths Simplifying Conditions Method (SCM) is that, when training complex tasks, the whole task should always be taught and practiced, but in increasing levels of difficulty (Reigeluth, 1999). The initial scenario would be as simple as possible (such as driving a car in a wide open space). The diversity and complexity of scenario elements would gradually be increased leading to scenarios representative of the most complex situations (such as driving a car through a busy town at rush hour). This type of training sequence is illustrated in Figure 29.
85
Figure 29 Simplifying Conditions Method Training Sequence (Adapted from Reigeluth, 1999) Whilst the detailed application of SCM is most pertinent to the detailed training design phase, it has relevance at a high level during TNA as there may be a need to specify a simplified environment for the early stages of task practice.
8.2.4 Team Training Methods

Salas and Priest (2005) identify three basic methods for the delivery of team training: 1. Information based. 2. Demonstration based (e.g. video). 3. Practice-based (e.g. guided practice). These three methods are consistent with the approaches recommended by Clark (2008) for the elaboration sequences for teaching principles procedures and processes, with information and demonstration forming initial instruction to be followed by practice. Salas and Priest (2005) also identify the following key principles of training: Team training should lead to teamwork skill development (e.g. leadership, adaptability). Both process and outcome measures are needed for teamwork diagnosis. Simulations should allow team members to experience some alternative course of action. Response strategies, provided during training, should be linked to cues in the environment and from other team members.
86
Team members should be provided sufficient opportunities to interact with novel environments in order to develop adaptive mechanisms. Team training should be more than a feel good intervention. Guided practice is essential. Training should establish a mechanism to foster teamwork. Both teamwork and taskwork competencies are needed for effective team functioning.
From the TCTNA perspective, these principles underline the importance of providing representative practice environments in which the training audience are presented with credible scenarios which stress their capability to conduct both the taskwork and teamwork elements of their tasks. Furthermore, effective coaching and feedback (including After Action Review) have to be provided. The implications for this stage of analysis are that it is essential to identify the following: The critical features of generic scenarios that are required to stress the teamwork and taskwork components of the tasks to be trained. The data that have to be gathered in order to inform assessment of processes and products of team activity. The instructional tasks that have to be fulfilled to plan, deliver and evaluate the training.
8.2.5 The Relationship between Tasks and the Operational Environment

There is a significant relationship between TOs and the operational environment that has to be understood from the training perspective. Different tasks require inputs from and provide outputs to different elements in the environment, as captured in the context descriptions at the start of the Team Task Analysis Phase. The corresponding TOs will therefore require representations of these sets of environmental elements. This is illustrated in Figure 30 which shows the mapping of tasks to the operational environment.
87
Figure 30 Mapping of TOs to the Operational Environment Each of TO 1 to 4 shown in the diagram require different but overlapping sets of elements in the operational environment. TOs 1.4 and 3.1 also have overlapping requirements but for much smaller subsets of environmental elements. The accurate identification of part task training requirements and simplified conditions opportunities ensures that overly complex training environments are not specified.
8.3 Instructional Method Selection

Team tasks can typically be considered to involve carrying out procedures and processes and applying principles to solve problems in both planning and the execution of plans. The general instructional sequence of providing initial instruction, followed by opportunities to practice the required skills in a realistic environment with feedback on performance, and culminating in assessment still holds true. Generally practice and instruction will take place in the same environment and are closely linked. It therefore makes sense to consider the methods for initial instruction and the methods for practice and assessment as two separate components.
8.3.1 Selecting Methods for Initial Instruction

From a task perspective, the general elaboration strategies for teaching processes, principles and procedures require the teaching of the appropriate knowledge components underpinning them. If this is not undertaken and training consists of practice followed by assessment, trial and error could prove to be an expensive way of developing an understanding of these underpinning knowledge elements. For example, classroom-based training on standard operating procedures could provide an invaluable opportunity for the team to develop a shared mental model of how the team as a whole should be operating
88
and how the functions of sub-teams need to be co-ordinated. Similarly, instruction on the application of doctrine, including such matters as the application of Rules of Engagement in the context of a particular theatre of operations, provides the team with an opportunity to develop shared mental models of how problems should be addressed and is likely to be time well spent. The initial instruction phase provides a key opportunity for addressing the teamwork aspects of the tasks to be trained. Discussion of the priorities for teamwork interactions and processes in the light of environmental task demands has the potential to provide the team with sound mental models of how the team should function. Table 34 provides suggestions for the content that should be covered in the initial instruction related to teamwork objectives. Table 34 Suggested Content for Initial Instruction on Teamwork
Teamwork Elements Level 1 Team member KSAs Level 2 Teamwork Component Interactions (TCIs) Priorities by role for : Communication Performance Monitoring Backup behaviours Resource allocation Task allocation Level 3 Teamwork Processes Level 4 Team Properties
The need for shared mental models of the task and how the team operates and communicates
The priorities for : Task Coordination Workload management Information Coordination Resource coordination Collaborative problem solving Collaborative planning Conflict management
The organisational structure and relationships of roles The significance of adapatability and cohesion in the conduct of the teams tasks in the light of the environmental task demands
Given the nature of the tasks in the light of the environmental task demands,
Having identified the topics that require initial instruction, appropriate methods need to be identified. Classroombased lectures and discussions are likely candidate methods. Others such as demonstrations may be possible depending on the nature of the task being trained.
89
A suggested output from this phase of analysis is an Initial Instruction Table. An example Initial Instruction Table is shown at Table 35. Table 35 Example Initial Instruction Table for F3 Pairs Training
Training Objective 1.0 Destroy Bandit Fighter BVR Topic for Initial Instruction Pairs tactics for engaging radarequipped bandits BVR Principles for coordinating a pairs engagement 2.0 Destroy Bandit Bomber BVR 3.0 Destroy Bandit Aircraft in Visual Range 4.0 Identify key teamwork KSAs for the conduct of pairs intercepts Pairs tactics for engaging non radar-equipped bandits BVR Pairs tactics for visual attacks Method Classroom lecture and discussion with illustrations of good and bad examples of the application of tactics
Critical teamwork behaviours in pairs intercepts
Classroom lecture and discussion with illustrations of good and bad examples of the application teamwork principles
8.3.2 Selecting Methods for Practice and Assessment

In general, the most likely method for practice of team and collective tasks will be the practice of the task in a representative environment with assessment based on observation of the team carrying out the tasks with formal debrief at the end of appropriate phases of activity. However, there is a need to identify sub-tasks which require part-task training and tasks or sub-tasks that would benefit from practice in simplified conditions. 8.3.2.1 Identification of Part-Task Training Requirements Consideration needs to be given to whether or not it is necessary or appropriate to train some subtasks separately. Candidate subtasks for separate training would include: a. Sub-tasks which do not require the whole team. If there are sub-tasks that only require a sub-team it may make sense to train those tasks separately as a precursor to whole team practice. The Task Role matrix provides a simple lookup table for identifying subtasks which fall into this category. b. Sub-tasks which have different environmental requirements. If there are subtask components which require only a sub-set of the environmental elements it may make sense to train these tasks separately from the perspective of efficient training resource utilization. Such subtasks can be identified from the Input and Output fields of the Task Description Tables. c. Sub-tasks which are difficult and require additional practice. Tasks which are considered to be particularly difficult may well benefit from additional practice if it is considered sufficient practice cannot be achieved during practice
90
of the whole task. Such subtasks can be identified from the Typical Errors and Consequences fields of the Task Description Tables. Candidate subtasks for separate training may well fall into more than one of these categories. An example would be the training of a Battle Staff to apply the Combat Estimate. The development of a Combat Estimate is based around answering seven key questions that have to be addressed when formulating an operation plan. During the execution phase of an operation the Battle Staff have to simultaneously control the execution of the plan, adjust the plan in response to events during execution (which may require reapplication of the Combat Estimate process) and apply the Combat Estimate process to further phases of the operation. During execution of the plan inputs are required from subunits who are executing the plan which constitutes a more complex environment than that for the development of the plan. The development of the combat estimate is complex and is a task which merits additional practice. 8.3.2.2 Identification of Simplifying Conditions Method Requirements Consideration should be given to identifying where there is benefit to be gained from practicing tasks in simplified conditions prior to practicing the tasks in the full environment. This is particularly applicable to complex tasks and tasks where there are significant environmental task demands. In such cases there is likely to be a high degree of teamwork required and there may need to be training effort focussed on the teamwork aspects of the task. An example from the F3 pairs training task would be the practice of intercepts against bandit fighters in visual range. This task requires operation of all the aircraft systems and air combat manoeuvring which can result in the crews experiencing sustained G-Forces of up to 7-G or more. It is particularly challenging when conducted at low-level because of the inevitable risk of collision with the ground or sea. Practicing the task in simplified conditions without the physical stressors, the element of danger and the need to deal with other aircraft systems could allow the students to focus on the key issues of the application the appropriate tactics and the teamwork interactions and processes necessary to carry out the intercept effectively. 8.3.2.3 Assessment and Feedback Methods Given that the general approach for team and collective training is to facilitate practice of the required teamwork and taskwork skills in a representative environment, assessment is essentially based on observation of team performance. The detail for assessment has already been captured in the Task Description Table for each task identified in the TCHTA. There are a number of options for the provision of feedback which include: Coaching of individuals during task performance Coaching of sub-teams during task performance
91
Hot debriefs at the conclusion of an exercise component or phase After Action Review of whole team performance at the end of an exercise phase.
8.3.2.4 Practice and Assessment Methods Table The Practice and Assessment Methods Table provides a simple record of the methods selected for each training objective, identifying whether the whole task will be trained in a representative environment alone or if a simplified environment will be required. Any subtasks that require part-task training are also identified. Probably the most challenging aspect of completing this table is the estimation of the time that is required for training. This is a significant value because it will impact on the cost of training. There are no convenient formulae or even heuristics to guide this estimation. The best guide is the time that similar training takes and SME instructor estimations. Constraints on course duration if there are any and on resource availability (such as aircraft training hours available) have to be taken into consideration.
92
Table 36 Example Practise and Assessment Methods Table

Training Objective 2.0 Destroy bandit fighter in visual range Practice method 1. Simplified conditions practise of intercepts Assessment method Observation of task performance Evaluation of recorded data of missile launch parameters Observation of task performance Evaluation of recorded data of missile launch parameters Feedback Method Hot debrief after each intercept in a training sortie Formal AAR with all exercise players post sortie Hot debrief after each intercept in a training sortie Formal AAR with all exercise players post sortie 7 hours Time Estimate 5 hours
2. Practice of whole task in representative environment
93
8.3.3 Training Scenario Specification

A critical part of the training overlay is the nature of the scenarios that are delivered in which the training audience practices their tasks. Noting the guidance on team training in section 8.2.4, it is imperative that the scenarios are representative and credible. Furthermore, they should reflect the environmental tasks demands identified for the task during the Team/Collective Task Analysis. Whilst the development of detailed scenarios is the domain of training design and subsequent preparation for specific training events, it is necessary to capture the key features of required scenarios in a generic way as these inform the specification of the training environments at the next stage of analysis. Any potential training environment must be capable of delivering appropriate scenarios or it will serve no useful purpose for training. That said, it may well be both inefficient and inappropriate to attempt to provide the full operational environment for training each task (hence the consideration of simplified conditions environments). There are five sources of information from the task analysis phase that need to be considered when developing training scenarios, illustrated in Figure 31.
Figure 31 Information Inputs to Generic Scenario Specifications The generic scenario specifications provide the baseline information for the development of the scenario. The task descriptions amplify this as they capture the inputs that have to be provided and the outputs that have to be delivered. However, it is the environmental task demand information, in conjunction with the information about the types of error that are likely, that provide the characterisation of what makes the task difficult. The scenario should contain elements that place the appropriate demands on the team. In the case of F3 Pairs training, factors such as visibility, difference in altitude between the bandits and the fighters (a bandit above the fighters has a tactical advantage), and the aggressiveness of the bandits are significant elements which ideally should be controllable. It is also necessary to consider the teamwork elements that are priorities as this may influence the scenario requirements. Communication, performance monitoring, backup behaviour, coordination and task allocation being significant for a pairs
94
intercept. Appropriate bandit tactics can generate the requirement for backup of the leader by the wingman. It may be that the generic scenarios identified at the start of the analysis process can each be amplified to ensure there is sufficient detail to inform the description of the training environment (with detail such as what control of the elements is required and how their numbers and actions may vary). Recording which training objectives are covered by which scenario can provide a useful cross reference of coverage of training objectives. It may also be appropriate to develop scenarios for aggregations of training objectives or even individual objectives if they are likely to require different training environments, such as live firing. It is suggested that scenario specification is carried out in two stages. The first stage is to develop a narrative description of the properties of the required training scenario. A suggested format for recording these is the Training Scenario Table shown in Table 37. Table 37 Example Training Scenario Table
Training Scenario Description 1 Training Objectives 2.0 Destroy Bandit Fighter in Visual Range A single bandit fighter should enter into visual range of the fighter pair and take appropriate aggressive defensive action to counter the attack using air combat manoeuvre and flares against heat seeking missiles. If the Tornado pair loses tactical advantage then the Bandit should counter attack taking heat seeking missile shots. Visual engagements should be conducted at both medium and low level and occur in degraded visibility as well as high visibility conditions. Bandit tactical advantage from initial positioning and altitude and aggressiveness of bandit tactics should be controllable.
This then needs to be mapped into the Environment Description Table as shown in Table 38. This mapping facilitates the specification of the training environments.
95
Table 38 Environment Description Table Entries for Task Scenario Requirements

Element Fighter Controller Bandit Fighters Bandit Missiles Bandit Bombers Aircraft Weather Terrain
Training Scenario 1 Simplified conditions practice Not Required Bandit fighters take evasive action using air combat manoeuvring and flares if defensive and counter attack taking heat seeking missile shots if offensive Bandit initial tactical advantage and aggressiveness of bandit tactics should be variable Full task practice Not Required Bandit fighters take evasive action using air combat manoeuvring and flares if defensive and counter attack taking heat seeking missile shots if offensive Bandit initial tactical advantage and aggressiveness of bandit tactics should be variable Heat seeking missiles Not required All systems and effects of G required Clouds, haze, precipitation , sun position and light levels Ground topology. Heat seeking missiles Not required Effects of G not required Operation of aircraft systems other than weapons systems and flight controls and displays not required Clouds, haze, precipitation , sun position and light levels Ground topology.
96
8.4 Instructional Task Identification

At this stage in the analysis it is necessary to identify the generic instructor tasks that will have to be fulfilled in order to deliver the training according to the methods identified. How these are actually instantiated will depend on the actual environments that are selected. Consideration also has to be given as to what elements in the instructional environment have to be configured and controlled by the instructors and the requirements for data capture during scenario execution.
8.4.1 Instructor Task Table

It is suggested that an Instructor Task Table is developed to provide a description of the instructor tasks and identify requirements for the training environment to support the training overlay. The exact nature of the task will be dependent on the nature of the task being trained and the task environment. The following are suggested as generic headings under which the table entries can be developed: Deliver Initial Instruction Deliver Practice o Prepare Scenario o Deliver Scenario Configure the scenario Control Scenario Change Scenario
Assess practice o Monitor and assess individual and team performance o Monitor and assess performance outputs o Provide feedback during task performance o Debrief practice
As the exact nature of each of these tasks will vary according to the training objective being taught it is suggested that the description of the tasks be broken down by training objective. An example of an Instructor Task Table and illustrative entries is shown in Table 39.
97
Table 39 Example Instructor Task Table Format and Entries

Instructor Task 2.0 Deliver Practice 2.2 Deliver Scenario 2.2.1 Configure the scenario Simplified conditions practice of TO 2.0 Set the weather conditions and the geographical area of practice. Define bandit profiles 3.0 Assess Practice 3.2 Monitor and assess performance outputs Simplified conditions practice of TO 2.0 Monitoring of aircraft manoeuvre during intercepts Visualisation of the manoeuvre of the F3 pair in 2D and 3-D should be available for debrief. Monitoring and recording of intercom chat and radio transmission from both crews required Monitoring and recording of visual scene (out of window) 3.4 Debrief practice Simplified conditions practice of TO 2.0 Use visualisation of the manoeuvre of the F3 pair in 2-D and 3-D for debrief. Description
8.4.2 Training Overlay Requirement Specification

Having identified the instructor tasks, the descriptions can be examined to identify the requirements for the training environment. Requirements identified, such as defining the bandit profiles and the monitoring of aircraft manoeuvre in the examples given in Table 39 can be mapped directly into the Environment Description Table as illustrated in Table 40. This completes the analysis of the training overlay.
98
Table 40 Environment Description Table Training Overlay Requirements Entries

Element Fighter Controller Bandit Fighters Bandit Missiles Bandit Bombers Aircraft Weather Terrain
Training Objective 2.0 Destroy Bandit Fighter in Visual Range Simplified conditions practice Overlay requirements Not Required Bandit fighters fly a predefined profile and counter attack with a degree of aggressiveness to match student performance. The instructor running the intercept should be able to change the profiles and bandit tactics as required during the sortie. Replay of bandit manoeuvre, missile launches and use of defensive aids required for debrief Heat seeking missile trajectory and effects required for debrief Not required Monitoring of aircraft manoeuvre during intercepts Visualisation of the manoeuvre of the F3 pair in 2-D and 3-D should be available for debrief Monitoring and recording of intercom chat and radio transmission from both crews required Monitoring and recording of visual scene (out of window) Clouds, haze, precipitation, sun position and light levels should be capable of being preset by the instructor Sea or land selectable by the instructor.
99
9 Training Environment Analysis

9.1 Introduction
Training environment analysis is conducted in three stages. The first stage is the specification of the required environments. The second stage is the identification of environment options and the third stage is the detailed definition of putative environments.
9.2 Training Environment Specification

Training environment specification is achieved by first rationalising the number of training environments required and then conducting a fidelity analysis.
9.2.1 Training Environment Rationalisation

The first stage of training environment specification is to rationalise the number of training environments that need to be specified. Training environment requirements for each training objective have already been identified in the training overlay analysis phase. The aim of this phase is to identify the optimal set of training environments. Selection of optimal environment is illustrated in Figure 32 a and b. Figure 32a shows that there is a large degree of overlap between TOs 1, 2 and 3 and therefore it seems sensible to specify Training Environment 1 for the whole task provision of training for these TOs and will cater for some aspects of TO 4. Training Environment 2 provides all the environmental elements required for TO 4. In the F3 pairs example this could be equivalent for providing a training environment for all aspects of Pairs intercepts except for the full training in the use of the cannon at close range. Live firing with the cannon is an annual training requirement and is conducted on a range using towed targets. This would be analogous to Training Environment 2. TOs 1.4 and 3.1 are provided with Training Environment 3 which is a part-task training environment. Training Environment 4 shown shaded in Figure 32 represents the provision of a simplified conditions training environment for TOs 1-3. The hole in the middle of Training Environment 4 represents the set of elements common to TOs 1-3 that are omitted in the simplified conditions.
100
a.
WholeTaskandParttaskTrainingEnvironments
b.
Simplified Conditions Training Environment
Figure 32 Mapping of TOs to Training Environments
101
9.2.2 Fidelity Analysis

Having identified the required training environments, the next stage is to determine the fidelity requirements for each environment. Fidelity refers to the degree of correspondence between the training environment and the operational environment. To take a simple example, consider a training environment that requires the inclusion of a German Shepherd attack dog. If the representation of the attack dog is a one-foot tall, pink, fluffy dog which, when prodded with a sharp stick, walks sideways towards you, vigorously wagging its tail and then attempts to lick your hand, it would probably not be perceived to be a particularly credible attack dog. Furthermore, it would be unlikely to be of any particular value in training someone in how to treat such an animal. What the example does illustrate is that the central concerns for fidelity are the physical form and function of elements in the environment. Technically, these aspects are referred to as physical and functional fidelity. The challenge for fidelity specification is determining how much fidelity is required. To push the attack dog example a little further, consider the requirement for training the reactions on detecting an attack dog. From a physical fidelity point of view, one-foot tall, pink and fluffy is probably not going to do the trick. Full size, accurate appearance, a loud bark, and plenty of teeth are probably nearer the mark. From a functional fidelity perspective, how it eats its dinner from a bowl and the ability to mark its territory when encountering a lamp post are not likely to be of relevance. However, the distance at which it can detect someone by scent and the effect of wind direction on the range at which it can detect scent probably are, as is the speed at which it can run and under what conditions it attacks. A practical issue that needs to be considered is that SME input will be required. However, there will be more than one opinion on the subject. Obtaining a consensus view is advised. In the case of providing a simplified conditions environment for Tornado F3 pairs training, there were three main sets of views about the fidelity of controls and displays. Some considered generic controls and displays were acceptable, some thought that displays had to be exact but controls could be generic, and others thought that both controls and displays had to be exact replicas. The final outcome was a sound British compromise. Replica throttle, stick and radar hand controllers were procured. For the systems displays, touch screens were used with faithful representations of the key displays. 9.2.2.1 Specifying Fidelity Requirements In order to fully specify fidelity requirements for a given training environment, each element in the environment has to be considered in turn. The Environment Description Table contains all of the elements that have to be described in fidelity terms. Fidelity specification therefore amounts to making appropriate entries in the table. In the Team/Collective Training Model (Figure 14) the Task Environment is shown as being composed of five different categories of elements: a. physical environment elements b. manned system elements
102
c. systems elements d. human elements e. resource elements Different data is required for each of these types of elements. The definitions and entries for these five types of elements are considered in turn. 9.2.2.1.1 System Fidelity Requirements For the purposes of fidelity specification, a system is anything with a mix of controls, displays and output devices that the training audience has to interact with, such as warfare systems, radios, and weapons systems. Descriptions of physical and functional fidelity are required which consider the attributes in Table 41. Table 41 System Fidelity Requirements
Physical Fidelity Requirements Attribute Size Location Appearance Controls Feel Weight Motion Sound Description Does the item need to be full size or is a smaller representation acceptable? Do the controls and displays have to be correctly spatially located with reference to the operators position, or if not what is acceptable? Do the colour and texture matter? What are the critical appearance attributes? Are all the controls required, if not, which are? Does the feel of the controls have to be replicated exactly? If the system is portable does it have to be a representative weight and balance? What motion cues does it have to provide? What sounds have to be produced and to what degree of fidelity?
Functional Fidelity Requirements Attribute Format Content Response Description Does the format of displays have to be replicated exactly? Can any display content be omitted? Does system response have to be replicated exactly or if not, what elements can be omitted and what tolerance on system response is acceptable? If the system interacts with other entities in the environment what attributes must it have (e.g. an aircraft has a radar signature and heat signature)?
Appearance to other system elements
103
The appearance of the system to other elements in the environment is included to ensure that data for all interactions is captured. It is included in the functional fidelity section as it may be a dynamic attribute, for example an aircraft heat signature will vary according to thrust or reheat selection. 9.2.2.1.2 Resource Fidelity Requirements Resources are all the elements in the environment that are not human or manned systems. These include logistics elements and equipment. The attributes in Table 42 need to be considered. Table 42 Resource Fidelity Requirements
Physical Fidelity Requirements Attribute Appearance Feel Weight Sound Description Do the colour and texture matter? What are the critical appearance attributes? If the item can be touched, does the feel of the item have to be replicated exactly? If the item is portable does it have to be a representative weight and balance? What sounds have to be produced and to what degree of fidelity?
Functional Fidelity Requirements Attribute Behaviour Description What aspects of behaviour have to be produced to generate interactions with the team and to respond to interactions from the team? Information required to generate interactions with the team or respond to team interactions
Interaction information requirements
9.2.2.1.3 Human Element Fidelity Requirements Fidelity requirements for the human elements in the environment are of particular importance. In order to be able to determine if a role player can be used, it is necessary to capture the required knowledge and skills needed to generate interactions with the team and to respond to team inputs. In simple situations, such as passing radio traffic, an untrained operator could read from a script. However, in the case of a carrier strike group exercising in a synthetic environment under the control of a Maritime Component Command (MCC) the interactions are more complex and would required senior staff with command experience to play the role of a staff member of the MCC. It is also necessary to know what environmental information they require to generate inputs and responses (for example the Fighter controller in the F3 Pairs training example needs to have a dynamic, 2-D view of the tracks of both the pair and the bandits with altitude information). The attributes in Table 43 need to be considered.
104
Table 43 Human Fidelity Requirements

Physical Fidelity Requirements Attribute Appearance Language Description What aspects of physical appearance and dress are significant? What language/dialect should the person speak if they interact by voice with the training audience?
Functional Fidelity Requirements Attribute Behaviour Description What aspects of behaviour have to be produced to generate interactions with the team and to respond to interactions from the team? Information required to generate interactions with the team or respond to team interactions What knowledge and skills are required to produce the required behaviour given the information and systems provided?
Interaction information requirements Knowledge and skills
9.2.2.1.4 Manned Systems Fidelity Requirements Manned systems, such as bandit fighters, are a hybrid between resources and human elements. They appear dynamically in the environment but respond based on human decision making, knowledge and skills. If the element is an enemy vehicle, it is necessary to determine how realistic it should be in appearance or however else it is perceived and how its behaviour is determined. Table 44 illustrates the attributes that need to be considered. Table 44 Manned Systems Fidelity Requirements
Physical Fidelity Requirements Attribute Appearance Sound Description Do the colour and texture matter? What are the critical appearance attributes? What sounds have to be produced and to what degree of fidelity?
Functional Fidelity Requirements Attribute Behaviour Description What aspects of behaviour have to be produced to generate interactions with the team and to respond to interactions from the team? What information is required to generate interactions with the team or respond to team interactions? What knowledge and skills are required to produce the required behaviour given the information provided? If the system interacts with other entities in the environment what attributes must it have (e.g. an aircraft has a radar signature and heat signature)?
Interaction information requirements Knowledge and skills Appearance to other system elements
105
9.2.2.1.5 Physical Environment Elements Static features of the environment such as terrain require only a physical fidelity description whereas dynamic elements (such as rain or waves) require functional specifications as well. Table 45 illustrates the attributes that need to be considered. Table 45 Physical Environment Fidelity Requirements
Physical Fidelity Requirements Attribute Appearance Feel Sound Description Do the colour and texture matter? What are the critical appearance attributes? If the item can be touched, does the feel of the item have to be replicated exactly? What sounds have to be produced and to what degree of fidelity?
Functional Fidelity Requirements Attribute Behaviour Description What aspects of behaviour have to be produced to generate interactions with the team and to respond to interactions from the team? Information required to generate interactions with the team or respond to team interactions
Interaction information requirements
9.2.2.1.6 Recording Element Fidelity Specifications Element specifications are recorded in the Environment Description Table. This has the advantage of keeping the Environment Description Table as the single master document that provides a comprehensive description of the required environment set. There will be a set of entries for each of the training environments described. This is illustrated in Table 46
106
Table 46 Tornado F3 Pair Environment Description Table

Element Fighter Controller (Human) Bandit Fighters (Manned System) Bandit Missiles (Resource) Radar Homing and Warning Receiver (System) Training Environment 1 Simplified Conditions Environment for whole task training of all objectives Fidelity Requirements On receipt of target information request, provide target location, height, heading and speed and vector to target Requires a tactical display showing the positions and speeds of the F3 and bandit aircraft Knowledge of tactics and control procedures for air intercepts, ability to calculate appropriate vectors given a plan view equivalent to a radar display Representative appearance in visual range. Accurate radar signature and heat signature Speed, acceleration, climbing and turning capability to be fully representative To attack : radar /visual indication of F3 positions and manoeuvre, knowledge of tactics To evade missile attack: radar warning receiver indications of F3 radar lock, knowledge of tactics including use of defensive aids Pursue F3 Pair aircraft Accurate speed and turning performance Radar guided missiles: Radar signatures of F3, range to target Heat seeking missiles: heat signature of F3 and flares, range to target Radar guided missiles: Radar signatures of F3 and chaff, Heat seeking missiles: heat signature of F3 and Size and location of display does not need to be exact but must be easily viewed Screen colour should be accurate Audio warnings should be accurately replicated Detection ranges should be exactly modelled Visual indications should be exact
107
9.3 Training Environment Option Identification

Generally the environment options for practicing a team task will either be the use of the live environment in some form or the use of simulation. If weapons effects are involved there will invariably be a requirement for the simulation of weapons effects with separate provision for live firing if relevant. The general considerations for the use of simulation include: 1. Safety - Simulation will be the most appropriate option where there is an unreasonable level of danger involved in using the live environment one would not fire live weapons at human or manned targets or practice dealing with an aircraft engine fire by setting an engine on fire in flight. 2. Cost - Simulation also offers the opportunity for significant cost savings in equipment maintenance, consumables cost and other cost associated with training delivery. A Tornado F3 costs tens of thousands of pounds per hour to operate whereas the overall cost of a simulator would be in the order of hundreds of pounds per hour. 3. Time - The use of simulation can also make considerable savings in time. For example, to conduct an hour of air intercept training for 5 intercepts takes about 3 hours for the sortie, taking into account aircraft checks, transit time to and from the training area, and the time to reposition aircraft after each intercept. The equivalent training could be achieved in a simulator in about 40 minutes. 4. Resource availability Simulation has the potential to address many resource constraint issues. With ever increasing environmental pressures, access to training areas is becoming more problematic. In a simulator the only constraint on geographical area is the availability of a suitable terrain database. Environmental conditions such as weather, darkness etc cannot be controlled in the live environment where as many conditions can be selected at will in a simulator. Resource availability also includes factors such as the ability to accurately represent threats from platforms other than those in the current inventory. 5. Instructional features Simulators provide significant advantages in terms of the instructional features that they offer. For example, the possibility of freezing the simulator do allow coaching if performance is poor, followed by resumption of the exercise post coaching, is a powerful feature, as is the ability to reset the simulator to a previous point in time to allow a repeat of the exact scenario experienced. In addition, considerably more performance data can be collected automatically in a simulator. There are a variety of different types of simulation which could be considered. The major categories include: a. Virtual Virtual simulation can be defined as real people operating simulated equipment in a virtual environment and is exemplified by vehicle and ops room simulations.
108
b. Constructive Constructive simulation can be defined as real people exercising military decisions on the basis of information constructed by a computer system. A common type of constructive simulation is the classic wargame and is typified by the wargames such as the one supporting the Command and Staff Trainer (CAST) at the Land Warfare Centre. c. Live Simulation Live simulation can be defined as real people operating real equipment with simulated effects in a live environment and is typified by the use of instrumented flying ranges and the Tactical Engagement Simulation (TES) systems used at BATUS. d. Embedded simulation Embedded simulation is the incorporating of simulation capability into operational equipment. Simulation modes built into warfare systems would fall into this category. e. Networked simulation Networked simulation is the networking together of multiple simulators. Examples include the Combined Arms Tactical Trainer (CATT) and the Medium Support Helicopter Aircrew Training Facility (MSHATF), both of which have multiple vehicle simulators connected together on one site. f. Distributed Simulation Distributed refers to the networking of simulators and simulator networks across different sites. Examples include the connection of the Cooke Warfare Team Trainers in Portsmouth being connected to US Navy simulation systems in Norfolk, Virginia and the connection of the Mission Training by Distributed Simulation (MTDS) system at RAF Waddington being connected to equivalent USAF systems in Mesa Arizona. g. Synthetic Wrap Synthetic wrap is an ingenious combination of the use of live and virtual simulation to provide an extended battlespace for training. This enables Operational pictures to be populated with elements that are outside the geographical area being used for training. The challenge is transitioning an element traversing the constructive space into the live space. h. Augmented Reality Augmented reality refers to the technique of integrating synthetic elements into the live environment. A typical example might include the insertion of synthetic target images and weapons effects into a weapons display. Identifying suitable options can be informed by the capabilities of extant systems but often advice will be required on what constitutes the contemporary art of the possible. Capability Joint Training Experimentation and Simulation (Cap JTES) in MoD Main Building should always be consulted for advice, particularly as there is a requirement for all new simulations to have the capability to be connected to extant systems to provide greater capability for distributed training in the collective and joint domains.
109
9.4 Training Environment Option Definition

Once an environment option has been identified it is necessary to provide a formal description of it. It is suggested that this can be achieved with the construction of two tables: an Environment Option Description Table and an Environment Option Properties Table. The Training Environment Option Description Table provides an overview of the option in terms of a narrative description of the option, a list of the resources required and details of how the instructional and support functions are implemented, including training requirements. An example for the JOUST networked simulation system, shown in Figure 33 is shown at Table 47. A table would be created for each option for the environment being considered.
JOUST
Figure 33 JOUST Networked Flight Simulation System
110
Table 47 Example Training Environment Option Description Table

Simplified Conditions Environment for Pairs Intercept Practice Option Name: JOUST Description: JOUST is a networked, desktop flight simulation system that has the capacity to train two student crews and can be sited in a single room. Bandit aircraft can be preprogrammed virtual entities in the environment or two manned consoles can be used. The performance data for the Tornado aircraft and the bandit aircraft is based on manufacturers data in the case of the Tornados and intelligence data in the case of bandit aircraft. The student workstations have representative controls and displays and an intercom system is provided which has a press to transmit facility to replicate radio use for communication between aircraft. Missile fly outs and effects are accurately modelled as are the effects of chaff and flares. The bandit workstations are single seat and have generic controls and displays. An instructor console is provided which has facilities for configuring all the parameters required for the exercises including geographical area, weather conditions and bandit profiles (if required). It provides a 3-D display of the intercepts and shows aircraft tracks and missile fly outs. It can be rotated to give a plan display. This can be used for both monitoring student actins and for replay of the intercepts for debrief purposes. Resource list: JOUST networked system in one room Instructional/Support Function Deliver Practice Prepare Scenario Deliver Scenario Configure the scenario Control Scenario Change Scenario Assess practice Monitor and assess individual and team performance Monitor and assess performance outputs Provide feedback during task performance Debrief practice Operate Bandit Aircraft Assistant instructor 2 Operation of generic Bandit station Instructional/Support Role Primary Instructor Numbers 1 Operation of the JOUST system to include: scenario construction system configuration control of scenarios use of replay facilities. Training Requirements
Having developed the overall description of the option, the next stage is to capture in detail how it meets the requirements for the environment. This entails describing how each element of the environment is represented and how the instructional overlay requirements are met. The requirements for each element are described by the corresponding column for that element in the Environment Description Table. It is suggested that the appropriate entries in the table are extracted and used to populate the first column of an Environment Option Properties Table for that element. Subsequent columns can then be used to record the detail for each option
111
being considered for the training environment in question. Example table entries are shown in Table 48. Table 48 Example Training Environment Option Properties Table Entries
Environment: Simplified Conditions Environment for Pairs Intercept Practice Environment Element: Bandit Missiles Requirement Option JOUST Heat seeking and radar guided missiles effects based on launch parameters, kill probability and pairs manoeuvre Evaluation of missile effectiveness for debrief Radar guided and heat seeking missile flyouts and effects shown in simulation on instructor display Live Flying Weapons effects simulation not available
Missile effectiveness modelled in simulation
Shot effectiveness of Bandit missiles evaluated by instructors inspection of video recording of cockpit displays and estimate of launch parameters and Kill probability Video of cockpit displays replayed using mission debrief facility
Video replay of missile effects for debrief
Video replay facility provided on the instructor station which can be viewed by the students
112
9.5 Training Environment Option Evaluation

Having developed the Environment Option Properties Tables, comparison of the technical option becomes a relatively simple matter of comparing column entries on their technical merits. The technical evaluation of alternative options for each environment can be shown quite simply using a standard traffic light colour coding scheme in an Environment Options Comparisons Table as illustrated in Table 49. This allows key weaknesses in each option to be quickly identified and gives a visual impression of the degree to which the option satisfies the requirement. Table 49 Training Environment Options Comparisons Table
Environment: Simplified Conditions Environment for Pairs Intercept Practice Environment Element: Bandit Missiles Requirement Option JOUST Live Flying Comments
Heat seeking and radar guided missiles effects based on launch parameters, kill probability and pairs manoeuvre.
Evaluation of missile effectiveness for debrief Video replay of missile effects for debrief
113
10 Training Options Evaluation

10.1 Introduction
The evaluation of training options is ultimately a subjective judgement of the balance of time, cost and perceived efficacy of the alternative options, given the likely training throughput. From one perspective this is likely to be simplified for team and collective training as there are likely to be fewer options to consider given that there will be relatively few training environment options.
10.2 Estimation of Costs

In principle the cost associated with a given option can be categorised as: Setup costs, including training environment acquisition and training development costs. Initial and ongoing instructor training costs. Maintenance costs of the training environments. Costs associated with running a given instance of the training course/event. Costs associated with the number of individuals attending the training course/event. Costs to integrate the solution into existing training environments (such as networking a simulator into existing simulator networks).
The cost model may be somewhat different if the training solution is to be acquired as a training service. Given that it is likely that a synthetic training solution will be required for some or all of the training, advice from MoD and probably industry will be required to determine costs in any meaningful way.
10.3 Estimating Effectiveness

Estimating the likely effectiveness of a training option is a difficult subjective task, although the efficacy of equivalent solutions should any exist can be a useful guide. The detailed comparison of the technical capabilities of alternative environment options afforded by comparisons made in the training environment analysis section, does go some way to taking the guess work out of that aspect of effectiveness assessment.
10.4 JSP 822 Guidance

The guidance in JSP 822 for the comparison of training options should always be followed.
114
11 Conclusions and Recommendations

11.1 Conclusions
This research was conducted to close the methodological gap that had been identified in the conduct of TNA for team and collective training. The resultant TCTNA approach has been developed following a four stage process of developing a team/collective training model, reviewing team analysis methods applicable to TCTNA, developing a theoretical TCTNA model and instantiating the theoretical model and developing guidance. The Team/Collective Training Model has been designed to underpin the TCTNA approach by providing a map of the components of team/collective performance and training that should be considered during the analytical process. At the core is the Team Performance Model, supported by a teamwork taxonomy, which shows how team processes act on the inputs from the environment to produces outcomes aimed at achieving a desired effect in the environment. Novel features of the model include the characterisation of the environment itself (expressed in terms of the different categories of element that make up the environment and the demands which the dynamic nature of the environment make on task performance), the mapping of instructional processes onto the Team Performance Model, and the explicit identification of the requirement for resources and systems to support the instructional processes. The review of team analysis methods confirmed that there was no extant methodological approach that was sufficient in itself for the conduct of TCTNA in its entirety, although HTA(T) could serve as the foundation for task analysis and concepts from the CDA, MATT and MEC approaches could be applied at different stages of analysis. The theoretical model of TCTNA, based on the TNA Triangle Model devised in a previous phase of HFI DTC research (HFI DTC, 2009), has five components, the instantiations of which contain a variety of new techniques and adaptations of existing techniques to cater for the greater complexity of team and collective training. Team/Collective Task Analysis can be mapped onto the OTA and Gap analysis phases of conventional TNA. Constraints Analysis, Training Overlay Analysis, Training Environment Analysis, and Training Option Selection map onto the Training Options Analysis phase of conventional TNA. Constraints analysis is conducted in parallel with the other phases of analysis and captures both the constraints that exist and their implications for the choice of training solutions. Team/Collective Task Analysis uses adaptations of software design methods to capture key information about the task environment, and an extension of HTA(T) as a method for analysing team/collective tasks from both a task and teamwork perspective. Training Overlay Analysis involves not only a consideration of the methods to be used for training, as would be conducted for individual TNA, but also a detailed analysis of the instructional and support roles required to deliver training. Training Environment Analysis includes templates for the specification of the different types of elements in the environment identified in the Team Performance Model and an approach for comparing the suitability of the features of alternative training environments. Another unique feature of the TCTNA method is the construction of the Environment Description Table which is populated with data during each phase of analysis and provides a detailed data set which can be used to inform the contractual specification of training environments where required. Limited guidance is also provided on training option selection. Templates and worked examples have been
115
provided to illustrate the application of each of the techniques advocated in the main analytical stages. The development of the TCTNA approach has benefited from the active participation of Service TNA specialists, particularly the TNA staff at the Fleet Human Resources Training Support Group. The opportunity exists to further refine the techniques developed by eliciting their feedback on the experience of applying the TCTNA method to the QE Class Carrier Collective TNAs currently under way. The greatest opportunity for exploitation of this work within MoD lies in the inclusion of the TCTNA approach within JSP 822. To this end, the authors of this report have been invited to participate in the ongoing revision of JSP 822 and this report will be used to inform that work. The TCTNA method also has potential for application to Joint training, although some adaptations of the method may be required and is a potential area for further research.
11.2 Recommendations
It is recommended that: a. Feedback is sought from TNA specialists currently applying the TCTNA method so that the techniques advocated can be refined and revised as necessary. b. The TCTNA method is incorporated into JSP 822. c. The application of the TCTNA method to Joint training is investigated.
116
12 References
Adair, J (1997) Leadership Skills Chartered Institute of Personal Development, London. Annett, J., Cunningham, D. & Mathias-Jones, P (2000) A method for measuring Team Skills, Ergonomics, Vol 43 No 8 (pp1076-1094). Annett, J., Duncan, K. D., Stammers, R. B. and Gray, M. J. (1971) Task Analysis (London:HMSO). Annett, J. (1997) Analysing team skills, in R. Flin, E. Salas, M. Strub and L. Martin (Eds), Decision Making Under Stress: Emerging Themes and Applications, Ashgate, Aldershot. Arthur, W, Edwards, B.D, Bell S.T., Villado, A.J. & Bennett, W. Team Task Analysis: Identifying Tasks and Jobs that are Team Based. Human Factors, Vol 47, Issue 3. Baker, Day and Salas (2006) Teamwork as an Essential Component of High-Reliability Organizations. Health Services Research. Vol 41, Issue 4, August 2006. 15761598. Bowers, C.A., Morgan, B.B., Salas, E. & Prince, C. (1993) Assessment of Coordination Demand for Aircrew Coordination Training, Military Psychology 5(2) pp 95-112. Burke, S. (2005) Team Task Analysis, in Stanton, N. Hedge, A., Brookhuis, K, Salas, E., Hendrick, H. (Eds) Handbook of Human Factors and Ergonomics Methods, CRC Press, London. Cannon-Bowers, J.A. & Salas, E. (1998) Decision Making Under Stress: Implications for Individual and Team Training, American Psychological Association, Washington DC. Clark, R. C. (2008) Developing Technical Training 3rd Edn, Pfeiffer, San Francisco. DSTL (2006) Analysis of Team Training A Methodology. DSTL Report 200606. DSAT QS (2003) Defence Systems Approach to Training Quality Standard. Fitts, P.M. (1964) Perceptual-Motor Skill Learning in Melton, A.W. (Ed) Categories of Human Learning (pp243-285), Academic Press, New York. Hackman, J. R., & Morris, C. G. (1975) Group tasks, group interaction process, and group performance effectiveness: A review and proposed integration. In L. Berkowitz (Ed.), Advances in Experimental Social Psychology Vol. 8, Academic Press, New York. (1-55). HFI DTC (2005) Operational Information Management Skills Knowledge and Attitudes Requirements HFI DTC Report No HFIDTC/WP.2.1.1/1. HFI DTC (2007) Information Exploitation Competencies HFI DTC Report No HFIDTC/2.1.1/3.
117
HFI DTC (2008) A Critique of Media Selection Models analysis of applicability of extant models to current UK Military Training HFI DTC report No HFIDTC/2/WP12.1.1/1. HFI DTC (2009) Training Needs Analysis The Application of an Information Processing-based Approach HFI DTC Report No HFIDTC/2/WP12.1.1/2 Huddlestone, J. and Harris , D (2003) Air Combat Student Performance Modelling Using Grounded Theory Techniques, Proceedings of the Interservice/Industry Training Simulation and Education Conference, Orlando Dec 2003. JSP 502 Training needs Analysis for Acquisition Projects. JSP 822 (2007) Part 5 Chapter 3 Defence Training Support Manual 3 Training Needs Analysis. Klein, G (2000) Cognitive Task Analysis of Teams in Schraagen, J.M., Chipman, S.F.,& Shalin, V.L. Cognitive Task Analysis, Laurence Earlbaum Associates. Klein, G. & Armstrong A.A. (2005) Critical Decision Method in Stanton, N.A. Hedge, A., Brookhuis, K, Salas, E., Hendrick, H. (Eds) Handbook of Human Factors and Ergonomics Methods, CRC Press, London. (35-1 35-8) Marks, M.A., Matheu, J.E. & Zaccaro, S.J. (2001) A temporally based framework and taxonomy of team processes, Academy of Management Review Vol 26 No3( pp356-376) Naikar, N, & Sanderson, P. (1999) Work Domain Analysis for Training System Definition and Acquisition in The International Journal of Aviation Psychology, 9(3) (271-290). NATO (2004) Evaluation of Collective Training in a Distributed Simulation Exercise Proceedings of the NATO Research and Technology Organisation Human Factors and Medicine Panel Symposium, Genoa Oct 2003. NATO (2005) Military Command Team Effectiveness: Model and Instrument for Assessment and Improvement NATO Research and Technology Organisation Technical Report TR-HFM-087. Nieva,V.F., Fleishman, E.A., & Reick, A (1978). Team dimensions: Their identity, their measurement, and their relationships. Final Tech. Report, Contract DAHI9-78-C- 0001. Advanced Research Resources Organisation, Washington, DC. Orasanu, J. M. (1993). Decision making in the cockpit. In: Weiner, E. L., Kanki, B. G. and Helmreich, R. L. (Eds). Cockpit resource management. London: Academic Press Limited. Partington, D. (2002) Essential Skills for Management Research, Sage, London. Reigeluth, C.M. (1999) The Elaboration Theory in Reigeluth, C.M. Instructional-Design Theories and Models Vol II, Lawrence Earlbaum Associates, New Jersey. Roby, T. (1968) Small Group Performance. Rand McNally & Company, Chicago.
118
Rousseau, V., Aube, C. & Savoie, A. (2006) Teamwork behaviours A review and Integration of Frameworks in Small Group Research Vol 37 No 5, (540-570). Salas, E., Sims, D. E., & Burke, C. S. (2005). Is there a big five in teamwork? Small Group Research, 36, 555-599. Salas, E., Dickinson, T.L., Converse, S., & Tannenbaum, S.I. (1992). Toward an understanding of team performance and training. In R.W. Swezey & E. Salas (Eds.), Teams: their training and performance Ablex, Norwood, NJ. (329). Salas, E. & Preist, H. Team Training in Stanton, N., Hedge, A., Brookhuis, K., Salas, E. and Hendrick H. (2005) Handbook of Human Factors and Ergonomics Methods, CRC Press, Florida. (44-1 44-7). Salmon, P.M., Stanton, N.A., Walker, G.H., Jenkins, D.P. (2009) Distributed Situational Awareness. Ashgate, Aldershot. Stanton, N. (2006) Hierarchical Task Analysis: Developments, Applications and Extensions, Applied Ergonomics Volume 37, Issue 1 January 2006, (pp55-79 ) Elsevier. Stanton, N.A., Salmon, P.M., Walker, G.H., Baber, C., Jenkins, D. (2005) Human Factors Methods A Practical Guide for Engineering and Design, Ashgate, Aldershot. Strauss, A., Corbin, J. (1990) Basics of Qualitative Research: Grounded Theory Procedures and Techniques, Sage, London. Swezey, R. W., Owens, J. M., Bergondy, M. L., & Salas, E. (1998). Task and training requirements analysis methodology (TTRAM): An analytic methodology for identifying potential training uses of simulator networks in teamwork-intensive task environments. Ergonomics, 41, 1678-1697. Tannenbaum, S. I., Beard, R. L., & Salas, E. (1992). Team building and its influence on team effectiveness: An examination of conceptual and empirical developments. In K. Kelley (Ed.), Issue, theory, and research in industrial/organizational psychology (pp. 117-153). Amsterdam: Elsevier. Tannenbaum, S.I., Smith-Jentsch, K.A., Behson, S.J. (1998) Training Team Leaders to Facilitate Learning and Performance in Cannon Bowers, J.A. & Salas, E.(Eds) Decision Making Under Stress: Implications for Individual and Team Training, American Psychological Association, Washington DC. Tesluk. P., Mathieu, J. E., Zaccaro. S. J., & Marks, M. (1997). Task and aggregation issues in the analysis and assessment of team performance. In M. T. Brannick, C. Prince, & E. Salas (Eds.), Team performance assessment and measurement: Theory, methods, and applications (pp. 197-224). Mahwah. NJ: Erlbaum. Ward, P.T. & Mellor, S.J. (1985) Structured Development for Real-Time Systems Volume 2: Essential Modelling techniques, Yourdon Press, New Jersey. Wickens, C.D. & Hollands J.G. Engineering and Human Performance 3rd Edn, Prentice Hall, New Jersey.
119
Appendix A
Teamwork Models
A.1 Team Process Model (Annett, 2000)
Figure 34 Team Process Model (adapted from Annett, 2000)
120
A.2 Team Coordination Dimensions (Bowers et al, 1993)

Table 50 Definitions of Team Coordination Dimensions (Bowers et al, 1993), Coordination Dimension Communication Situational Awareness (SA) Decision Making (DM) Definition Includes sending, receiving, and acknowledging information among crew members. Refers to identifying the source and nature of problems, maintaining an accurate perception of the aircrafts location relative to the external environment, and detecting situations that require action. Includes identifying possible solutions to problems, evaluating the consequences of each alternative, selecting the best alternative, and gathering information needed prior to arriving at a decision. Includes monitoring, allocating, and coordinating the resources of the crew and aircraft; prioritizing tasks; setting goals and developing plans to accomplish the goals; creating contingency plans. Refers to directing activities of others, monitoring and assessing the performance of crew members, motivating members, and communicating mission requirements. Refers to the ability to alter ones course of action as necessary, maintain constructive behaviour under pressure, and adapt to internal or external changes. Refers to the willingness to make decisions, demonstrating initiative, and maintaining ones position until convinced otherwise by facts. Refers to the overall need for interaction and coordination among crew members.
Mission Analysis (MA)
Leadership
Adaptability
Assertiveness Total Coordination
121
A.3 The Models for Analysis of Team Training Taxonomy (Dstl, 2006)
Table 51 MATT Teamwork Behaviours (Dstl, 2006) Behaviour Definition 1. Communication Behaviours 1a Information Exchange Seeking and passing information to all relevant team members at appropriate times in relation to their task needs. 1b Communication Skills 2. Co-ordination Behaviours 2a Procedural Co-ordination 2b Collaboration Making use of standardised formats and conventions to transmit information. The integration and synchronisation of team interactions in the completion of laid down procedures. The process of organising team resources, activities and actions to ensure that tasks are mutually shared and completed in time. Directing and co-ordinating the activities of the team.
2c Leadership and Task Management 3. Adaptive Behaviours 3a Situation Assessment 3b Decision Making
Development of a common understanding of the situation. Mutual involvement in the assessment of a situation and choice of a course of action through discussion and argument. Monitoring the performance of team mates, providing constructive advice and giving and receiving feedback. Providing assistance to other team members who need it.
4. Back-up Behaviours 4a Performance Monitoring and Feedback 4b Mutual Support
122
Table 52 MATT Team Member Attitudes and Characteristics (Dstl, 2006) Attitude 1. Mutual Trust 2. Shared Vision 3. Team Orientation 4. Collective Efficacy Characteristics Team members respect each other, listen to each others proposals and views and encourage proactive behaviour. Team members agree on the direction, goals and mission of the team and have a mutual belief in the importance of the team. Team members believe that the team approach is likely to be more successful than acting as an individual. Team members hold positive common perceptions of group achievements and potential.
Table 53 MATT Teamwork Knowledge Requirements (Dstl, 2006) Type of knowledge Definition Shared Task Models Cue-Strategy Associations Team Mission, Objectives and Resources Accurate Problem Models Team Member Characteristics Boundary Spanning Roles Task Sequencing Team Role Interaction Patterns Teamwork skills Shared models of the situation and appropriate strategies for coping with task demands. Association of environmental data, with appropriate task strategies requiring coordination. Goals held in common and the team members and facilities for their achievement. Correct understanding of the teams problems and strategies by which members will cope with and solve them. Task relevant competencies, preferences, tendencies, strengths and weaknesses of team mates. Knowledge of how a team manages its interactions with non-team members and other units. Integrating task inputs according to team and task demands. Knowing how the team communicates and arrives at decisions. Understanding the skills and behaviours required for successful performance. Understanding what needs to be done in order for the team to perform effectively. Knowing how to organise tasks in sequences depending on priorities. Descriptors Hold shared interpretation of situations and how to deal with them. Know how and when to change co-ordination strategies. Common understanding of mission and team resources required to achieve objectives.
123
A.4 Salas Big Five Model of Teamwork (Salas et al, 2005)
Table 54 Definitions of the Core Components and Coordinating Mechanisms of the Big Five Model of Teamwork (adapted from Salas et al, 2005) Teamwork Definition Core Components Team leadership Ability to direct and coordinate the activities of other team members, assess team performance, assign tasks, develop team knowledge, skills, and abilities, motivate team members, plan and organize, and establish a positive atmosphere. The ability to develop common understandings of the team environment and apply appropriate task strategies to accurately monitor team mate performance. Ability to anticipate other team members needs through accurate knowledge about their responsibilities. This includes the ability to shift workload among members to achieve balance during high periods of workload or pressure. Ability to adjust strategies based on information gathered from the environment through the use of backup behaviour and reallocation of intra-team resources. Altering a course of action or team repertoire in response to changing conditions (internal or external). Propensity to take others behaviour into account during group interaction and the belief in the importance of team goals over individual members goals. Coordinating Mechanisms Shared mental models Mutual trust Closed loop communication An organizing knowledge structure of the relationships among the task the team is engaged in and how the team members will interact. The shared belief that team members will perform their roles and protect the interests of their teammates. The exchange of information between a sender and a receiver irrespective of the medium.
Mutual Performance Monitoring Backup behaviour
Adaptability
Team orientation
124
A.5 Teamwork Behaviours (Rousseau et al, 2006)

Table 55 Teamwork Behaviours (Rousseau et al, 2006) Preparation of work accomplishment Team Mission Analysis Goal Specification Planning Performance monitoring Systems monitoring Coordination Cooperation Information exchange Backing up behaviours Inter-team coaching Collaborative problem solving Collective interpretation and evaluation of the teams purpose, including identification of its main tasks and the operative environmental conditions and team resources available for carrying out the mission Identification of the level of performance that team members have to achieve Development of alternative courses of action for task accomplishment Keeping track of fellow team members work Tracking team resources and the state of the external environment.
Work Assessment Behaviours
Task-related collaboration behaviours Integrating team members activities to ensure task accomplishment within established temporal constraints Working together during task execution. Exchange information by whatever means
Team Adjustment Behaviours Provision of tangible task-related help when a team member is failing to reach the goals as defined by his or her role Provision of feedback and confronting members who break norms Collectively find and implement a solution that brings actual conditions closer to the desired conditions involves gathering and integrating information related to the problem, identifying alternatives, selecting the best solution, and implementing the solution includes decision making Team members activities designed to invent and implement new and improved ways of doing their tasks The voluntary assistance that team members provide to reinforce the sense of well-being of their teammates Resolution of conflicts tasks, processes and interpersonal issues
Team practice innovation Psychological support Integrative conflict management
Management of Team Maintenance
125
- End of Document
126
127

Collective TNA

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Collective TNA

Uploaded by

Copyright:

Available Formats

Training Needs Analysis for Team and Collective Training

Reference ............................................HFIDTCPIII_T13_01 Version ................................................................................. 2 Date ................................................................. 16 April 2011

HFIDTCPIII_T13_01 Version 2/ 16 April 2011

HFIDTCPIII_T13_01 Version 2/ 16 April 2011

Executive Summary ................................................................................... 1 Introduction ................................................................................................ 3

The Team/Collective Training Model .......................................................... 9

Development of a Team/Collective Training Model .......................................................... 27

Review of Team Analysis Methods Applicable to TCTNA ........................ 30

HFIDTCPIII_T13_01 Version 2/ 16 April 2011

The TCTNA Method ................................................................................. 36

Constraints Analysis ................................................................................. 41

Team/Collective Task Analysis................................................................. 43

HFIDTCPIII_T13_01 Version 2/ 16 April 2011

Training Overlay Analysis ......................................................................... 83

HFIDTCPIII_T13_01 Version 2/ 16 April 2011

Training Environment Analysis ............................................................... 100

9.3 9.4 9.5

Training Options Evaluation ................................................................... 114

Conclusions and Recommendations ...................................................... 115

11.1 Conclusions ..................................................................................................................... 115 11.2 Recommendations .......................................................................................................... 116

References ............................................................................................. 117 Teamwork Models................................................................. 120

HFIDTCPIII_T13_01 Version 2/ 16 April 2011

HFIDTCPIII_T13_01 Version 2/ 16 April 2011

HFIDTCPIII_T13_01 Version 2/ 16 April 2011

HFIDTCPIII_T13_01 Version 2/ 16 April 2011

HFIDTCPIII_T13_01 Version 2/ 16 April 2011

RHWRRadar Homing & Warning Receiver

HFIDTCPIII_T13_01 Version 2/ 16 April 2011

HFIDTCPIII_T13_01 Version 2/ 16 April 2011

HFIDTCPIII_T13_01 Version 2/ 16 April 2011

2.2 Scope of Team/Collective Training Needs Analysis

HFIDTCPIII_T13_01 Version 2/ 16 April 2011

2.3 Training Needs Analysis

Figure 1 The Systems Approach to Training

HFIDTCPIII_T13_01 Version 2/ 16 April 2011

HFIDTCPIII_T13_01 Version 2/ 16 April 2011

HFIDTCPIII_T13_01 Version 2/ 16 April 2011

Phase 2 TNA Development Operational/business Task Analysis OPS/CF Statement Deliverable 1

Training Gap Analysis

Training Objectives Deliverable 2

Training Options Analysis

Recommended Training Solution Deliverable 3

Can trg design begin?

Other SAT Elements

Phase 3 TNA Post Project Evaluation

Figure 2 MoD TNA Process Diagram (JSP822, 2007)

HFIDTCPIII_T13_01 Version 2/ 16 April 2011

2.4 Methodological Approach

Figure 3 TCTNA Development Sequence

HFIDTCPIII_T13_01 Version 2/ 16 April 2011

3 The Team/Collective Training Model

HFIDTCPIII_T13_01 Version 2/ 16 April 2011

3.3 Development of a Teamwork Taxonomy

3.3.1 Review of Extant Teamwork Models

Figure 4 Patterns of Team Interactions adapted from Tesluk et al (1997)

HFIDTCPIII_T13_01 Version 2/ 16 April 2011

HFIDTCPIII_T13_01 Version 2/ 16 April 2011

Table 1 Teamwork Models used in Teamwork Analysis

HFIDTCPIII_T13_01 Version 2/ 16 April 2011

Table 2 Integrative Teamwork Models

HFIDTCPIII_T13_01 Version 2/ 16 April 2011

HFIDTCPIII_T13_01 Version 2/ 16 April 2011

3.3.2 Synthesis of a Teamwork Taxonomy