A Review of the Event Analysis of Systemic Teamwork Methodology
A Review of the Event Analysis of Systemic Teamwork Methodology
A Review of the Event Analysis of Systemic Teamwork Methodology
- No tags were found...
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
HFIDTC/WP1.1.3/10<br />
Version 2/ 31 October 2005<br />
3.7 Operation Sequence Diagrams<br />
Background and applications<br />
Operation Sequence Diagrams (OSD) are used to graphically describe <strong>the</strong> activity and<br />
interaction between teams <strong>of</strong> agents within a network. According to Kirwan and<br />
Ainsworth (1992), <strong>the</strong> original purpose <strong>of</strong> OSD analysis was to represent complex, multiperson<br />
tasks. The output <strong>of</strong> an OSD graphically depicts <strong>the</strong> task process, including <strong>the</strong><br />
tasks performed and <strong>the</strong> interaction between operators over time, using standardised<br />
symbols. There are various forms <strong>of</strong> OSD’s, ranging from a simple flow diagram<br />
representing task order, to more complex OSD which account for team interaction and<br />
communication. OSD’s have been applied in a number <strong>of</strong> domains, including <strong>the</strong> fire<br />
service (Baber et al 2004), naval warfare (Stewart et al 2004), aviation (Stewart et al<br />
2004), energy distribution (Salmon et al 2004), air traffic control (Walker et al 2004) and<br />
rail (Walker et al 2004) domains.<br />
Domain <strong>of</strong> application<br />
The technique was originally used in <strong>the</strong> nuclear power and chemical process industries.<br />
However, <strong>the</strong> technique is generic and can be applied in any domain.<br />
Procedure and advice<br />
Step 1: Define <strong>the</strong> task(s) under analysis<br />
The first step in an OSD analysis is to define <strong>the</strong> task(s) or scenario(s) under analysis.<br />
The task(s) or scenario(s) should be defined clearly, including <strong>the</strong> activity and agents<br />
involved.<br />
Step 2: Data collection<br />
In order to construct an OSD, <strong>the</strong> analyst(s) must obtain sufficient data regarding <strong>the</strong> task<br />
or scenario under analysis. It is recommended that <strong>the</strong> analyst(s) use various forms <strong>of</strong><br />
data collection in this phase. Observational study should be used to observe <strong>the</strong> task (or<br />
similar types <strong>of</strong> task) under analysis. Interviews with personnel involved in <strong>the</strong> task (or<br />
similar tasks) should also be conducted. The type and amount <strong>of</strong> data collected in step 2<br />
is dependent upon <strong>the</strong> analysis requirements. The more exhaustive <strong>the</strong> analysis is<br />
intended to be, <strong>the</strong> more data collection techniques should be used.<br />
Step 3: Describe <strong>the</strong> task or scenario using HTA<br />
Once <strong>the</strong> data collection phase is completed, a detailed task analysis should be conducted<br />
for <strong>the</strong> scenario under analysis. The type <strong>of</strong> task analysis is determined by <strong>the</strong> analyst(s),<br />
and in some cases, a task list will suffice. However, it is recommended that a HTA is<br />
conducted.<br />
Step 4: Construct <strong>the</strong> OSD diagram<br />
60