23.01.2015 Views

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

SHOW MORE
SHOW LESS
  • 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

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!