MAP-01-010 HFI Management Guide - Human Factors Integration ...

THIS DOCUMENT IS THE PROPERTY OF HER BRITANNIC MAJESTY’S GOVERNMENT 

MARITIME ACQUISITION PUBLICATION No 01-010 

MAP-01-010 

HFI Management Guide 

(formerly STGP 10) 

ISSUE: 4 

November 2006 

Copyright: This work is Crown copyright and the intellectual property rights of this publication 

belong exclusively to the Ministry of Defence. However, material or information contained in this 

publication can be reproduced, stored in a retrieval system or transmitted in any form provided it 

is used in for the purposes of furthering Human Factors Integration. 

© Crown Copyright 2006 

Sponsored by: Sea Systems Group 

TES-SSG-ShipDes 

Defence Procurement Agency, 

Mod Abbey Wood, Bristol, BS34 8JH 

tes-ssg-cshf@dpa.mod.uk 

Telephone 0117 913 5066 

Nov 2006 Page i Issue 4

MARITIME ACQUISITION PUBLICATION NO 01-010 

HUMAN FACTORS INTEGRATION (HFI) MANAGEMENT GUIDE 

(FORMERLY STGP 10) 

CONTENTS 

1 HFI Within Naval Capability Acquisition.......................................................................1-1 

2 HFI Processes and Mechanisms .................................................................................2-1 

3 Managing the HFI Process...........................................................................................3-1 

4 The Human Factors Integration Plan (HFIP)................................................................4-1 

Annex 

A1 Glossary...............................................................................................................Annex 1 

A2 Contact Details.....................................................................................................Annex 2 

A3 References...........................................................................................................Annex 3 

Nov 2006 Page i Issue 4

MAP-01-010 – HFI Management Guide (STGP 10) 

Human Factors Integration (HFI) has been shown to be a key factor in the 

continued drive to improve military capability, overall cost effectiveness and 

safety. The guidance contained in the HFI Management Guide (MAP 01-010) 

and the HFI Technical Guide (MAP 01-011) has been distilled from the 

experience gained over at least a decade of ship and equipment development 

and construction. Consequently they represent the best currently available 

practice in HFI. IPTs and supporting contractors will find these publications of 

considerable value in ensuring the appropriate application of HFI to their Project 

and in providing the necessary assurance that their efforts are being effectively 

applied. With allowance for variations in terminology and applicability and the 

overall policy lead given by the TES Human Factors Group, these guides have 

also been found useful in the Land and Air domains. 

Any enquiries regarding this publication in relation to an invitation to tender or a 

contract in which it is incorporated are to be addressed to the responsible 

technical or supervising authority named in the invitation to tender or contract. In 

other cases, the publication sponsor is to be contacted where there are concerns 

regarding the application of this publication, particularly issues associated with 

specific ship types. 

Compliance with this Maritime Acquisition Publication shall not in itself relieve any 

person from any legal obligations imposed upon them. 

This publication has been devised solely for the use of the Ministry of Defence 

(MOD) and its contractors in the execution of contracts for the MOD. To the 

extent permitted by law, the MOD hereby excludes all liability whatsoever and 

howsoever arising (including, but without limitation, liability resulting from 

negligence) for any loss or damage however caused when the standard is used 

for any other purpose. 

Comments on the content and scope are to be forwarded to the sponsor. 

Nov 2006 Page ii Issue 4

Abbreviations 

2SL 

ADAS 

ADQUAL 

ALARP 

AMS 

ANEP 

ARM 

BOI 

BR 

BSI 

CADMID 

CALS 

CBS 

CCII 

CINC 

CM 

COEIA 

CO 

COTS 

CSA 

CSHF 

CWG 

DCDS 

DEC 

DG 

DLO 

DLOD 

DME 

DNM 

DNPS 

DPA 

DSAT 

DStan 

Dstl 

EAC 

ECC 

EENA 

EER 

EHFA 

ES 

FAT 

FBG 

FLEET NPS 

FOTR 

GFA 

HAZOP 

HCI 

2nd Sea Lord 

Assistant Director Acquisition Support (no longer extant) 

Additional Qualification 

As Low As is Reasonably Practicable 

Acquisition Management System 

Allied Naval Engineering Publication 

Availability Reliability & Maintainability 

Balance of Investment 

Book of Reference 

British Standards Institute 

Concept, Assessment, Demonstration, Manufacture, In-Service, 

Disposal 

Continuous Acquisition and Life-cycle Support 

Chemical Biological Sciences 

Command & Control Information Infrastructure 

Commander In Chief 

Capability Managers 

Combined Operational Effectiveness and Investment Appraisal 

Commanding Officer 

Commercial-off-the-Shelf 

Customer Supplier Agreement 

Combat Systems Human Factors 

Capability Working Group 

Deputy Chief Of the Defence Staff 

Directorate of Equipment Capability 

Director General 

Defence Logistics Organisation 

Defence Lines of Development 

Director Marine Engineering 

Directorate of Naval Manning (No longer extant) 

Directorate of Naval Personnel Strategy 

Defence Procurement Agency 

Defence Systems Approach to Training 

Defence Standard 

Defence Sciences and Technology Laboratory 

Equipment Approval Committee 

Equipment Capability Customer 

Escape and Evacuation Naval Authority 

Escape, Evacuation and Recovery 

Early Human Factors Analysis 

Ergonomics Society 

Factory Acceptance Testing 

Future Business Group 

CINCFLEET Naval Personnel Strategy 

Flag Officer Training & Recruitment 

Government Furnished Assets (includes GFE) 

Hazards and Operability (Analysis) 

Human Computer Interface 

Nov 2006 Page iii Issue 4


HF 

HFG 

HFI 

HFIL 

HFIP 

HFSG 

HFWG 

HM 

HMI 

HMS 

HQ 

HUM 

IA 

IAB 

ILS 

ILSP 

IMO 

INM 

IPT 

IRC 

ISD 

ISO 

ISOP 

ISTAR 

ITEA 

ITEAP 

ITN 

ITT 

JCB 

JDCC 

JSP 

JWP 

KIP 

KUR 

LOD 

LSA 

LSAR 

MAP 

MAS 

MDG (N) 

MLS 

MLS CG 

MMI 

MoD 

MOE 

MSM 

NATO 

NEC 

NEHFILG 

NPS 

NRTA 

Human Factors 

Human Factors Group 

Human Factors Integration 

Human Factors Integration Log 

Human Factors Integration Plan 

Human Factors Steering Group 

Human Factors Working Group 

Her Majesty's 

Human Machine Interface 

Her Majesty's Ship 

Headquarters 

Health & Usage Monitoring 

Integration Authority 

Investment Appraisal Board 

Integrated Logistics Support 

Integrated Logistics Support Plan 

International Maritime Organisation 

Institute of Naval Medicine 

Integrated Project Team 

International Research Collaboration 

In Service Date 

International Standards Organisation 

Invitation to Submit Outline Proposal 

Intelligence Surveillance Target Acquisition & Reconnaissance 

Integrated Test Evaluation and Acceptance 

Integrated Test Evaluation and Acceptance Plan 

Invitation to Negotiate 

Invitation to Tender 

Joint Capability Board 

Joint Doctrines and Concepts Centre 

Joint Service Publication 

Joint Warfare Publication 

Key Integration Parameter 

Key User Requirement 

Line of Development (see DLOD) 

Logistic Support Analysis 

Logistics Support Analysis Record 

Maritime Acquisition Publication 

Military Agency for Standardisation 

Medical Director General (Navy) 

Marine Electrical Systems 

Marine Electrical Systems Controls Group (was WSA-MLS5) 

Man Machine Interface 

Ministry of Defence 

Measures of Effectiveness 

Maritime System Maturity 

North Atlantic Treaty Organisation 

Network Enabled Capability 

Naval Equipment Human Factors Integration Liaison Group 

Naval Personnel Strategy 

Naval Recruiting and Training Agency 

Nov 2006 Page iv Issue 4

OPS 

PCO 

PCOC 

PCOC-IMT 

PDF 

PDG/STS 

PERT 

PIAR 

PIAR-IMT 

PJT 

PMP 

PMS 

POC 

POL 

PPE 

PPO 

PR&A 

PRA 

PRM 

PS 

PSMP 

PSTAD 

R&T 

RAF 

RBB 

RM 

RN 

RN ICG 

RNGTAD 

RNSETT 

RNSMS 

RSI 

SAG 

SAT 

SML 

SoC 

SoW 

SP(Pol) 

SR(S) 

SRD 

SRL 

SSA 

SSE 

SSG 

SSMO 

SSP 

ST(S) 

STG 

STGP 10 

STGP 11 

Operational Performance Statement 

Prime Contracting Organisation 

People Component of Operational Capability 

PCOC Information Management Tool 

Portable Document Format 

Standards Programme Management (DStan) 

Programme Evaluation and Research Technique 

Personnel, Influences, Assumptions and Requirements 

PIAR Information Management Tool 

Pre Joining Training 

Project Management Plan 

Platform Management Systems 

Point Of Contact 

Petroleum, Oils and Lubricants 

Personal Protective Equipment 

Principal Personnel Officer 

Project Review and Assurance 

Process Risk Assessment 

Programme Responsibility Matrix 

Physical Sciences 

Project Safety Management Plan 

Project Specific Target Audience Description 

Research and Technology 

Royal Air Force 

Research Building Block 

Royal Marines 

Royal Navy 

RN Intelligent Customer Group (was RNSETT) 

Royal Navy Generic Target Audience Description 

RN School of Education & Training Technology (now RN ICG) 

Royal Navy Submarine School 

Repetitive Strain Injury 

Supportability Assurance Group 

Systems Approach to Training 

System Maturity Level (Maritime) 

Scheme of Complement 

Statement of Work 

Service Personnel Policy 

Staff Requirement for Sea Systems (superseded by SRD and 

URD) 

System Requirement Document 

System Readiness Level 

Ship Support Agency (subsumed into DLO) 

Support Solutions Envelope 

Sea Systems Group (was STG) 

Ship Safety Management Office 

Single Service Projects 

Staff Target for Sea Systems (superseded by URD and SRD) 

Sea Technology Group (now SSG) 

Sea Technology Group Publication 10 (now MAP-01-010) 

Sea Technology Group Publication 11 (now MAP-01-011) 

Nov 2006 Page v Issue 4


STGSS 

STR 

STS 

TAD 

TCOC 

TES 

TES-SSG 

TLM 

TLMP 

TNA 

TO 

TPS 

TRL 

TTCP 

UK 

URD 

WBS 

WLS 

WSA 

Sea Technology Group Surface Ships (now TES-SSG-Ship) 

Statement of Technical Requirements 

Statement of Technical Specification 

Target Audience Description 

Technology Component of Operational Capability 

Technical Enabling Services 

TES Sea Systems Group (formerly STG) 

Through Life Management 

Through-Life Management Plan 

Training Needs Analysis 

Team Organisation 

Training Performance Specification 

Technology Readiness Level 

The Technical Co-operation Panel 

United Kingdom 

User Requirement Document 

Work Breakdown Structure 

Whole Life Support 

Warship Support Agency (subsumed into DLO) 

Nov 2006 Page vi Issue 4 

MAP-01-010 TOC_23.doc

CHAPTER 1 – HFI WITHIN NAVAL CAPABILITY ACQUISITION 

CONTENTS 

1.1 Introduction to the Human Factors Integration (HFI) Guides .......................................1-3 

1.1.1 MoD Human Factors Integration Policy ................................................1-5 

1.1.2 Introduction to the Guides and Use by Project Role .............................1-7 

1.1.3 Objectives of the HFI Management Guide (MAP-01-010) ....................1-8 

1.1.4 Objectives of the HFI Technical Guide (MAP-01-011)..........................1-9 

1.1.5 The On-Line HFI Guides.......................................................................1-9 

1.1.6 Supporting Documentation ...................................................................1-9 

1.1.7 Sources of Advice...............................................................................1-10 

1.2 HFI in Naval Procurement ................................................................................1-12 

1.2.1 Definition of Human Factors (HF) .......................................................1-12 

1.2.2 HFI Domains.......................................................................................1-12 

1.2.3 HFI in Naval Projects – Objectives .....................................................1-14 

1.2.4 HFI Technical Areas for Naval Systems .............................................1-15 

1.2.5 Relationship between HFI Domains, HFI Technical Areas and MAP-01- 

011 Chapters ......................................................................................1-16 

1.3 Detailed HFI Domain Issues .............................................................................1-18 

1.3.1 Manpower HFI Issues.........................................................................1-18 

1.3.2 Personnel HFI Issues..........................................................................1-19 

1.3.3 Training HFI Issues.............................................................................1-20 

1.3.4 Human Factors Engineering HFI Issues .............................................1-22 

1.3.4.1 Compartment, Workspace and Workstation Specification and 

Design ..............................................................................1-22 

1.3.4.2 Layout of Operational, Accommodation and Transit Areas, 

Escape Routes, and Equipment.......................................1-23 

1.3.4.3 Environment in Normal & Abnormal Working Conditions 1-23 

1.3.4.4 User-Equipment Interfaces and HF Style Guides ............1-24 

1.3.4.5 User Input to Equipment Interface Design .......................1-25 

1.3.4.6 Use of Automation............................................................1-25 

1.3.4.7 System Integration HFI Issues .........................................1-25 

1.3.5 System Safety HFI Issues...................................................................1-25 

1.3.6 Health Hazard Assessment HFI Issues ..............................................1-27 

1.3.7 Organisational and Social HFI Issues.................................................1-28 

1.3.8 HFI Trade-Offs....................................................................................1-28 

1.4 HFI Contribution to Project Outputs..................................................................1-29 

1.4.1 Overview of the HFI Inputs .................................................................1-29 

1.4.2 HFI Contribution to Plans....................................................................1-30 

1.4.2.1 Types of Plans..................................................................1-30 

1.4.2.2 Human Factors Integration Plan (HFIP) ...........................1-31 

1.4.3 Integrated Test, Evaluation & Acceptance Plan (ITEAP)....................1-31 

1.4.3.1 HFI Contribution to the ITEAP through the Procurement 

Cycle ................................................................................1-31 

Nov 2006 Page 1-1 Issue 4


1.4.3.2 HFI Content of the ITEAP.................................................1-31 

1.4.4 Through Life Management Plan (TLMP).............................................1-33 

1.4.4.1 HFI Activities ....................................................................1-33 

1.4.4.2 HFI Content of TLMP .......................................................1-33 

1.5 HFI Contribution to Agreements .......................................................................1-34 

1.5.1 HFI Focus Relationships.....................................................................1-34 

1.5.2 Contracts and Invitations to Tender (ITTs) .........................................1-34 

1.5.3 Customer Supplier Agreements (CSAs) .............................................1-35 


Chapter 1 – HFI within Naval Capability Acquisition 

1.1 Introduction to the Human Factors Integration (HFI) 

Guides 

Human Factors (HF) is the systematic application of relevant information about 

human capabilities, limitations, characteristics, behaviour and motivation to the 

design of products and systems, the procedures people use and the environment 

in which they use them. The term covers all biomedical and psychosocial 

considerations. This information serves as the basis for making design 

recommendations and for predicting the probable effects of various design 

alternatives. In addition, HF involves the evaluation of things that have been 

designed to ensure that they satisfy their intended objectives. 

In terms of military capability, whether a product will achieve its required level of 

operational effectiveness in the field depends not only on the technical 

performance of the hardware and the software that make up the system but the 

capabilities and limitations of the people who will operate and support it. Failure 

to address the people who are part of the system and the environment in which it 

will be operated can lead to an overall system that fails to achieve the expected 

levels of operational effectiveness or safety. Unless identified and addressed at 

early phases of procurement, solving problems in design is likely to be high cost 

and require: 

• Product redesign or modification 

• Increases in manpower numbers or a need for personnel with a higher 

level of skill 

• Additional training time or resources 

To address these problems MOD has established the Human Factors Integration 

(HFI) programme, which is reviewed as part of the Project Review and Assurance 

(PR&A) process for each project. The programme consists of a systematic 

process for identifying, tracking and resolving human related issues ensuring a 

balanced development of both technological and human aspects of capability, 

together with supporting tools and techniques. A fundamental concept within HFI 

is that people are an important part of the system and that system integration is 

key to achieving operational effectiveness. The HFI process is described in this 

document (ie MAP-01-010 ‘HFI Management Guide (STGP 10)’) and, with more 

detail, in MAP-01-010 ‘HFI Technical Guide (STGP 11)‘ [Ref 1]. 

HFI should also be seen as an integral part of the Systems Engineering 

approach. The systems concept is central to the implementation of HFI and the 

overall goal of both HF and HFI is to design an optimal system consisting of 

operator, equipment and the environment in which they operate. 

In order to provide flexibility of approach to IPTs, there is no, single, mandatory 

HFI process specified within DPA AMS guidance. However, formal HF input may 

be required to mandatory MoD processes, such as Safety Case development. 

The HFI guidance promulgated within MAP-01-010 and MAP-01-011 should be 

regarded as model processes and activities, representing current best practice. 

The need to undertake specific HFI activities, e.g. task analysis, and the extent to 

which such activities are required, should be decided on a project-by-project 

basis, with appropriate input from HF Specialists and stakeholders. There is no 

suggestion that all the activities detailed within the Guides are always 

necessary or justified. However, in order to provide accountability, the 



model process identified in the Guides should be used as a reference norm, 

with any departures from that norm being documented and justified in 

appropriate project documentation. The HFI Focus should therefore use the 

model process as a checklist, and fully justify any project-specific 'opt-outs'. Key 

HFI activities are also considered during the Maritime System Maturity (MSM) 

Project Review and Assurance (PR&A) process. 

Experience from a range of MoD acquisition projects, and also from many other 

large-scale industrial procurement programmes, shows very clearly that the 

timing of HFI activities and resulting outputs is a critical factor in successful 

Human Factors Integration. A classic problem is the HFI input is "Too Little, Too 

Late". The active involvement of HFI staff (HFI Focus and HFI professionals) in 

the early phases of a project is an essential requirement whilst key project 

decisions are being made. If Human Factors input is delayed until the latter 

phases of equipment design and selection, there may be relatively little value to 

be added. The Early Human Factors Analysis (EHFA) technique addresses this 

issue in part. 

Similarly, it is often thought by non-HF specialists that HFI activities are never 

complete. Whilst some HF activities are relatively self-contained and produce 

discrete outputs at defined phases in a project, it must be emphasised that many 

HFI activities require an iterative approach, in which system and equipment 

proposals, designs and their realisations are systematically and repeatedly 

examined to assess their effects on the human component of the system. The 

need for HFI continues on beyond the hand over of capability to the user, in that 

there is justification for HF involvement in the analysis of in-service data and user 

feedback on the adequacy of the delivered solutions. 

It is not only important to decide upon an appropriate set of HFI activities for a 

particular project situation, it is essential that these are satisfactorily 

communicated to all relevant parties. 

HFI activities will not happen as a matter of course. The various organisations 

involved in a typical capability acquisition chain may or may not have in-house 

HFI capability, HFI processes or adopt HFI practices. Where MoD requires a 

Supplier to undertake particular HFI activities, apply particular HFI processes or 

produce particular HFI outputs this must be clearly stated in contract 

documentation, and appropriate resources allowed for their procurement and 

associated management. 

To avoid nugatory effort and expenditure, appropriate efforts should be made to 

identify, take into account and possibly re-use HF deliverables produced for MoD 

under other contracts. 

Generally, in specifying HF requirements in contracts, emphasis should be 

placed on the form of deliverable required, rather than on how the deliverable 

should be achieved. A possible exception to this is where consistency of 

approach across a number of supply contracts is required. 



1.1.1 MoD Human Factors Integration Policy 

MoD spending on personnel is at least equivalent to that on equipment and the 

Acquisition Handbook [Ref 2] includes an emphasis on ‘a through life systems 

approach, typified by applying Whole Life Costing techniques’ and ‘effective 

trade-offs between system performance, through life costs and time’. All 

equipment used by the armed forces has some element of human interaction and 

increasingly, the human is thought of as being part of the whole system, 

stemming from the Systems Engineering view of a system. 

In order to ensure that people are integrated into the system design safely, 

efficiently and reliably, equipment projects are expected to undertake an 

appropriate level of Human Factors Integration (HFI). For a general introduction 

to HFI, see ‘Human Factors Integration: An Introductory Guide’ [Ref 3] and ‘The 

MOD HFI Process Handbook’ [Ref 4], see also AMS Topic 2561 ‘Human Factors 

Integration (HFI)’ [Ref 5]. 

HFI is a focused management process that considers the extent of human 

involvement in the system under the seven areas known as domains, shown in 

Figure 1-1. 

HFI Domain 

Manpower 

Personnel 

Training 

Human Factors Engineering (HFE) 

System Safety 

Health Hazard Assessment 

Organisational and Social 

Figure 1-1: HFI Domains 

This process also enables trade-offs between these domains, such as the effect 

on safety of reducing manpower, and trade-offs with other areas such as the 

necessity to balance manpower size against operational capability. 

These domains map loosely to the eight Defence Lines of Development (DLOD), 

see Chapter 2. 



It is not intended that the HFI process should replace existing processes that are 

better described in: 

1. Safety – JSP 430 ‘MOD Ship Safety Management’ [Ref 6]. 

2. Complementing – BR 4017 ‘Naval Manning Manual’ [Ref 7]. 

3. Training – DSAT QS ‘The Defence Systems Approach to Training Quality 

Standard’ [Ref 8], supported by the Defence Training Support Manuals 

(DTSMs) [Ref 9] through [Ref 14]. 

4. Integrated Logistics Support (ILS) – ‘MOD ILS Manual’ [Ref 15]. 

Instead, HFI seeks to support these processes to ensure that the human element 

is integrated into the system design. 

Due to the nature of the maritime environment, it is particularly important that all 

MoD vessels and associated equipment are designed to take full account of the 

personnel who will operate them. These personnel are not only required to 

operate and maintain equipment in a remote and dynamic environment, but 

actually to live within the vessel in close proximity to each other for long periods. 

The systems involved are complex and expensive, in terms of design, build, 

operation, maintenance and disposal. The personnel required to work with these 

systems therefore have ever-greater demands placed upon them. 

Therefore, all projects are required to develop an HFI strategy, which should 

describe and justify the level of work that will be done on the project. 

Within DPA, the Sea Systems Group (SSG – previously known as the Sea 

Technology Group (STG)) has a remit to act as a focal point for HFI across the 

acquisition cycle for maritime projects and it interfaces with other focal points 

within the MoD organisation, see Section 1.1.7 Sources of Advice, below. This 

remit is achieved through the following: 

• Sponsorship of the HFI Guidance documents (MAP-01-010 and MAP-01- 

011). 

• Attendance at IPTs’ Human Factors Steering Groups (HFSG) and Working 

Groups (HFWG). 

• Combat system specific guidance and identification of best practice. 

• Guidance on implementation and execution of HFI process. 

In order to ensure a coherent HFI methodology, guidance material has been 

produced and is available on the ‘Acquisition Management System (AMS)’ 

website [Ref 16], see AMS Topic 2561 ‘Human Factors Integration (HFI)’ [Ref 5]. 

This HFI guidance and information is accessed using the AMS - Acquisition 

Topics - Topic Explorer. HFI is also the subject of Governing Policy GP 2.15 

‘Human Factors Integration’ [Ref 29]; this is part of the ‘Support Solutions 

Envelope (SSE)’ [Ref 30] and comes under Key Support Area 2 - Supportability 

Engineering. 

A general introduction to HFI and its value to the MoD is provided in the 

‘Introductory Guide’ [Ref 3] and ‘HFI Process Handbook’ [Ref 4]. For information 

about the generation of HFI requirements in the early phases of procurement, 



see Chapter 3 of this guide and ‘Human Factors Integration (HFI): Practical 

Guidance for IPTs’ [Ref 17]. The ‘Introductory Guide’ and ‘Practical Guidance for 

IPTs’ also detail the steps involved in co-ordinating HFI with the procurement 

process. MAP-01-010 and MAP-01-011 complement the use of these guides to 

provide detailed support for Surface Ship, Submarine and related equipment 

projects in the Defence Procurement Agency (DPA) and the Defence Logistics 

Organisation (DLO). 

1.1.2 Introduction to the Guides and Use by Project Role 

The guidance contained in MAP-01-010 and MAP-01-011 has been derived from 

project experience using an approach in which a MoD IPT places contracts with a 

Prime Contractor and then acts as the focus of Customer activities. 

Developments in MoD contract strategy now mean that the classic IPT may in 

some cases be replaced by an 'Alliance' formed from MoD and Prime Contractor 

staff, both working under a common management structure. Future 

developments in contracting may see military capability increasingly provided 

under PFI arrangements. The specific guidance on HFI responsibilities and 

activities contained within MAP-01-010 and MAP-01-011 may need to evolve to 

suit these novel contractual arrangements and the altered context of its 

application. 

MAP-01-010 and MAP-01-011 described HFI processes that are principally 

directed at the acquisition of new capabilities using bespoke solutions. 

Increasingly, commercial and technical trends mean that UK Defence Capability 

utilises a higher proportion of MOTS and COTS solutions. In other cases, new 

capability may be achieved through an upgrade of a legacy system. The overall 

HFI process described can be readily adapted to these acquisition situations. In 

such cases, increased emphasis on identifying system and equipment 

constraints may be required. Also, the process of HFI trade-offs may need to 

respect the commercial benefits of MOTS and COTS equipment solutions. 

The guidance in MAP-01-010 and MAP-01-011 is aimed primarily at the HFI 

Manager and HFI Focus within an IPT, see Table 1-1. Project experience gained 

over several years of application of the guides shows that the documents are 

also used by Prime Contractor staff and in some cases, sub-contractor staff. 

The HFI Guides are for use primarily by people performing the following roles: 

1. Integrated Project Team (IPT) Leader – This role has overall 

responsibility for ensuring that adequate resources are allocated to allow 

due regard to HFI to be given within the project. For more information on 

the role of the IPT Leader, see Chapter 2 (Sect 2.7.1). 

2. HFI Focus within the IPT – This role has responsibility for actively coordinating 

HFI issues throughout all aspects of the design of platforms and 

equipment, in conjunction with other systems engineering disciplines and 

MoD authorities, at each phase of the procurement cycle. The HFI Focus 

is responsible for assessing whether, and to what extent, HFI might be 

required within the project, an overview of the process and stakeholders 

and a mechanism for quantifying the scope of work, resources required 

and timescale. The HFI Focus, in conjunction with the IPT Leader, is 

responsible for determining how these processes will be managed and who 

is responsible for this management. In smaller projects, this role may not 



be a full-time post. For more information on the role of the HFI Focus, see 

Chapter 2 (Sect 2.7.2). 

3. Supplier – This role is responsible for conducting the technical HFI 

programme as required by the Human Factors Integration Plan (HFIP). 

For more information on the supplier terms of reference, see Chapter 2 

(Sect 2.7.3). 

4. HF Specialist in the IPT or the Supplier’s Human Factors Team – This 

role is responsible for executing HFI activities or providing advice about the 

overall conduct or products of such activities. For more information on the 

HF Specialist’s terms of reference, see Chapter 2 (Sect 2.7.4). 

HFI Guide 

Element 



On-Line HFI 

Guides 

Description 

Guidelines for the overall 

management of an HFI programme. 

Guidelines for managing the technical 

application of HFI in platform and 

equipment procurement. 

On-line versions of the contents of 

MAP-01-010 and MAP-01-011 

enabling hypertext linking of content 

(within and between the Guides); 

keyword search; fast access to, and 

copying of, specific contents; and 

guided use of the HFI material. 

Intended Users 

IPT Leader 

HFI Focus 

Supplier / HF 

Specialist 


Supplier / HF 

Specialist 

IPT Leader 


Supplier / HF 

Specialist 

Table 1-1: HFI Guides Description 

1.1.3 Objectives of the HFI Management Guide (MAP-01-010) 

MAP-01-010 provides guidance about the management of the HFI Programme 

for a platform or equipment and is aimed primarily at the IPT Leader and HFI 

Focus, although certain chapters will be relevant to the HF Supplier or specialist 

(for example, see Chapter 4 The Human Factors Integration Plan (HFIP)). 

MAP-01-010 describes major HFI issues and addresses the management steps 

that can be taken within the IPT. A HFIP needs to be developed as part of the 

Through-Life Management Plan (TLMP). The HFIP is normally prepared by the 

Prime Contractor or may be delegated to one of the Prime’s Subcontractors. 

MAP-01-010 helps the HFI Focus to understand how the HFIP can be used to 

monitor the supplier to ensure that systems meet all requirements. 



In particular, the objectives of MAP-01-010 are as follows: 

• To introduce Human Factors Integration (HFI) issues, risks and trade-offs. 

• To assist the IPT Leader and HFI Focus to develop an effective 

organisation to manage HFI. 

• To assist the IPT Leader and the HFI Focus to set requirements for the 

Supplier’s HFIP. 

• To provide guidance about HFI requirements identification, tendering, 

project control and monitoring, assessment and acceptance. 

• To provide specific guidance on how to achieve effective Whole Ship 

co-ordination of HFI issues. 

• To explain how HFI is incorporated into a multi-disciplinary approach. 

1.1.4 Objectives of the HFI Technical Guide (MAP-01-011) 

MAP-01-011 is designed for use in conjunction with MAP-01-010 and provides 

detailed guidance about HFI technical issues for platforms and equipment. It is 

aimed primarily at the HF Supplier or specialist for the conduct of HFI activities 

but will also provide guidance to the HFI Focus on the technical activities to be 

conducted. 

The content is designed to help the HFI Focus to identify the authorities and 

stakeholders involved, and the HFI activities that may be needed at each phase 

of the procurement. The advice is organised into HFI Technical Areas combining 

platform and equipment information where applicable. 

1.1.5 The On-Line HFI Guides 

MAPs 01-010 and 01-011 are available in electronic (PDF) format via the ‘Human 

Factors Integration’ [Ref 5] topic link on the ‘Acquisition Management System 

(AMS)’ website [Ref 16]. Additionally, both are available as CD-ROM versions, in 

either PDF or Word format. 

1.1.6 Supporting Documentation 

Figure 1-2 summarises the main documents providing HFI policy and guidance to 

the IPT. Each document is relevant to all of the project roles, to a varying 

degree. The figure below indicates, by means of proximity, the most relevant 

document for each role. 



Supplier / HF 

Specialist 

MAP-01-011: HFI 

Technical Guide 

[Ref 1] 

IPT Leader 

The Acquisition 

Handbook [Ref 2] 


Integration: An 

Introductory Guide 

[Ref 3] 

The MOD HFI Process 

Handbook [Ref 4] 

MAP-01-010: HFI 

Management Guide 

[this doc] 



Integration (HFI) 

Practical Guidance for 

IPTs [Ref 17] 

System Project 

Manager 

Figure 1-2: Supporting Documentation 

1.1.7 Sources of Advice 

For contact details, see Annex 2. 

• DPA – Technical Enabling Services (TES) – Human Factors Group (HFG) 

The Human Factors Group (HFG) has been established (late 2005) within TES to 

provide advice and guidance to IPTs predominantly in the Air and Land 

environments on the interpretation of HFI policy and application of HFI processes 

and procedures. The Group will also be supporting IPTs in assurance 

compliance with HFI policy and standards. As it develops its capability this group 

will increasingly drive development of HFI within Defence Acquisition, with SSG 

(see below) representing the Sea specific aspects. 

• DPA – TES – Sea Systems Group (SSG) 

Prior to April 2006, the SSG was known as the Sea Technology Group (STG). 

• TES-SSG-Ship (previously STGSS) 

Chair of Naval Equipment Human Factors Integration Liaison Group 

(NEHFILG). 



• TES-SSG-ShipDes (previously STGSS3) 

Responsible for overall delivery of advice and guidance to IPTs and 

Industry partners on application of HFI and input to the Maritime System 

Maturity People line for PR&A of Naval Platforms within the DPA and DLO. 

• TES-SSG-CSHF (previously STGCSHF) 

Sponsor of both MAP-01-010 and MAP-01-011, focal point for advice on 

application of guidance documents. 

Combat System Human Factors (CSHF) support and advice to IPTs. 

Member of MOD / Industry HFI Working Group. 

UK Panel Member for The Technical Co-operation Panel (TTCP): 

Subgroup HUM Technical Panel 9 (Human Factors Integration for Naval 

Systems). 

• TES-SSG-ShipDesNA (previously STGSS3a) 

Broader Human Factors matters relating items such as noise, vibration, 

accommodation and habitability. 

• DPA – Future Business Group (FBG) 

The Technology Co-ordination Cell of the Future Business Group (FBG) supports 

the link between the Research Building Block (RBB) and the DPA. 

• Defence Sciences and Technology Laboratory (Dstl) 

Dstl is a MoD organisation, see the Dstl website [Ref 18]. The Human Sciences 

group within the Defence Science and Technology Laboratory consists of 

physiologists, psychologists and other scientists. They provide expert scientific / 

technical support and independent advice to MOD and other Government 

Departments on the Human Sciences aspects of the formulation of research 

programmes, policy and procurement; they support the three armed services in 

the four environments in which they operate (i.e. land, sea, air and CIS). The 

team maintains close links with other Human Scientists in the MoD, Industry and 

academia both in the UK and abroad through a variety of NATO, TTCP and other 

formal IRC links, as well as through less formal links. 

• Institute of Naval Medicine (INM) 

The INM Human Factors Group specialises in the ergonomics of ship design from 

aspects of the individual to equipment and platform level. This includes 

anthropometric and psychological issues in addition to design and ergonomics. 

In addition to short duration consultancies for individual projects, the INM Human 

Factors Group undertakes long-term research. 

• DLO – Marine Electrical Systems Controls Group (MLS CG) – Human 

Factors, PMS, Machinery Controls and Control Trainers 

Provides advice and support within the Marine Engineering community for 

Human Factors issues. Has expertise in Human Computer Interface (HCI) 

design, task analysis, acceptance testing and how HFI relates to Platform 

Management Systems (PMS). Now part of Technical Enabling Services. 



1.2 HFI in Naval Procurement 

1.2.1 Definition of Human Factors (HF) 

Human Factors (HF) can be defined thus: 

An engineering discipline that applies theory, methods and research 

findings from ergonomics, psychology, physiology, anatomy and other 

disciplines to the design of manned systems. 

Human Factors is by nature interdisciplinary. It brings together concepts, 

theories, data and practice from a number of human-related sciences. It is 

concerned with influencing the design of manned systems, equipments and 

operational environments so as to promote safe, efficient and reliable total 

system performance. 

In the context of MAP-01-010 and MAP-01-011 the term ‘system’ is used to 

encompass any combination of platform (vessel), internal and external 

equipment, operating and maintenance personnel and all associated support 

systems such as documentation, tools, etc. 

1.2.2 HFI Domains 

The Human Factors Integration (HFI) framework focuses the contribution that 

Human Factors can provide as a discipline on the needs and capabilities of the 

users of manned systems, see ‘Introductory Guide’ [Ref 3]. The HFI framework 

identifies six general areas or ‘domains’, which will be referred to throughout 

MAP-01-010 and MAP-01-011. Table 1-2 gives definitions for the domains, each 

of which is represented in the document text by an associated icon. 

A seventh HFI domain is evolving to cover the Organisational and Social aspects 

arising from the organisational complexity of providing Network Enabled 

Capability (NEC) and will cover issues such as: 

• Shared situational awareness, 

• Cultural issues, 

• Trust and Information sharing, 

• Soft Interoperability 

• Alternative organisational configurations 

The implications of this seventh domain have yet to be fully determined and will 

be incorporated into this document at a later issue. 



Manpower 

Personnel 

Training 


Engineering 

(HFE) 

System Safety 

Health Hazard 

Assessment 

Organisational 

and Social 

Concerns the number of men and women, 

military and civilian, required and available 

to operate and maintain the system under 

consideration. 

Considers the aptitudes, experience, and 

other human characteristics, including 

body size and strength, necessary to 

achieve optimum system performance. 

Embraces the specification and evaluation 

of the optimum combination of: 

instructional systems; education; and 

on-the-job training required to develop the 

knowledge, skills and abilities needed by 

the available personnel to operate and 

maintain systems to a specified level of 

effectiveness under the full range of 

operating conditions. 

Covers the comprehensive integration of 

human characteristics into product and 

system design, including all aspects of 

workstation and workspace design. For 

vessels it also considers accommodation 

and habitability issues. 

The process of applying Human Factors 

expertise to minimise safety risks occurring 

as a result of the system being operated or 

functioning in either a normal or an 

abnormal manner. The objective is to 

reduce to ‘as low as reasonably 

practicable’ (ALARP), the risk of injury to 

service personnel (non-service persons 

under some circumstances) and damage 

to equipment. Often, engineering solutions 

are called for. In some cases, changes to 

interface design, personnel selection 

criteria, training requirements, manning or 

operating procedures may provide a 

cost-effective alternative. 

As part of System Safety considerations, 

this process seeks to identify and address 

conditions inherent in the operation or use 

of a product that may cause death, injury, 

illness, and disability or reduce the 

performance of personnel (e.g. vibration, 

toxic fumes, radiation, noise, shock, recoil). 

The process of applying tools and 

techniques drawn from organisational 

psychology, information science and 



system of systems domains in order to 

address the impact of introducing new 

equipment into complex enterprises. 

Table 1-2: HFI Domains 

1.2.3 HFI in Naval Projects – Objectives 

A naval system generally consists of a platform, equipment and associated 

personnel. A vessel is defined by the particular combination of a platform (the 

hull, internal layout and superstructure) and associated equipments, many of 

which require human interaction for both operation and maintenance. A vessel 

(surface ship or submarine) has also to provide an environment suitable for crew 

living, eating and recreation (ie not-working) as well as for work. 

Operational requirements are the main factors that dictate the design of naval 

systems. Manned naval systems will only achieve required levels of total system 

performance in a cost-effective manner if HF characteristics are properly 

integrated into the overall design and implementation of all systems. 

HF characteristics include the following: 

• The effective allocation of system functionality between human and 

equipment components; 

• Adequate manning and effective organisational design; 

• The design of operable equipment; 

• Appropriate training support; 

• Acceptable environmental and accommodation design; 

• Incorporation of appropriate health and safety measures. 

The main objectives of HFI for naval systems are concerned with the definition 

and management of all relevant human issues and risks that arise during 

platform and equipment design or modification (Figure 1-3). These objectives 

are summarised at the highest level as follows: 

• To define attainable levels of human workload and performance if the 

operational requirement is to be achieved at the levels of the force, the 

vessel and the individual sub-system. 

• To define the complement and skill requirements taking account of 

manpower policy. 

• To define the through-life cost implications of decisions concerning the 

manned operation, maintenance and training support of platforms and 

equipment. 

• To identify and take into account the human capabilities and limitations that 

must be considered for successful platform and equipment design. 



• To assess, evaluate and aid acceptance of the HF characteristics of 

platforms and equipment during the development process to ensure that 

the design supports effective, efficient, safe and acceptable job and task 

performance. 

• To ensure that Health and Safety standards and legislation are fully 

observed. 

• To ensure that the service conditions and quality of life onboard is 

acceptable to RN personnel and supports retention. 

• To ensure that cost-effective training and support for skills and knowledge 

development is provided onboard and ashore in accordance with training 

policy. 

System Safety 

& Health Hazards 

Operational 

Requirement 

Human-Equipment 

Functions & Tasks 

User-Equipment 

Interface Design 

Human 

Workload & 

Performance 

Total System 

Performance 

Training 

Needs 

Complement & 

Personnel 

Characteristics 

Environment 

& Accommodation 

Figure 1-3: Human Factors in Naval Systems 

1.2.4 HFI Technical Areas for Naval Systems 

The scale of naval equipment procurement ranges from the acquisition of 

complete new platforms and/or equipment systems to the provision of specific 

items of equipment for existing vessels. The procurement process itself may 

occur over a number of phases and involve requirements specification, design 

assessment and acceptance into service. HFI technical issues must be 

addressed in an appropriate manner at each phase of procurement for each type 

of platform or equipment. To support the naval procurement process, a series of 

‘HFI Technical Areas’ has been established with the following purposes: 



• To promote common understanding of HFI technical issues. 

• To summarise the management process and the stakeholders involved. 

• To provide guidance about HFI activities, outputs, methods and standards. 

HFI Technical Areas that affect the design and construction of the vessel, and 

affect its crew, include: complementing, training, deck and compartment layout, 

vessel maintenance and ship husbandry, overall environment and habitability, 

traffic flow and material handling and crew health and safety. HFI Technical 

Areas that affect the design and construction of the installed combat system and 

marine engineering equipment and systems include: manning implications, 

training, operability, workstation design and workspace layout, the local 

environment and health and safety aspects for equipment. Table 1-3 identifies 

these HFI Technical Areas and shows the HFI domains with which they are 

associated. 

All concerned must remember that HFI is not a self-contained process. HFI 

activities are undertaken to ensure that people-related issues are fully taken into 

account in other traditional areas of design and manufacture. In order to achieve 

this, frequent two-way communication between Human Factors specialists and 

those in other disciplines, e.g.: systems engineering, marine engineering, 

mechanical engineering, information system design, and logistics support. 

1.2.5 Relationship between HFI Domains, HFI Technical Areas and MAP- 

01-011 Chapters 

The HFI domains, see Table 1-3, help to elicit and to structure the HFI issues 

addressed in the HFI Programme. All documentation for the Investment 

Approvals Board (IAB) must use the HFI domains. It is essential that appropriate 

attention be paid to each HFI domain in total system design to achieve the best 

outcome. 

Manpower 

Personnel 

HFI Domains HFI Technical Areas MAP-01-011 

Chapter 

Reference 

Manpower, Complementing & 

Accommodation 

Chapter 4 

Team Organisation Chapter 5 

Crew and Equipment User 

Characteristics 

Chapter 6 

Training 

Crew and Equipment User 

Training 

Chapter 7 


General Arrangement Chapter 8 

Factors 

Operational Spaces Chapter 9 

Engineering 

(HFE) Accommodation Spaces Chapter 10 

Miscellaneous Spaces Chapter 11 



HFI Domains HFI Technical Areas MAP-01-011 

Chapter 

Reference 

System Safety 

Health Hazard 

Assessment 

Organisational 

and Social 

Personnel Movement & Material 

Handling 

Habitability & Internal 

Environment 

Chapter 12 

Chapter 13 

Equipment Layout Chapter 14 

Operability & User-Equipment 

Interaction 

Chapter 15 

Maintenance & Support Chapter 16 

Ship Safety 

System Safety 

Ship and Equipment Health 

Hazards 

Health Hazard Control 

Chapter 17 

Not yet fully determined and will be covered at a 

later issue. 

Table 1-3: HFI Domains, HFI Technical Areas and MAP-01-011 Chapters 

HFI Technical Areas are more specific to the type of system to be procured. 

Technical issues to be addressed during procurement are derived from the 

appropriate HFI Technical Area(s). 

Several HFI domains may be associated with each HFI Technical Area, e.g. the 

design of Operational Spaces will involve more than just the techniques and 

knowledge contributed by the Human Factors Engineering domain and will 

include those from Health Hazard Assessment, System Safety and Personnel 

domains. However, not all HFI Technical Areas may need to be addressed 

during a particular procurement project. During a refit to an existing platform for 

example, many design areas may be fixed. 

Whilst specialist parts of Integrated Project Teams will deal separately with 

platform issues and combat and marine equipment, there is a need for all parties 

to approach the procurement process in a fully integrated manner to ensure 

adequate exchange of requirements, constraints, design decisions and 

satisfactory system integration. 

MAP-01-011 provides details about the technical issues, the HFI process and 

associated activities, outputs, methods and standards for each of the HFI 

Technical Areas listed in Table 1-3. 

The Navigation Guidance Tables for HFI Activities and Outputs in MAP-01-011 

Chapter 2 provide checklists summarising the HFI activities and outputs in HFI 

Technical Areas that apply to each phase of the procurement process. These 

checklists provide cross-references to aid navigation between MAP-01-010 and 

MAP-01-011. 



1.3 Detailed HFI Domain Issues 

1.3.1 Manpower HFI Issues 

The central Manpower HFI issue for vessels is the estimation and validation of 

the crew size and composition, represented by the Scheme of Complement 

(SoC). This is because of the complex process of long-term manpower planning 

and the effect of manning on whole-life costs. The complementing process is 

described in ANEP 21 ‘Procedure for Ship Manning for NATO Surface Ships’ 

[Ref 19] and BR 4017 ‘Naval Manning Manual’ [Ref 7]. 

The complementing process for RN vessels addresses both the Manpower and 

Personnel HFI domains. The number and skill profiles of crewmembers are 

defined by the allocation of tasks to personnel. This allocation will occur at the 

platform level and at the level of component equipments. The contribution of 

each HFI Programme to the Basic Manning Requirement (BMR) estimates is 

collated at the platform level for input to complement modelling. 

The estimated numbers of personnel required to perform the operational and 

other duties in a vessel drives the SoC. The HFI Programme for a vessel 

provides these estimates from the earliest phases of the procurement process as 

contributions to the BMR. The BMR forms the basis for the Quarter Bill (QB). 

The QB is the basic working document for the design of the SoC for a new class 

of vessel, and remains the fundamental guidance document for the stationing of 

personnel through the operational life of the vessel. 

Manpower estimation for a vessel is a process that takes account of the following 

factors: 

• The missions that the vessel is expected to perform taking full account of 

concurrent activities and the level of autonomy required. 

• The allocation of functions between human and equipment on board the 

vessel. This determines the workload of tasks and duties and therefore the 

number of jobs. 

• RN requirements for the optimal number of personnel at the appropriate 

skill level to perform the operational task in order to make the most efficient 

use of available manpower. 

• Future RN Manpower Policy influenced by the expected Branch structure 

of the RN, demographics, retention factors and whole-life costs. 

• Existing organisational and manning practices (including those used 

outside the RN) that can provide lessons for future systems. 

Crew, team and sub-team organisation is defined based on the allocation of 

duties and tasks to groups of crewmembers. Outline job specifications are 

developed for each type of crewmember by collating the various tasks for 

evolutions, equipment operation, ship’s husbandry, maintenance and other duties 

identified in HFI Programmes. Accommodation standards, stores, traffic flows 

and communication systems may have important effects on the platform design. 

Manpower estimation needs to take into account mission and task workload, and 

will be heavily influenced by the success of automation and the ease of 

maintenance of the platform and its equipment. Manpower HFI requirements will 



also drive the design of accommodation, layout, services and provision of Escape 

and Evacuation facilities. Supportability of the platform or equipment will also 

influence the ashore manning requirement at dockside and throughout the 

logistics and training support chain. 

Human Factors provides methods for the analysis of the tasks and workload 

driving the estimated complement size for a vessel. Frameworks for conducting 

top-down functional allocation between human and equipment, and between 

different members of the crew have been developed. Some of these frameworks 

consider how human role allocation can be varied dynamically as a function of 

situation and operational workload, as technological constraints on the definition 

and the location of operator and maintainer posts are relaxed. 

Contributions to the Basic Manning Requirement must also be cross-referred with 

the Safety Case (see JSP 430 ‘Ship Safety Management’ [Ref 6]). The Scheme 

of Complement and any subsequent changes will affect overall ship safety. 

1.3.2 Personnel HFI Issues 

A clear understanding of the required characteristics of the crew or system users 

is fundamental to effective system design. A Project Specific Target Audience 

Description (PSTAD) is used to record the required personnel characteristics of 

operators and maintainers. The PSTAD is usually developed in the first phase of 

procurement and is progressively developed and used at subsequent phases. A 

technique known as Early Human Factors Analysis (EHFA) plays a key role in 

determining the need for, and the application of, a PSTAD. It is vital that each 

project is very clear about why a PSTAD is required, the role that it will perform 

and how it will be used. The development of a valid and authoritative PSTAD 

may require significant effort on the part of a large project. However, failure to 

properly represent personnel characteristics for use during the design will 

increase risks to operational capability, human safety and whole-life costs. HF 

issues deriving from the EHFA will also form an input to the Hazard Log as part of 

the Safety Case process. Subsequent revision of the PSTAD may be required as 

a means of mitigating HF issues. 

Target Audience Descriptions are developed as part of equipment programmes. 

A PSTAD is a systematic definition of crew physical characteristics, basic 

capabilities, skills, rank structure and Branches and relevant organisational and 

social factors. It is used to ensure that the development of platform and 

equipment matches human requirements. It is very important that this 

information is relevant for the future user population rather than simply reflecting 

current personnel or practices. The PSTAD should be collated at the platform 

level to check consistency and to ensure that personnel characteristics are taken 

into account during platform design. It should also consider the effect of real 

operational stress and environmental conditions on future human performance. 

The range of crew physical characteristics is relevant when addressing internal 

layout, escape routes and accommodation, workspace design and equipment 

control. The successful design of deck-head height, step size, access and 

egress routes and operator and maintenance positions will be determined by the 

actual physical size of personnel. The reach envelope of users must be 

modelled when assessing the usability of equipment. Accommodation must be 

designed to cater for privacy and other requirements for mixed gender crews. 



Lower and upper limits of basic capabilities including strength, hearing and vision 

need to be understood to ensure that the environment and operator task 

demands are properly designed. For example, basic visual acuity limits need to 

be considered in designing and locating warning labels and instructions on 

equipment or in compartments. Strength variation and handedness need to be 

considered when designing access handles and controls. 

Basic competence levels of RN personnel in use of language and the operation 

of computing devices is relevant during the design of computer-based information 

systems. For example, the readability or comprehension level of text both on-line 

and in document form will need to match the educational level of users. New 

systems may require skills and knowledge that are rare in the RN or even limited 

at a UK national level, e.g. systems management of information technology. 

Skills and rank requirements are determined by the mission profile for the vessel, 

its equipment fit and operational demands. Operational Performance Statements 

(OPS) define the high-level competencies required of RN personnel. Similar 

information is available in job specifications for personnel from the other services. 

These define the types of skills available in the organisation. It is important that 

the impact of the platform and the equipment on skill requirements is clearly 

understood. Training needs and the Human Factors Engineering of equipment 

are both heavily influenced by the skills and knowledge required for operation 

and maintenance. 

Organisational and social factors will also need to be taken into account to 

encourage retention and prevent skills loss. The quality and design of living 

accommodation and operational spaces may influence attitudes to serving on 

board and hence retention. The design of equipment and the workload 

associated with its operation may also influence job satisfaction. 

1.3.3 Training HFI Issues 

Training needs for each category of crewmember are collated and expressed as 

Operational Performance Statements (OPS) and Training Performance 

Statements (TPS) for the class of platform. OPS are owned by the Principal 

Accounting Officer (PAO) and are used by Fleet to express job-related training 

requirements. OPS already exist for different rank and role specialisations so 

this activity can concentrate on identifying changes to existing OPS and the 

definition of OPS for new roles. Training Performance Statements (TPS) that 

need to be achieved to meet each related OPS are maintained by Flag Officer 

Training and Recruiting (FOTR), which is responsible for the provision of training 

to the RN. The Fleet Air Arm training TPS reside with Fleet. However, on the 

completion of training, an assumed shortfall normally exists between the TPS 

and OPS, which is rectified by the provision of On-the-Job Training (OJT). The 

following equation is commonly referred to in order to indicate this relationship: 

OPS=TPS+OJT 

The procurement programme will therefore need to identify new TPS that arise. 

The list of current OPS is recorded in the PSTAD. Safety-related training needs 

will also need to be identified and integrated as required by JSP 430 ‘Ship Safety 

Management’ [Ref 6]. For example, the TPS needs to be cross-referenced with 

the minimum competency requirements specified by the Safety Case for 



operating equipment or for contributing to a safety critical task or management 

process. 

Individual, sub-team, team and crew training options for the platform are 

developed by collating the outputs of Training Needs Analysis (TNA) for the 

equipment and for the platform. This information contributes to the development 

of the training policy for the type and class of vessel. 

On-board training equipment, courseware, supporting resources, e.g. allocation 

of training duties to crewmembers, and trainee throughput are collated at the 

platform level. This information has a number of uses including the definition of 

on-board training procedures, estimation of the training margin for 

accommodation, identification of space and storage requirements and estimation 

of the total commitment to on-board training. 

The HFI Programme addresses the impact of new platforms and equipment on 

the skills and knowledge required of future operator and maintenance personnel 

(the Integrated Logistics Support (ILS) programme also addresses training 

needs). Both the HFI and the ILS programmes provide key inputs to the Training 

Needs Analysis (TNA). DSAT QS [Ref 8] defines a systematic approach to 

training and training quality issues, including the TNA process. DTSM3 ‘Defence 

Training Support Manual (DTSM) 3: Training Needs Analysis‘ [Ref 11] provides 

the common framework within which all three services conduct TNA. DTSM3 

replaces JSP 502 ‘The Tri-Service Guide to Training Needs Analysis (TNA) for 

Acquisition Projects’ [Ref 20]. However, JSP 502 continues to provide useful 

detail. 

MoD and RN Training strategy requires that the recommended training option is 

specified and delivered as part of the platform or equipment procurement 

programme. The chosen option can have a major impact on the whole-life costs 

of the system. A major question is the balance of training conducted ashore and 

afloat. Shore-based training provides more control over the learning 

environment, reduces on-board crew workload and accommodation and ensures 

that vessels are supplied with skilled personnel. However, training by shore 

establishments increases whole-life costs and may require a heavy investment in 

training technology. Team training time ashore may also be limited. IPTs should 

take into account the endorsed training strategy for individual training, collective 

training and training equipment procurement. 

Training media can be integrated within equipment. Alternatively, part-task 

procedural training devices and full simulations that federate several equipment 

types and systems may be used. On-board training using training simulations 

embedded in equipment provides advantages in terms of realism and team 

working but its use is limited by operational requirements. Developments in 

synthetic training and computer networking are likely to increase the flexibility of 

training options. This will enable more cost-effective mixtures of ashore and onboard 

training, e.g. smaller on-shore training establishments may manage and 

provide training resources directly to on-board crews via networked simulations. 

The costs and advantages of developing and running dedicated training 

equipment need to be balanced against those of using real equipment. 

Training needs are identified at the level of each individual operator or maintainer 

and at crew, team and sub-team levels. Training solutions must address the 

requirements for the conversion of existing personnel. Training must also cater 

for the initial and continuation training of personnel. A common problem is 

specifying prerequisite entry requirements for trainees. Technology may require 



the application of completely new basic operating skills and knowledge by RN 

personnel. 

The training products developed during procurement will form the basis for ongoing 

RN training. Resources to support training design ashore and on board 

are limited. Any development of training courseware should take into account 

existing RN quality standards. The strategy for courseware development needs 

to take into account the context, e.g. the role of industry in acting as a training 

provider, the policy for first of class training and the whole-life costs associated 

with training support. 

The design of training equipment, whether stand-alone or embedded within the 

real system, must also be subject to the same HFI requirements as the real 

equipment. Training equipment may require an instructor-user interface as well 

as the trainee user interfaces. The needs of instructors and trainers must be 

considered when designing training equipment. Instructor facilities may include 

scenario generation, recording, game control, monitoring of trainee performance 

and (for embedded training) control of segregation and rapid purging of training 

data. 

The design of the training roll-out programme will require extensive co-ordination 

with a number of RN training and other authorities. The timing of training is 

critical in avoiding any skills decay before crews start live operation of the 

equipment. 

1.3.4 Human Factors Engineering HFI Issues 

Of all the HFI domains, Human Factors Engineering (HFE) addresses the widest 

range of HFI issues and those of most central concern to the design of the 

platform and equipments. The issues in this domain are often those that most 

directly affect personnel on board the vessel, and which can affect their 

performance for better or worse. The range of HFE issues that arise during 

platform and equipment procurement include the following: 

• Workspace and workstation specification and design. 

• Use of Automation. 

• User-Equipment Interfaces and role of Human Factors Style Guides. 

• Layout of operational, accommodation and transit areas, escape routes, 

fixtures, fittings and equipment. 

• Environment in normal and abnormal working conditions. 

• System Integration. 

1.3.4.1 Compartment, Workspace and Workstation Specification and Design 

General arrangement, deck, compartment and workspace layout decisions 

require the collation of HFI information about the space needed by operators and 

maintainers. Each workspace is studied with regard to the human visual and 

movement envelope required by personnel performing tasks, transiting or 

handling materials in that area. 



Habitability requirements are collated at the platform level as they are determined 

by the design of accommodation spaces, environmental conditions and the 

provision of facilities to maintain the crew and provide comfortable living 

conditions. Environmental models are developed which take into account the full 

fit of equipment and the human activities to be performed, under normal and 

abnormal operating conditions, making use of information from related HFI 

Programmes. 

The measurement of total task workload when the operator is working with all 

equipments requires an integrated approach. Level of human workload, critical 

task performance and protection of vital operational aspects from human error 

are assessed across all systems and this may require a collation of information 

from different HFI Programmes. 

Standard Operating Procedures are created or modified for the vessels affected 

by procurement. The maintenance procedures and tasks, including ship’s 

husbandry, are collated and assessed across the platform to take advantage of 

common procedures and practices. 

The effectiveness of equipment will be determined in part by its operability. 

Operability criteria are defined for each type of equipment to determine the level 

of user performance that must be attainable. The characteristics of the userequipment 

interface play a major part in determining operability. The 

characteristics required for effective user-equipment interfaces are defined for 

related types of equipment. 

1.3.4.2 Layout of Operational, Accommodation and Transit Areas, Escape 

Routes, and Equipment 

The HFI Programme will need to address the layout of operator workspaces, 

maintainer access points, operational and accommodation compartments, transit 

and escape routes, upper deck structure, embarkation and disembarkation areas, 

and damage control points. 

Effective design considers a range of interacting factors. These factors include 

human reach and vision envelopes, furniture and fittings, comfort, communication 

between team members, traffic flow, equipment movement, storage and 

replenishment needs and activities, evolutions and the need for simultaneous 

activities in the same area, e.g. equipment repair in compartments during live 

operations. Human traffic flow should also be assessed for Escape Analysis 

purposes and is mandatory for the Escape and Evacuation Naval Authority 

(EENA) to issue a ‘Certificate of Safety – Escape and Evacuation’. 

Space may be at a premium on vessels, particularly in operational compartments. 

Simulation-based design and computer-assisted design can help to optimise the 

use of available space. 

1.3.4.3 Environment in Normal and Abnormal Working Conditions 

The physical environment within which human tasks are conducted must be 

designed to enhance system performance and limit human performance 

degradation. This requires attention in the HFI Programme to a wide range of 

ergonomic and environmental issues including ship motion, heat, ventilation, 

lighting levels, noise levels and vibration. 



Critical mission and task performance needs to be assessed under worst-case 

conditions throughout the range of possible climates, sea states, manoeuvring 

conditions and emergency or damage states, and forms part of the safety 

assessment for the platform. The effect of ship damage or equipment 

malfunction on the operating environment and on the feasibility of damage 

control also needs to be considered. Simulation-based design may be used to 

assist designers assess the effects of ship motion on task performance. 

1.3.4.4 User-Equipment Interfaces and Human Factors Style Guides 

Achieving a high level of operational effectiveness using computer-based 

systems requires the design and development of operable user interfaces. 

Within a warship there are a large number of diverse user-equipment interfaces 

to be found, ranging from combat system equipments, logistics and 

administration systems to complex machinery control and communications 

systems. A core activity of the HFI programme should focus on the compatibility 

of the proposed user interface with the following specific areas: 

• Task demands (e.g. the display of mission-related data in a form that can 

lead to rapid decision making); 

• Human operator capabilities (e.g. the provision of weapon or steerage 

controls taking account of human manual tracking speed and accuracy); 

• Other user characteristics (e.g. the design of grips on hardware equipment 

that can be manipulated by the full range of likely users). 

Every variant of user interface will require learning of display interpretation and 

control procedures. Hence, decisions concerning the user-equipment interface 

will impose overheads in terms of training and the transferability of operating 

skills. The use of documents known as Human Factors Style Guides helps to 

reduce these overheads by providing design standards for each class of user 

interface. Style Guides also exist or can be adapted for specific use on each 

class of equipment. 

A Human Factors Style Guide is used to document a set of rules and conventions 

to be used by equipment designers and implementers. The guide will typically 

address text message format, text presentation factors, use of symbols, use of 

colour, device layout conventions, labelling issues, alarm message format, etc. 

Common style requirements are developed for all types of display and control 

found in the platform. Consistent and common design principles are applied to 

the user interface style of different equipments, to the passive and active alarms 

and warnings, during the selection of mechanical operating controls, and in the 

design of maintenance warning and advisory labels etc. 

Commercially available human-computer interface style guides have been 

adapted for military use to provide consistent rules for the design of windows, 

icons, menus and input device operations. The use of commercial-off-the-shelf 

equipments can, at first sight, lead to inevitable differences in user-interface 

characteristics. However, an explicit assessment of the impact of any userequipment 

style differences helps to ensure that negative effects are anticipated 

and either designed out or highlighted in standard operating procedures and 

during training. Appropriate use of the style guide should be mandated in 

procurement documentation. 



1.3.4.5 User Input to Equipment Interface Design 

Experience has demonstrated that the early involvement of users and RN subject 

matter experts is critical for the effective design of user-equipment interfaces. 

The HFI Programme therefore needs to ensure that such involvement is planned. 

Tools are available to support early simulation of user-equipment interfaces. 

Critical design issues, requiring user involvement, must be resolved efficiently 

and effectively. Scenario-based design walk-throughs and equipment 

prototyping are cost-effective techniques for user involvement when combined 

with the use of low-cost mock-ups. 

1.3.4.6 Use of Automation 

Equipment functions include computer-based, mechanical and electrical facilities 

for the operational role and to maintain habitability. During the platform and 

equipment design process decisions are made about the degree of automation 

and the role of human users and maintainers. The allocation of functions 

between human and equipment is a key process in the HFI Programme. The 

ultimate operational value and supportability of a platform and its equipment will 

hinge on obtaining the best balance between the use of automatic or mechanised 

solutions and human resources. 

The use of automation has a major impact on the size and composition of the 

complement. Failure to consider all of the tasks and duties required for 

equipment operation and maintenance, ship husbandry, damage control, mission 

requirements and domestic activities may result in unacceptable crew workload 

and subsequent limitations in vessel effectiveness. 

The allocation of tasks between human and equipment must form an explicit part 

of the design process. For example, computer-based systems can be used in 

virtually every area of a vessel from the Combat System to ship control 

equipment. The HFI Programme needs to ensure that the software design 

method provides sufficient information for the purpose of evaluating human task 

implications to determine operator workload, skill requirements, and humancomputer 

interface design and maintenance needs. 

1.3.4.7 System Integration HFI Issues 

System integration is the co-ordinated design and assessment of individual, 

team, equipment, layout and environmental issues. While specific Human 

Factors work may address each of these issues in relative isolation, it is only 

through an integrated approach that their joint effect can be properly assessed. 

This approach is equally important whether the system is developed to meet new 

requirements or comprises commercial-off-the-shelf components. 

1.3.5 System Safety HFI Issues 

The inherent ability of the system to be used, operated and maintained without 

risk of injury or death to personnel must be addressed in the HFI Programme. 

These adverse conditions may occur when the system is functioning in a normal 

or an abnormal manner. Every design decision may impact on system safety to a 

greater or lesser degree and may affect the risks to humans from damage, 

equipment malfunction or operator error. These risks must be continually 



assessed for the full range of interacting factors (design of equipment interfaces; 

workspace and compartment layout; movements of humans and equipment; 

environmental conditions; operational duties, recreational activities and 

maintenance tasks etc.) described in related HFI Programmes. 

Safety must be managed in accordance with JSP 430 ‘Ship Safety Management’ 

[Ref 6]. The safety management system defined in JSP 430 addresses both the 

System Safety and the Health Hazard Assessment domains. This will normally 

result in the production of a Safety Case for the vessel and associated 

equipments. These will be collated and the System Project Managers should 

ensure that the HFI issues are addressed consistently throughout. 

The Ship Safety Management System is the focus for integrating the results of 

HFI activities related to system safety. The HFI Programme must help to ensure 

that safety risks and safety mitigation are continuously addressed and entered 

into the Safety Case. Human Factors Engineering activities and products provide 

information and opportunities to address safety issues. This includes the 

identification of abnormal system states due to human error, poor operability, 

equipment malfunction, and extreme environmental conditions and vessel 

damage. 

While personnel can contribute to safety as well as detracting from it, typical 

levels of human error tend to be very high. A high proportion (some 70% to 95%) 

of marine accidents can be attributed to the human element. Poor design of the 

working environment is one of the main contributory factors to this. 

Vessel safety issues include assessments of human vulnerability and survivability 

in relation to the structural layout, the composition of structural materials and 

fittings and the effects of shock and motion. Damage control is of particular 

interest for three reasons: 

1. The survivability of personnel in deck areas and compartments that is 

subject to damage. 

2. The protection of the teams tasked with controlling fires or repairing other 

types of damage. 

3. The number of personnel that need to be diverted from other tasks to 

engage in damage control and fire fighting will drive the overall size of the 

complement, see BR 4017 ‘Naval Manning Manual’ [Ref 7]. 

System safety issues apply equally to the design of accommodation areas under 

normal peacetime conditions of use. System safety issues must also be 

addressed for scenarios when the rapid Escape and Evacuation of personnel is 

required. Operations under Chemical, Biological, Radiation and Nuclear Defence 

(CBRND) conditions increase safety risks of exposure or contamination as well 

as increasing the probability of certain types of human error. 

Human reliability analysis tools are available for use in the HFI Programme to 

identify and estimate the probability of possible sources of human error. A large 

body of knowledge has accumulated from the application of these techniques in 

the nuclear power and other industries that is applicable to the design of power 

plant (both nuclear and conventional) and other systems. 



1.3.6 Health Hazard Assessment HFI Issues 

Health hazards can occur in working and recreational areas of the vessel and are 

distinguished from safety risks as they can arise during normal operation of the 

system. The HFI Programme needs to define the risk of such hazards and 

ensure that platform and equipment design, operating procedures and training 

eliminate or minimise their impact and maximise crew health. 

The range of potential health hazards that apply across platform and equipment 

programmes include the following: 

1. Acoustic – Hearing loss from exposure to continuous or intermittent noise, 

e.g. in machinery rooms, prolonged wearing of headsets. 

2. Biological – Infections from micro organisms, their toxins and enzymes, 

e.g. in galleys. 

3. Chemical – Inhalation, ingestion or direct contact with toxic substances, 

e.g. hydraulic fluid. 

4. Oxygen deficiency – Reduced performance or asphyxiation, e.g. poorly 

ventilated compartments. 

5. Radiation – Radiation from ionising and non-ionising sources, e.g. 

proximity to high-powered radar equipment. 

6. Shock – Shock arising from equipment operation or ship motion, e.g. 

electric, extreme movements. 

7. Temperature extremes and humidity – Extremes leading to reductions in 

performance, or more serious effects on health, e.g. excessive heat 

generated by proximity to operating equipment. 

8. Trauma – Physical trauma resulting from direct impact to the body or 

musculo-skeletal trauma due to the need to lift excessive weights or 

continuously operate equipment, e.g. repetitive strain injury associated with 

using input devices for computer-based or other equipment. 

9. Vibration – Vibration arising from the contact of mechanically oscillating 

surfaces with the body, e.g. the effect of the platform motion envelope in 

different compartments. 

10. Visual – Loss or serious impairment of sight due to exposure to high levels 

of light energy, e.g. lasers; eyesight problems from prolonged use of visual 

display units. 

The identification and recognition of health hazards in the HFI Programme helps 

to ensure that these are designed out. In a vessel hazards may arise from many 

sources. These may be structural including the provision and location of 

drainage facilities, the ease of cleaning surfaces, the absorption of surface 

finishes, toxic and other characteristics of furnishing and surface finishes and the 

effects of leakage or interactions between substances. Hazard prevention will 

affect the design of operating procedures, shift lengths and rest periods, rotation 

of relief operators, the design of protective equipment, compartment layout, 

hazard zoning and training and raising awareness. Preventative programmes 

and facilities can be designed to counter these types of health hazard and to 



promote health through positive action, e.g. segregation of smoking areas, 

provision of exercise facilities. 

Health hazards and issues need to be collated and checked to ensure that all 

preventative measures are in place and the relevant standards are applied. 

Health hazards can occur in many forms. Health may be affected by basic 

operation of equipment (e.g. repetitive strain injury, muscular strain), exposure to 

extreme environmental conditions (noise, vibration, ship motion, heat), bacterial 

infection in galleys or washrooms and exposure to environmental emissions or 

materials. 

Hazards and operability (HAZOP) analysis provides a method for combined 

identification of safety and health hazards to crew, see Def-Stan 00-56 ‘Safety 

and Management Requirements for Defence Systems’ [Ref 21]. However, it 

should be noted that some long-term health hazards might require additional 

investigation and advice from the Institute of Naval Medicine (INM) and Medical 

Director General (Navy). 

1.3.7 Organisational and Social HFI Issues 

Organisational and Social issues are not yet fully determined and will be covered 

at a later issue of this document. 

1.3.8 HFI Trade-Offs 

HFI provides an inclusive framework for use in optimising the use of automation, 

the size of organisation, skill development and training, operability, habitability 

and health and safety. The seven HFI domains and the HFI Technical Areas 

provide a vehicle for identifying, analysing and accounting for factors that affect 

the human contribution to overall system performance. Decisions made within 

each particular domain may appear to be optimum within that area. However, 

the contribution of each individual domain on overall system performance must 

be considered. 

In order to optimise overall system performance, it is often necessary to conduct 

trade-off analyses between individual factors. It is necessary to consider total 

system trade-offs at the earliest phase of procurement. 

HFI trade-offs at the level of the total naval system are usually conducted during 

the earliest phases of procurement and include the following examples: 

1. Platform size, shape and speed and its effects on human 

performance, habitability and crew health and safety – Optimising the 

platform for speed, manoeuvrability and survivability will impact crew 

performance and well-being. For example motion-induced interruptions 

affecting crew performance will be dependent on the architecture of the 

platform and its resulting motion characteristics. The trade-off performed 

must balance platform options against crew performance, platform 

habitability and crew health and safety. 



2. Reduction in complement size against the costs and risks of 

increased automation – Platform development and whole-life costs are 

closely related to the size of the complement. Increased automation can 

reduce some aspects of crew workload and may decrease the manning 

required. The trade-off performed must determine the extent to which 

investment in increased automation actually provides the capability to 

reduce crew workload and complement size while still delivering the 

required outputs. 

3. Reduction in complement size against the costs and feasibility of 

increases in the skill levels of personnel – The core functions of moving 

and fighting a vessel require skilled personnel. Increasing the use of 

automation may decrease crew size at the cost of increasing the variety 

and depth of skills required amongst the remaining personnel, e.g. 

additional system management skills might be required. The trade-off 

performed must determine the costs and feasibility of recruiting, training 

and retaining personnel with the required skills. 

4. Reduction in training against the costs of increasing the operability of 

the platform and the equipment – The simplification of platform and 

equipment design, including the increased use of automation, may 

increase operability and hence decrease training costs. The trade-off 

performed must determine the costs of increasing operability against the 

savings in the training that can actually be achieved. 

5. Assignment of training ashore and on-board – Training to develop, 

maintain and extend skills may be conducted at shore establishments or on 

board vessels. Shore training establishments increase whole-life costs but 

decrease on-board crew size and workload. Investment costs in training 

simulation are determined by decisions about whether training equipment 

is developed for stand-alone use ashore or is embedded within on-board 

operational equipment. Required operational skills will only be produced if 

the training environment enables initial learning and allows existing skills to 

be developed further. The trade-off performed must determine the 

optimum assignment ashore and on board given investment and whole-life 

costs and the effectiveness and efficiency of the training that will be 

provided. 

1.4 HFI Contribution to Project Outputs 

Only the HFI contribution to project plans is discussed in this chapter. For 

information on the HFI contribution to requirements, see Chapter 3. 

1.4.1 Overview of the HFI Inputs 

HFI yields value by influencing project outputs. In the early phases, such project 

outputs are mainly documents, e.g. requirements and plans. As the project 

progresses, solutions begin to predominate. Documents are the major 

determinants of what system is acquired, and the ‘solution’ is its implementation. 

HFI contribution to documents should not be restricted to the ‘HFI section’, as the 

contents of many other areas will have human implications and such documents 

should be reviewed in full to determine the applicability for HFI. HFI contribution 

(from the IPT) to ‘solutions’ is mainly supportive and enabling. 



The influence of HFI on the future system is made effective mainly through the 

project deliverables (at Initial Gate and Main Gate). These include: 

1. Requirements – URD, draft SRD, SRD. 

2. Plans – Phase plans; TLMP; HFIP; HFI contributions to other plans (ILS, 

Safety, etc.). 

3. Contract SoW – Statements defining HFI tasks for Suppliers within the 

overall MoD co-ordinated activity. 

4. Justification – Evidence and analyses to support assertions about system 

cost effectiveness based on the viability, cost and performance of the 

human component of the system. 

HFI must begin in Concept phase, with an analysis of human issues related to 

the acquisition of the proposed capability, and an assessment of the associated 

risks and requirements. The HFI objective during Concept is to ensure that the 

phase outputs submitted at Initial Gate take account of any human-related 

issues, which could seriously affect the ability to meet the project’s objectives. 

In Assessment, more detailed work is undertaken to understand, quantify and 

begin to reduce the HFI risks identified during Concept phase. This will involve 

exploring major issues, such as manpower reduction, workload, performance 

shortfalls or safety, and a larger number of smaller items. Assessment involves a 

systematic and informed assessment of options using simulation, modelling, 

prototypes and mock-ups to capture requirements and identify where savings can 

be made. HFI ensures Suppliers are clearly focused on the issues, as well as 

addressing them within MoD. Results are represented in the phase outputs 

submitted at Main Gate. Here, the outputs are as above, but also include the 

revised URD, SRD, ITT SoR and COEIA. 

1.4.2 HFI Contribution to Plans 

1.4.2.1 Types of Plans 

The plans typically used in the HFI process and discussed in this chapter are of 

two broad types: 

1. Management Plans – These define what will be carried out, when, by 

whom, to what criteria, with what resource, under what assumptions, with 

what dependencies. 

2. Specialist ‘Plans’ – These are more comprehensive than management 

plans. They contain extra supporting information, records of key decisions 

and results that help to justify the plan. These include the Integrated Test, 

Evaluation and Acceptance Plan (ITEAP, see Section 1.4.3), Safety Plan, 

Reliability Plan, and Integrated Logistics Support Plan (ILSP). HFI requires 

co-ordination with many of these plans. The Through Life Management 

Plan (TLMP, see 1.4.4) is an umbrella structure embracing all of these as 

well as the outline vision of the project through life. 



1.4.2.2 Human Factors Integration Plan (HFIP) 

There should be an HFI section in the Through Life Management Plan for each 

phase, typically supported by reference out to a more detailed Human Factors 

Integration Plan (HFIP). Effective HFI relies on good communication across 

technical areas and organisations, with regular access to user representatives 

(subject matter experts and hands-on users). See Chapter 4 for more detailed 

information on the HFIP. 

1.4.3 Integrated Test, Evaluation & Acceptance Plan (ITEAP) 

1.4.3.1 HFI Contribution to the ITEAP through the Procurement Cycle 

The Integrated Test, Evaluation & Acceptance Plan (ITEAP) is a key document 

defining how the project will ensure that the required ‘equipment capability’ is 

being produced, and then confirm that it has been. Those aspects of the 

capability that relate to integration between human and equipment components 

require HFI input to the ITEAP. 

The ground for ITEA must be laid during Concept, with the ITEAP completed in 

outline by Main Gate, and fully developed in Demonstration prior to contract let. 

It will then evolve throughout the remainder of the procurement cycle. See 

‘Practical Guidance for IPTs’ [Ref 17] for a fuller description of HFI actions for 

ITEA throughout the CADMID cycle. 

1.4.3.2 HFI Content of the ITEAP 

Table 1-4 introduces the HFI content needed for the ITEAP. Items should be 

complete by Main Gate except where noted. 

Section 

Introduction 

Scope of 

system 

System 

acceptance 

strategy 

Typical HFI Related 

Content 

Background to HFI 

requirements 

Describe the human 

component and identify key 

interactions between human 

and equipment (subject to 

HFI acceptance). 

Strategy for acceptance 

against HFI requirements 

and how it fits in overall 

acceptance strategy. 

Comment 

Brief philosophy underlying 

operability evaluation – 

importance of human 

performance as a measure of 

equipment operability. 

Identify any complicating 

factors, e.g. incremental build 

up of equipment function 

might prevent full role-based 

operability testing until later 

phase. 

Underlying principles of 

operability acceptance. 

Scope for use of common 

scenarios, dual use of trial 

opportunities, etc. 



Section 

Acceptance 

risk statements 

Overall 

process 

Derivation of 

acceptance 

criteria 

Acceptance 

risks and 

strategy 

Acceptance 

activity 

Assessment 

and review 

process 

Resource 

management 

Plans 

Typical HFI Related 

Content 

Describe HFI risks to be 

removed by evaluation and 

acceptance. 

Describe how the equipment’s 

ability to integrate 

with, and support the human 

elements will be evaluated, 

tested and accepted. 

Identify the criteria required 

for HFI testing and how they 

will be derived. 

Process for deriving test 

thresholds from the 

requirements. 

Describe how risks inherent 

in the acceptance process 

will be managed, together 

with any imposed 

constraints. 

Describe how HFI evaluations 

and tests will be 

conducted. 

Describe how HFI evaluations 

and tests will be 

validated, and the process 

for handling subjective data 

gathered during trials. 

Describe how HFI evaluation, 

test and acceptance 

will be managed, especially 

how it will be integrated with 

non-HFI activity. 

Include a section on HFI 

evaluation and acceptance 

plans, calling up more 

detailed trials plans, acceptance 

schedules, etc. 

Comment 

Supported by links to humanrelated 

items in the project 

risk register. 

This should identify the main 

areas, e.g. physical 

compatibility, legibility, 

comprehensibility, task 

performance, task 

degradation over time, health 

and safety. 

Likely to require a combination 

of independent reference 

data and early trials to 

confirm criteria. Note that 

tests involving human performance 

must account for 

intrinsic human error rates. 

Risks might include trial 

subjects being unfamiliar with 

new equipment and procedures. 

Constraints might 

be practical limit on numbers 

of trials and subjects. 

Outline only at Main Gate – 

Complete during 

Demonstration phase. 

Outline only at Main Gate – 

Complete during 

Demonstration phase. 

Only needed after Main Gate 

for ITEAP, but note that resource 

estimates should be 

included in TLMP and in the 

plan for Demonstration phase. 

Only needed after Main Gate 

for ITEAP. 

Table 1-4: HFI Content of ITEA Plan 



1.4.4 Through Life Management Plan (TLMP) 

The Through Life Management Plan (TLMP) is a key project document, see 

Chapter 2, and the AMS provides guidance on its production and use, see 

‘Through Life Management – Guidance’ [Ref 31]. The Human Factors Integration 

Plan (HFIP) must identify the dependencies and interfaces between HFI activities 

with other disciplines in the context of the overall Through-Life Management Plan 

(TLMP). 

1.4.4.1 HFI Activities 

The TLMP enables stakeholders to inform and visualise the project, by 

presenting a whole-life perspective of its objectives, assumptions, plans and 

resources. Its aim is to demonstrate completeness, realism and relevance. The 

TLMP is an articulation by the IPT Leader (and each System Project Manager 

within the IPT that manages more than one project) to their customers and key 

stakeholders of how they will manage their project through its life, i.e. their 

response to the task set within the Customer Supplier Agreement (CSA). The 

TLMP brings all aspects of and information for the project to a central focal point 

for stakeholders and provides a gateway into the detailed project information. 

1.4.4.2 HFI Content of TLMP 

The TLMP consists of a set of documents, all of which will be updated as the 

project progresses. HFI contributions to the TLMP should include: 

• HFI strategy 

• HFI issues log 

• Key HFI decisions 

• Long-term outline Human Factors Integration Plans (HFIPs) 

• HF working group constitution and procedures 

• Division of responsibility between various stakeholders in HFI regarding 

shared activities such as PSTNA, TAD, Task Analysis and user support. 

This should form part of the PRM (Programme Responsibility Matrix). 

• Procedures for management and sharing of Human Factors (HF) data 

throughout the life cycle 

• Key HFI trials results 

• HFI audit results following introduction to service 

• HFI management strategy for evolutionary upgrades. 



1.5 HFI Contribution to Agreements 

1.5.1 HFI Focus Relationships 

HFI activities called up by the Human Factors Integration Plan (HFIP) to be 

carried out by organisations outside the IPT will require either a contract or a 

Customer Supplier Agreement (CSA). These must be supported by explicit 

Statements of Work (SoWs) that define what is required, to the same level of 

detail as the project HFIP. 

The IPT is at the hub of a network of formal agreements about how to provide the 

capability. The HFI Focus is responsible for helping to set up those agreements 

in a way that supports the project HFI needs, and then managing the day-to-day 

liaison throughout the project to ensure that the agreements work. Figure 1-4 

portrays these relationships schematically. 

HFI Consultant eg 

SSG, DSTL, 

‘Customer Friend’ 

from Industry 

Figure 1-4: HFI Focus Relationships 

1.5.2 Contracts and Invitations to Tender (ITTs) 

Work by bodies outside MoD will be subject to a contract, normally preceded by 

an Invitation to Tender (ITT). A Statement of Work (SoW) must support them 

both. SoWs for (potential) equipment and/or service suppliers should specify the 

following: 

• The evidence to be produced in support of claims about the operability etc 

of equipment solutions (including details of how it was derived). 

• The use to be made of military users (subject matter experts and hands-on 

users). 

• The information to be exchanged with other HFI stakeholders. 

• The format and timing of information, demonstrations, trials, etc. 



SoWs for HFI support should specify the following: 

• Relationship with IPT and division of responsibilities for HFI. 

• Scope of HFI analysis, evaluation, trials, etc. to be undertaken. 

• The use to be made of service users (subject matter experts and hands-on 

users). 

• The information to be exchanged with other HFI stakeholders. 

• The format and timing of information, demonstrations, trials, etc. 

1.5.3 Customer Supplier Agreements (CSAs) 

CSAs are the equivalents of contracts within MoD. The Acquisition Handbook 

[Ref 2] focuses on the IPT’s agreement with the DEC to supply equipment and/or 

equipment support. CSAs, in respect of aspects of capability outside the IPT’s 

control, help the IPT to meet its wider remit of providing capability. Most of these 

involve people, and come within the scope of HFI. Each CSA should be 

supported by an explicit Statement of Work (SoW) to define what is required, to 

the same level of detail as the Human Factors Integration Plan (HFIP). How this 

is written will vary with the work and who is doing it. 

There will be CSAs for the supply of capability in respect of doctrine, force 

structure, manning, training, sustainability, integration, interoperability, etc from 

the supplier to the DEC as customer. Supporting CSAs are needed to enable the 

IPT to deliver equipment capability that is effectively integrated with the human 

component. CSAs between the IPT and other parts of MoD need to cover three 

other main areas: 

1. Provision to the IPT of information about future personnel who will form the 

human component of the capability. 

2. Provision of people to support the IPT and Supplier(s) during the project. 

3. Provision of the human component of the capability. 

The first of these concerns information typically covering the characteristics, 

skills, aptitudes, numbers and availability of people, how they will be trained and 

organised, their other tasks and responsibilities, and so on. 

The second will include the type of subject matter experts to support the IPT, 

equipment designers and supporting analysts. It will also include the need for 

timely access to representative service personnel to take part in evaluations, 

trials, etc. It is very easy to underestimate the need for this type of support. 

The third relates to the design of the total system (human and equipment). For 

the whole to be reliably engineered, tested and accepted, each separately 

supplied component (human as well as equipment) must have defined 

boundaries, and defined performance at those boundaries. Any trade-off 

affecting budgets, e.g. between training and equipment cost or between 

manpower and automation cost must be negotiated within this CSA. 



(This page is intentionally left blank) 

Nov 2006 Page 1-36 Issue 4 

MAP-01-010 CH 1_15.doc

CHAPTER 2 – HFI PROCESSES AND MECHANISMS 

CONTENTS 

2.1 An Overview of Smart Acquisition and HFI..................................................................2-3 

2.1.1 Introduction ...........................................................................................2-3 

2.1.2 The Equipment Capability Customer ....................................................2-4 

2.1.3 The Joint Capability Board and Capability Management ......................2-4 

2.1.4 The Second Customer Function ...........................................................2-5 

2.1.4.1 Core Leadership.................................................................2-5 

2.1.4.2 Pivotal Management...........................................................2-5 

2.1.5 The Integrated Project Team ................................................................2-5 

2.2 Key Project Documents and Events in the Acquisition Cycle .............................2-6 

2.2.1 The User Requirement Document (URD) .............................................2-6 

2.2.2 The System Requirement Document (SRD).........................................2-6 

2.2.3 The Through-Life Management Plan (TLMP) .......................................2-6 

2.2.4 Acceptance and In-Service Date ..........................................................2-7 

2.3 The HFI Component of System Readiness ........................................................2-7 

2.3.1 People KIP Issues...............................................................................2-10 

2.4 Introduction to HFI Processes and Mechanisms ..............................................2-14 

2.4.1 Overview of HFI Mechanisms .............................................................2-14 

2.5 System Integration............................................................................................2-15 

2.5.1 The Components of Operational Capability........................................2-17 

2.5.2 Defence Lines of Development...........................................................2-18 

2.5.3 DLOD Inter-relationships ....................................................................2-20 

2.5.4 The ‘People’ Line of Development ......................................................2-20 

2.5.5 Trade Off Analyses .............................................................................2-21 

2.5.6 System Properties...............................................................................2-22 

2.5.7 People Requirements Definition .........................................................2-23 

2.5.8 People-Related Needs........................................................................2-23 

2.5.9 Intrinsic Human Needs........................................................................2-24 

2.5.10 Capability Related (Extrinsic) Human Needs......................................2-24 

2.5.11 Project Related Human Needs ...........................................................2-25 

2.5.12 Readiness Levels................................................................................2-25 

2.6 HFI and the CADMID Lifecycle.........................................................................2-26 

2.6.1 Concept Phase ...................................................................................2-27 

2.6.1.1 Objectives.........................................................................2-27 

2.6.1.2 HFI Focus Responsibilities during Concept .....................2-28 

2.6.2 Assessment Phase .............................................................................2-30 

2.6.2.1 Objectives.........................................................................2-30 

2.6.2.2 HFI Focus Responsibilities during Assessment ...............2-31 

2.6.3 Demonstration Phase .........................................................................2-33 

2.6.3.1 Objectives.........................................................................2-33 

2.6.3.2 HFI Focus Responsibilities during Demonstration ...........2-34 



2.6.4 Manufacture Phase.............................................................................2-35 

2.6.4.1 Objectives.........................................................................2-35 

2.6.4.2 HFI Focus Responsibilities during Manufacture...............2-36 

2.6.5 In-Service Phase.................................................................................2-37 

2.6.5.1 Objectives.........................................................................2-37 

2.6.5.2 HFI Focus Responsibilities during In-service ...................2-38 

2.6.6 Disposal Phase...................................................................................2-39 

2.6.6.1 Objectives.........................................................................2-39 

2.6.6.2 HFI Focus Responsibilities during Disposal .....................2-39 

2.7 Project Role Terms of Reference .....................................................................2-39 

2.7.1 IPT Leader and Systems Project Managers .......................................2-39 

2.7.2 HFI Focus Terms of Reference...........................................................2-40 

2.7.3 Supplier Terms of Reference..............................................................2-40 

2.7.4 HF Specialist Terms of Reference ......................................................2-41 

2.8 Multidisciplinary Groups HFI Focus Checklist ..................................................2-41 

2.8.1 HFI and Operational Analysis .............................................................2-42 

2.8.1.1 Operational Analysis HFI Focus Checklist .......................2-42 

2.8.2 HFI and Ship Design...........................................................................2-42 

2.8.2.1 Ship Design HFI Focus Checklist.....................................2-43 

2.8.3 HFI and Systems Engineering ............................................................2-43 

2.8.3.1 Systems Engineering HFI Focus Checklist ......................2-43 

2.8.4 HFI and ILS.........................................................................................2-44 

2.8.4.1 ILS HFI Focus Checklist...................................................2-45 

2.8.5 HFI and Health & Safety .....................................................................2-46 

2.8.5.1 Health & Safety HFI Focus Checklist ...............................2-46 

2.8.6 HFI and Training .................................................................................2-46 

2.8.6.1 Training HFI Focus Checklist ...........................................2-47 


Chapter 2 – HFI Processes and Mechanisms 

2.1 An Overview of Smart Acquisition and HFI 

2.1.1 Introduction 

The information contained in this chapter is derived from various sources, in 

particular: ‘The Acquisition Handbook’ [Ref 2], the ‘Acquisition Management 

System’ [Ref 16] and JSP 502 ‘Tri-Service Guide to TNA’ [Ref 20]. 

This section sets HFI in its procurement context. In order to do so it is necessary 

to outline the Smart Acquisition process in terms of the core relationship between 

the customer and the supplier. At each phase of the acquisition process, there is 

a requirement for Human Factors (HF) input. Later in this chapter, these HFI 

activities are outlined against each of the acquisition phases. Under the Smart 

Acquisition philosophy, acquisition progresses through a series of phases 

designed to take the project through its whole life from Concept to Disposal. 

These phases include: Concept; Assessment; Demonstration; Manufacture; In- 

Service and Disposal. Together they are commonly referred to as the ‘CADMID 

cycle’. 

Figure 2-1 below gives an overview of the organisations involved in the 

acquisition process. These are discussed in detail in subsequent sections. 

Customer 1 

Equipment 

Capability 

Customer (ECC) 

Deputy Chief of Defence 

Staff (Equipment 

Capability) 

Within the ECC, a Joint 

Capability Board (JCB) 

exists, comprising: 

CM 

Precision 

Attack 

CM 

Information 

Superiority 

DG 

Equipment 

DG 

Research & 

Technology 

CM 

Battlespace 

Manoeuvre 

DEC Above 

Water 

Effects 

DEC CCII 

Dir Capab 

Resource & 

Scrutiny 

Dir Analysis 

Expt & 

Simulation 

DEC 

Special 

Projects 

DEC 

Expedition 

Log & Supp 

DEC Under 

Water 

Effects 

DEC Deep 

Target 

Attack 

DEC 

ISTAR 

Director 

Equipment 

Plan 

Dir Equip 

Capability 

Secretariat 

Dir 

Concepts & 

Technology 

Military 

PoC for DG 

(R&T) 

CWG/DEC 

Air & Lit 

Man CWGs 

DEC Chem 

Bio Rad & 

Nuclear 

DEC 

Theatre 

Airspace 

DEC 

Ground 

Manoeuvre 

Directors of 

Equipment 

Capability 

(DEC) act as 

customer to 

Integrated Project Teams (IPTs) 

Customer 2 supports ECC decisions on 

equipment capability by providing 

advice and experience on concepts, 

doctrine, sustainability, training, force 

structure, personnel. 

IPT tasked with the acquisition of new 

capabilities. 

IPT function performed by Defence 

Procurement Agency (DPA) until 

manufacture when it transfers to the 

Defence Logistics Organisation (DLO). 

Figure 2-1: Major Organisations involved in the Acquisition Process 



2.1.2 The Equipment Capability Customer 

The Equipment Capability Customer (ECC) is responsible for developing and 

managing a balanced and affordable equipment programme to meet the current 

and future needs of the Armed Forces. 

The ECC is responsible for: 

1. Requirements Definition – The capture, analysis, specification and 

progressive refinement of Capability needs to form a User Requirements 

Document (URD). 

2. Equipment Planning – The prioritisation and balance of investment 

between and within capabilities. 

3. Seeking Approvals – In conjunction with IPT Leaders. 

4. Authorising Acceptance – The confirmation that the need for equipment 

capability has been met by the systems supplied. 

2.1.3 The Joint Capability Board and Capability Management 

Within the ECC organisation, a Joint Capability Board (JCB) exists. This is 

headed by the Deputy Chief of Defence Staff (Equipment Capability) (DCDS 

(EC)) and comprises a number of Capability Managers (CM), the Director 

General Equipment and the Director General (Research and Technology). The 

JCB is responsible for: 

• Providing strategic direction, based on departmental priorities. 

• Making Balance of Investment (BOI) decisions across the entire Equipment 

Programme. 

Each Capability Manager is responsible for a defined area of capability and has a 

number of Directors of Equipment Capability (DEC) who are responsible for 

projects. The DEC forms one or more Capability Working Groups (CWGs), which 

include representatives from all stakeholders in the capability area, including the 

IPT Leaders. 

Capability Working Groups are the primary means by which the views of 

stakeholders are accounted for and provide advice from which the empowered 

DEC makes decisions. The functions of the Capability Working Groups are: 

1. Strategic Planning – To include the review of current and predicted 

capability, capability gaps, potential equipment. 

2. Concept Development – The CWG’s principal output is specific 

equipment concepts as options to meet capability gaps, commissioning 

high-level operational analysis and applied research. This may lead to the 

development of a User Requirements Document (URD) and outline 

equipment options with cost, time and performance parameters that can 

form the basis of an Initial Gate business case. The CWG, in conjunction 

with the Capability Manager and the IPT, will sponsor a requirement 

through the Initial Gate Approval. 



3. Equipment Capability Acceptance – The DEC is the Acceptance 

Authority but the CWG is closely involved in the development of the 

Integrated Test, Evaluation and Acceptance Plan, the review of the 

Acceptance Submission by the IPT Leader, advice on formal Acceptance 

and subsequent Release to Service. 

The responsibility for HFI is shared between the Capability Working Group and 

the IPT. HFI helps the IPT and CWG work together, trading off changes that 

might be needed in equipment with changes to people and procedures to ensure 

total system effectiveness. 

2.1.4 The Second Customer Function 

Customer 2 is the user of the equipment capability and has two key roles, Core 

Leadership and Pivotal Management role. These are discussed below. 

2.1.4.1 Core Leadership 

This role is undertaken by the Single Service Chiefs and supports the ECC 

decisions on equipment capability by providing advice and experience on the full 

range of factors making up military capability, including concepts and doctrine, 

sustainability, training, force structure and personnel. Single Service Chiefs are 

responsible for ensuring that the Joint Capabilities Board and CWGs receive 

appropriate input on such matters for future equipment capability. 

2.1.4.2 Pivotal Management 

This role is undertaken by the end-users of equipment, primarily the Front Line 

and Training Commands. This role focuses on in-service equipment and 

includes responsibility for defining the in-service outputs sought from the IPT and 

monitors IPT delivery performance. As the new equipment enters service, 

Customer 2 takes on the lead customer role and confirms with the IPT the level 

of in-service support required including availability, sustainability, and training to 

be provided. 

2.1.5 The Integrated Project Team 

The Integrated Project Team (IPT) is responsible for translating the ECC’s 

expression of the user requirements (the User Requirement Document (URD)) 

into an output-based statement of what the system must do to meet these 

requirements (the System Requirement Document (SRD)). The IPT will also 

devise and cost equipment solutions to meet the SRD, produce the material 

required to support the Customer’s Main Gate Approval and manage the 

development, manufacture, in-service support and eventual disposal of the 

equipment. At the Manufacture phase, the control of the IPT passes from the 

DPA to the DLO. The IPT deals with the ECC mainly through the DEC. 



2.2 Key Project Documents and Events in the Acquisition Cycle 

It is important to realise that in most cases HFI outputs are produced to support 

other project documents, processes and outputs. As such, HFI deliverables need 

to be appropriately justified cross-referenced and linked. The need for particular 

HFI activities and any resulting outputs must be linked to actual need within a 

project context. 

The following are the key Project Documents and Processes that are agreed 

between the Customer and the IPT. An overview is given of HFI inputs to each 

of these documents and processes in the following sections. 

2.2.1 The User Requirement Document (URD) 

The User Requirements Document (URD) is the means by which the DEC 

develops, communicates, and maintains the user’s requirement throughout the 

life of the system. The URD also provides the benchmark against which the 

analysis of trade-offs is conducted and provides the criteria against which the 

final solution will be validated. It consists of a complete set of individual user 

requirements supported by other documents and identifies a set of Key User 

Requirements (KURs). 

HFI must begin at the URD development stage with an analysis of the human 

issues related to the acquisition of the proposed capability, and an assessment of 

the user requirements and risks. Human Factors input to the URD is therefore 

essential. An HFI objective during Concept is to ensure that the project phase 

outputs such as the URD take account of any human-related risks and issues 

that could seriously affect the ability of the system to meet the project objectives. 

2.2.2 The System Requirement Document (SRD) 

The SRD defines, in output terms, what the system must do to meet the user 

needs as defined in the URD. The linkage between individual requirements in 

the URD and the SRD is maintained to show the origin of every demand placed 

on the system and how each user requirement is met. 

During the Assessment phase, HFI activities are undertaken to quantify and 

begin to reduce the HFI risks identified during the Concept phase. This involves 

a systematic assessment of options using HF analysis, simulation, and modelling 

mock-ups, to capture requirements and assess risk. 

2.2.3 The Through-Life Management Plan (TLMP) 

The TLMP represents an integrated through-life approach to managing 

acquisition. This starts as soon as the ECC has identified the capability gap and 

continues up to the point of final disposal. The TLMP acts as a project 

‘knowledge base’ with related documents and sub-plans, for use in planning and 

decision-making. The TLMP applies throughout the CADMID lifecycle and draws 

out interdependencies between different parts of the project and with other 

projects. 

The TLMP is the repository for project plans and related documents, see also 

Chapter 1. As such it will contain Human Factors documents such as the Human 

Factors Integration Plan (HFIP, see Chapter 4), and other relevant documents. 

HFI input to other specialist plans, such as the Safety Plan and the ILS Plan, will 

also be required. 



2.2.4 Acceptance and In-Service Date 

The DEC is the Acceptance Authority. At an early stage during the acquisition 

process, the IPT Leader and the DEC will agree an acceptance strategy that will 

identify how the acceptance process will be applied, and will enable an Integrated 

Test, Evaluation and Acceptance Plan (ITEAP) to be drawn up. Acceptance is a 

progressive process that goes through the following stages, see Table 2-1. 

Stages 

Acceptance 

‘Stage’ 

Description 

1 User and 

System 

Requirement 

2 Design 

Certification 

3 Initial 

Acceptance 

4 System 

Acceptance 

5 In-Service 

Date 

Acceptance occurs when these requirements and the 

acceptance criteria are endorsed by end users and 

stakeholders. 

Agreed by the IPT Leader 

This takes place where Service use is required before 

System Acceptance is achievable. 

System Acceptance determines whether the system 

acquired by the IPT satisfies the SRD as assessed by 

the DEC. 

In-Service Date is declared when the military 

capability provided by the system is assessed as 

available for operational use. In-Service Date 

acceptance requires that there is a usable quantity of 

the system integrated with all essential supporting 

elements declared by the DEC. 

Table 2-1: Project Acceptance Stages 

HFI input to the acceptance process is required at an early stage. In many 

projects, HFI input to the Integrated Test, Evaluation and Acceptance Plan 

(ITEAP) is necessary to detail the types of Human Factors analysis, testing and 

acceptance criteria required to ensure that the user requirements are met. In 

addition, HFI input to Stage 1 of the Acceptance process is enabled via HFI 

mechanisms such as HFI Working Groups, HF analyses and initial user testing 

with mock-ups and early prototypes. HFI input to user trials to support System 

Acceptance is usually required. 

2.3 The HFI Component of System Readiness 

The MoD Acquisition Management System (AMS) identifies the need to 

periodically assess project progress in relation to planned targets in order to 

successfully manage risk. A major contributor to this process is the concept and 

application of System Readiness Levels (SRLs) to assess the maturity of a 



project in relation to defined measurement topics, known as Key Integration 

Parameters (KIPs), and defined milestones. 

For maritime projects, including both surface ships and submarines, a Maritime 

System Maturity assessment process is used. In this process, the SRL concept 

is expressed as Maritime System Maturity Levels (Maritime SMLs). Table 2-2 

summarises the nine Maritime SMLs, which span all project phases from Concept 

Exploration to Acceptance Sea Trials. 

Maritime 

SML Level 

SML 1 

SML 2 

SML 3 

SML 4 

SML 5 

SML 6 

SML 7 

SML 8 

SML 9 

Descriptor 

Needs Analysis / Concept Exploration 

Concept Definition / Feasibility Design 

Overall Ship Design 

Ship Sub-system Design 

Detailed Design Integration 

Ship/Submarine Test and Acceptance Planning 

Ship/Submarine Assembly 

Post-Launch Outfit, Tests and Trials 

Acceptance Sea Trials 

Table 2-2: Maritime System Maturity Levels 

The MoD guidance document, ‘Maritime System Maturity’ [Ref 22], provides: 

• The background to the Maritime SML process. 

• The structure and technical detail of the Maritime SML assessment 

scheme. 

• Special requirements for Initial Gate and Main Gate milestones. 

• Special requirements for Naval Authority Regulation (relating to project 

areas that require formal certification, such as Vessel Stability, OME, and 

Escape & Evacuation). 

• Details of individual key issues and requirements. 

Within the Maritime System Maturity assessment process, the KIPs embrace 

Naval Architecture, Marine Engineering, Information Management, Combat 

System Engineering, Whole Ship Issues, Marine Interoperability, Safety, People, 

Reliability and Maintenance and Integrated Logistic Support. 

Human Factors issues are addressed under the KIP heading of ‘People’, which 

embraces both HFI and the training of operational staff. However, the HFI Foci 



must remember that Human Factors issues may arise in other KIPs, such as 

Habitability and Escape & Evacuation - (Naval Architecture KIP), Survivability 

(Whole Ship Issues KIP), System and Equipment usability (Maritime 

Interoperability KIP), Operating Instructions (Safety KIP). 

The Maritime SML schema relates to three ‘Systems Engineering Stages’ 

(SESs), namely: 

• Requirements Formulation - Concept Development SES. 

• Engineering Development (Design & Construction/Trials Planning) SES. 

• Construction and Trials SES. 

Within each Systems Engineering Stage, a number of Maritime SML stages 

apply. The relationship between the Maritime System Maturity Levels and the 

CADMID Cycle Phases is illustrated in Figure 2-2. 

CADMID 

Cycle Phase 

Maritime SES 

Maritime 

SML 

HFI Input 

INITIAL 

GATE 

MAIN 

GATE 

CONCEPT 

ASSESSMENT 

DEMONSTRATION 

Requirements 

Formulation/Concept 

Definition SES 

Engineering 

Development SES 

Maritime SML 1 





Appropriate 

HFI Activities, 

Events and 

Milestones 


MANUFACTURE 

Construction & 

Trials SES 




IN-SERVICE 

Ongoing HFI 

Support to 

Operations 

and In-Service 

Capability 

Upgrades 

DISPOSAL 

HFI Input to 

Safe Disposal 

Figure 2-2: Relationship Between Maritime System Maturity Levels and 

CADMID Cycle Phases 



2.3.1 People KIP Issues 

The detailed scope of People KIP issues is shown within the Maritime SML 

schema, see Table 2-3 through Table 2-11 below. 

SML 1 - Needs Analysis / Concept Exploration. 

KIP Topic 


Management 

Issues. 

Key Requirements 

• IPT HFI Manager appointed with agreed Terms of Reference. 

• IPT HFI Focus appointed with agreed Terms of Reference. 

• Project HFI Strategy Defined. 

• Draft Human Factors Integration Plan (HFIP) produced. 

• Stakeholder and User Groups identified and appropriate 

Working Groups convened. 

• HFI Issues Log/Risk Register created. 

HFI Technical 

Issues. 

• Baseline assumptions and constraints documented. 

• Mission and Operational Analyses conducted. 

• Early Human Factors Analysis (EHFA) complete. 

• Initial HF Impact Assessments complete. 

• High-Level Function, Task and Role analyses complete. 

• Project-Specific TAD created from RNGTAD. 

• Initial Complementing Estimates complete. 

• Initial Training impact assessment complete. 

Table 2-3: Maritime SML 1 KIP Requirements 

SML 2 - Concept Definition / Feasibility Design. 

KIP Topic 



Issues. 


Issues. 


• HFIP complete, agreed, disseminated and in use. 

• HFI Issues Log/Risk Register fully populated. 

• PS-TAD fully populated, disseminated and in use. 

• PS-TAD management system in place. 

• Mission analyses, Operability Scenario analysis and Functions 

analysis complete. 

• Key User Needs and inputs identified. 

• Essential Task Analyses complete. 

• Allocations of Functions confirmed. 

• User roles, tasks and activities defined. 



• Key Human Performance Issues identified and analysed. 

• Complementing studies mature. 

• HMI and HCI Design Principles agreed. 

• Training Analyses mature. 

• HF Trade-Off Analyses mature. 

• Cost of People Component well understood. 


SML 3 - Overall Ship Design. 

KIP Topic 



Issues. 


• HFIP updated and re-issued. 

• HFI Sub-Plans produced and agreed. 

• HFI Issues Log/Risk Register agreed. 

• TLMP updated from HFI information. 


Issues. 

• Detailed SOC produced. 

• TNA Complete. 

• HMI and HCI initial designs produced. 

• HMI Style Guides identified, selected or created as appropriate. 


SML 4 - Ship Sub-System Design. 

KIP Topic 



Issues. 


Issues. 


• HFIPs updated and re-issued as necessary. 

• HF Issues, Risks and Mitigations fully mature. 

• Compartment, workspace and workstation designs mature. 

• Detailed HMI and HCI design substantially complete. 

• Initial Operability Trials underway. 

• Training system URD mature, based on completed TNA. 




SML 5- Detailed Design Integration. 

KIP Topic 



Issues. 


Issues. 



• Key HF Issues Log items closed out. 

• Detailed HMI and HCI design fully complete. 

• Operator instructions mature. 

• Equipment Operability assessments mature. 

• Confirm validity of TNA against maturing HMI and HCI designs. 

• Safety-related operator actions identified and validated. 

• HFI Input to Ship Safety Case mature. 


SML 6 - Ship/Submarine Test and Acceptance Planning. 

KIP Topic 



Issues. 


Issues. 



• Equipment Operability Trials planning complete. 

• Identify User/Equipment mismatches and evaluate impacts. 

• Verify Operational and Training Performance Statements. 

• Draft Operating Instructions and Guidance produced. 


SML 7 - Ship/Submarine Assembly. 

KIP Topic 



Issues. 


Issues. 



• Operator Workload analyses complete. 

• Operator Performance evaluations complete. 

• Situational awareness analyses complete. 

• Operability Trials planning complete. 



• Operational and Training Performance Statements verification 

complete. 

• Safety-related human performance analyses complete. 

• Procedural mitigation of safety risks verified. 

• HFI contribution to Ship Safety Case complete. 


SML 8 - Post-Launch Outfit, Tests and Trials. 

KIP Topic 



Issues. 


Issues. 



• Operability Trials complete. 

• Contractual acceptance of HF-related features (with appropriate 

input from HFI SMEs). 

• HF Aspects of ITT via ITEAP verified. (with appropriate input 

from HFI SMEs). 

• Operating procedures and User Instructions verified and safety 

aspects approved by Safety Authority. 

• Procedural risk mitigations proved and signed off. 

• Operability trials complete and accepted. 

• Necessary interoperability features demonstrated. 

• Procedural mitigation of safety risks proven and demonstrated. 


SML 9 - Acceptance Sea Trials 

KIP Topic 



Issues. 


Issues. 



• Document human and organisational lessons learnt to inform 

future capability upgrades and new systems. 

• Provide support for capability upgrades in-service. 

• Finalise and validate TNA. 

• Ensure TNA identifies course/lesson content and plans. 




2.4 Introduction to HFI Processes and Mechanisms 

2.4.1 Overview of HFI Mechanisms 

This section introduces the processes and mechanisms for conducting HFI within 

a project. The key project and HFI objectives are outlined along with an overview 

of the HFI activities required to achieve these objectives. The information 

contained within this section is taken from the ‘Introductory Guide’ [Ref 3] and the 

‘Practical Guidance for IPTs’ [Ref 17]. This chapter does not describe HFI 

technical activities, which are described in more detail in MAP-01-011 [Ref 1]. 

Subsequent sections and chapters within this Guide provide greater detail to the 

topics highlighted in this section. 

The processes and mechanisms described in this and subsequent chapters are 

the means by which Human Factors is addressed within the project. It is the role 

of the IPT Leader and the appointed HFI Focus to determine how these 

processes will be managed and who is responsible for this management. In 

some cases, the HFI Focus may be directly responsible for ensuring that these 

elements are carried out. In many cases, however, the HFI Focus will delegate 

responsibility to the HF Supplier or an HF Specialist within the IPT. Figure 2-3 

shows a representation of the activities within the HFI process. 

Figure 2-3: HFI Process Activities 

The core process of HFI is focused on an understanding of human-related 

issues, risks and opportunities for the project. Several key processes are 

implemented to manage these issues and the HFI processes are addressed 

within this Guide as follows, see Table 2-12. 



HFI Process 

MAP-01-010 Chapter 

Co-ordination MAP-01-010, Chapter 3 

Identifying and managing 

requirements 

Identifying and managing the 

issues 

Contribution to project outputs 

(and plans) 

The Human Factors Integration 

Plan (HFIP) 

Managing and monitoring the 

project 

MAP-01-010, Chapter 3 





Managing acceptance MAP-01-010, Chapter 3 

HFI Process 

MAP-01-011 Chapter 

Supporting analysis MAP-01-011, Chapters 4-17 

Table 2-12: Guide to HFI Processes within the STGPs 

There is a degree of overlap between these processes, such that the outputs 

from one process may inform another. 

2.5 System Integration 

Two principal objectives of MAP-01-010 and its companion volume MAP-01-011 

are to facilitate the acquisition of Naval operational capability, and to optimise the 

integration of that capability into existing Naval operational, management and 

training systems. 

This is a complex process that needs to be addressed from the outset of a 

project. This section of the Guide describes current and emerging approaches, 

methods and tools with which to better manage system integration issues. These 

approaches use the concept of an overall system with various components, and 

provide structures against which the need for particular HFI Focus activities can 

be determined. 

A potential barrier to good HFI within a project is any approach that focuses on 

the procurement of equipment, rather than the procurement of capability, 

particularly in the early stages of a project. Early focus on equipment can result 

in a (defective) HFI process in which the role of people in a system is entirely 

determined by needs generated by equipment design or choice. This is likely to 



result in sub-optimal solutions, sub-optimal system performance and possible 

deleterious effects on the human component of the system. 

Whilst this guide is directed to Naval capability acquisition, the principles 

discussed here may be applied to Land and Air capability components. As 

technology enables greater degrees of interactive working between Sea, Air, and 

Land forces, the need for a more consistent tri-service approach to capability 

integration will become increasingly prominent. 

For the purposes of discussion, Military Operational Capability can be regarded 

as a collection of systems that operate with varying degrees of interaction and 

cooperation, see Figure 2-4. The systems are called socio-technical systems, 

because they comprise not only inanimate components, such as land, buildings, 

platforms, and large and small equipment, but also an animate component; the 

people who direct, use, and support the inanimate parts. 

MILITARY CAPABILITY 

SYSTEM 1 SYSTEM 3 

SYSTEM 2 

MANAGEMENT 

SYSTEM 

SUPPORT SYSTEM 

Figure 2-4: Capability Component Interactions 

Military systems comprise fixed assets, platforms, equipment, materiel and 

people in a wide variety of combinations. Each of these elements may be 

regarded as a ‘component’ of the system. System components may be linked 

physically, electronically, logically or organisationally. 

In reality, the ‘People Component’ is distributed throughout the system in the 

form of operators, maintainers, supporters, facilitators, managers, and many 

other specific roles. The people component operates under structures, and in 

accordance with a wide range of operational, social and ethical ‘rules’, expressed 

in the form of policies, directives, regulations, procedures and many other, less 

formal mechanisms. 

The complexity of such systems creates a challenge for the HFI Focus and 

others concerned with Human Factors Integration. It is important to remember 



that the goal of HFI is not to ‘fit’ the people component into the technological part 

of the system. The goal of the HFI process is to integrate the people component 

WITH the technology, logistic and organisational components using appropriate 

methods and tools. 

2.5.1 The Components of Operational Capability 

In very simple terms, Overall Capability can be regarded as comprising two 

principal components: the Technology Component (of Operational Capability) 

(TCOC) and the People Component (of Operational Capability) (PCOC), see 

Figure 2-5. 

Socio-Technical 

Systems 

(Who does what, where, when, 

how, why and with whom) 

People 

Technology 

Figure 2-5: Principal System Components 

Historically, MoD Acquisition processes have focussed effort on the technological 

components of operational capability. In today’s Defence environment, the 

significance of the People component, measured both in terms of the cost of 

ownership and operational effectiveness, is an increasingly important 

consideration. In order to achieve cost-effective systems, it is vital that system 

functions are appropriately assigned to the various system components 

(Allocation of Functions). 

At the formation of Human Factors as a formal discipline, system functions were 

often regarded as carried out by people OR carried out by machine. 

Developments in technology, particularly in the capability of computer-based 

systems, now means that this simple, dualistic model does is inadequate to 

ensure satisfactory integration of People into systems. In practice, the allocation 

of functions and tasks between people and technology requires a more 

sophisticated approach that recognises a continuum of possible allocations, see 

Figure 2-6. In some situations, task allocation may be carried out dynamically at 

the initiation of the machine component, but under the overall control of the 

human. 



Best done by 

humans, but 

can be done 

by machine 

Can only be 

done by 

humans 

Best shared between 

humans and machines 

Can only be done by 

machines 

People 

Best done by 

machines, but 

can be done 

by humans 

Technology & Equipment 

Figure 2-6: Allocation of Functions Continuum 

2.5.2 Defence Lines of Development 

An increasingly useful tool to assist with the Human Factors Integration process 

is the Defence Lines of Development (DLOD). The DLODs provide a defined 

structure against which to address HFI issues across single and multiple 

capabilities, and thus achieve coherence in capability evolution. For the early 

stages of a project (Pre-Concept, Concept and into Assessment phases), the 

DLOD structure provides a more comprehensive taxonomy than that provided by 

the HFI Domains, which have greater application in the Design, Manufacture and 

Testing stages. There are eight DLODs 1 , see Table 2-13. 

DLOD 

Concepts and 

Doctrine 

Principal Components 

• The expression of required future capabilities 

• The expression of the principles which guide military 

forces actions 

• The authoritative codification of how military activity is to 

be conducted 

• Arrangements for inter-force and International cooperations. 

Related HFI 

Domains 

Personnel • Manpower numbers 

• Personnel characteristics 

• Personnel capabilities 

• Recruitment 

• Retention 

• People structures 

• Ethos, morale and motivation 

• Career development 

Manpower 

Personnel 

1 These definitions are derived from ‘Defence Lines of Development’ [Ref 23] published by the Joint 

Doctrines and Concepts Centre (JDCC). The terminology used is consistent with JWP 0-01.1 ‘UK 

Glossary of Joint and Multinational Terms and Definitions’ [Ref 24]. 



DLOD 


• Release 

• Terms and Conditions 

• Manning requirement 

• Manpower plans 

• Schemes of Complement 

• Personnel management and administration 


Domains 

Organisation • Military Force structures 

• Military Branch structures 

• MoD Civilian organisational structures 

• MoD Support Supplier structures 

Training • Training facilities 

• Training equipment 

• Training materials 

• Training staff 

• Training methods (Collective & Individual) 

• Training programmes 

Manpower 

Personnel 

Training 

Equipment 

Information 

Infrastructure 

All operational and non-operational, deployable and nondeployable 

equipment: 

• Platforms 

• Equipment 

• Hardware 

• Software 

• PPE 

• Materiel 

• Legacy systems 

The timely provision of coherent data, information and 

knowledge to support capability in an operational context, 

including data, information and knowledge: 

• Acquisition 

• Storage 

• Processing 

• Dissemination 

• End use 

• Security 

Fixed and permanent: 

• Land 

• Work-related buildings 

• Berths 

• Training areas 

• Training buildings, areas and locations 

• Accommodation 

• Storage facilities 

• Housing 

• Structures 



Engineering 



Engineering 



Engineering 



DLOD 


• Utilities 

• POL facilities 

• Facility management services 

• Estate development 


Domains 

Logistics • Maintenance of forces 

• Materiel acquisition 

• Materiel storage 

• Materiel transport 

• Materiel distribution 

• Transport of personnel 

• Acquisition, construction, maintenance, operation and 

disposal of facilities 

• Provision of services 

• Provision and support of medical and health services 

Table 2-13: Defence Lines of Development (DLOD) 

2.5.3 DLOD Inter-relationships 

In the case of both the DLODs and the HFI Domains, intelligent use of each 

framework is essential. The two taxonomies exist to support structured analysis 

and issues management. They must not be seen as isolated stove piped boxes 

in which issues are considered in isolation. The concept of INTEGRATION of 

Human Factors issues between the individual DLODs and the individual HFI 

Domains remains paramount. 

2.5.4 The ‘People’ Line of Development 

For the HFI Focus, a particularly useful emerging concept is that of a ‘Super 

LOD’, namely the People Line of Development, see Figure 2-7. The People Line 

of Development subsumes a number of the DLODs in whole or part, and 

provides a useful concept through which to summate and address people-related 

issues. 



Created by 

people, Concepts 

and Doctrine 

determine how 

people operate 

and use 

equipment. 

Logistics 

DLOD 

Concepts & Doctrine 

DLOD 

Personnel DLOD 

Human-Machine Interface 

Infrastructure DLOD 

The PEOPLE Super LOD 

Organisation DLOD 

Training DLOD 

Information DLOD 

Provides the 

physical 

environment in 

which People 

work. 

Provides the 

structures in 

which People 

work. 

Provides People 

with the required 


Capabilities. 

Provides Data, 

Information and 

Knowledge with 

which People 

work. Some 

information is 

provided by the 

Equipment; some 

by Humans. 

Equipment DLOD 

Figure 2-7: The People Super Line of Development 

2.5.5 Trade Off Analyses 

The People ‘Super LOD’ forms a so-called ‘trade space’ in which the many 

required trade-off decisions can be made, taking into account the impact of a 

decision in one DLOD on other related DLODs. 

The equipment component of the solution cannot be optimised in isolation. 

Equipment trade-offs that change the performance or function at the interface 

with the human component (operators, maintainers or support staff) must be 

assessed to determine how they affect the human performance. Likewise, 

opportunities to improve human performance, to reduce training or manning, etc. 

through changes to equipment must also be explored. 

A key activity in the Pre-Concept and Concept phases is to develop an adequate 

understanding of the human-related risks and opportunities in a proposed project 

or range of project options. This understanding is required to underpin all 

subsequent HFI activities, since the human component is a major source of cost, 

and usually a critical factor in system effectiveness. Early Human Factors 

Analysis (EHFA) is a simple, systematic process for identifying and assessing 

human issues, and then deciding how to manage them. Pointers to humanrelated 

risks can be found in operational experience, changes to the operational 

context, procurement constraints and research programmes. Risks identified in 

Concept should be reviewed, and any new risks assessed. Quantifying humanrelated 

risks requires detailed analysis, which will vary with the nature of the risk. 



Decisions taken at Main Gate are dependent on being able to make good 

estimates of overall cost and effectiveness of each technology option. Humanrelated 

costs typically dominate Whole Life Costs, and detrimental human 

performance caused by poor Human Factors Integration can undermine the 

effectiveness of apparently good equipment. The human dimension of the 

Combined Operational Effectiveness and Investment Appraisal (COEIA) is 

therefore critical, more so when the options differ significantly in nature. See 

‘Practical Guidance for IPTs’ [Ref 17] for guidance on how to assess human 

performance impact and human-related costs in support of the COEIA process. 

2.5.6 System Properties 

In addition to the DLODs, JDCC documentation highlights the need to consider 

overarching themes, such as Interoperability. The Interoperability theme may be 

considered to be one example of a number of ‘essential system properties’ that a 

system should possess. Such properties include: 

• Affordability 

• Safety 

• Ability to be Licensed (nuclear and safety-critical) 

• Operability (including ability to be Manned) 

• Interoperability 

• Maintainability 

• Sustainability 

• Ability to be Integrated into wider systems 

• Ability to be Upgraded 

• Suitability for safe Disposal 

For a given system, these various property requirements may conflict in whole or 

part, and may thus call for trade-offs to be considered. The relative importance 

of these properties and the absolute importance to MoD will be project-specific 

parameters and these must be determined in the early phase of the project. 

Some of these may be addressed in the User Requirement Document (URD), but 

others may need to be explored with Stakeholders and researched in some 

detail. 

Development of System Property Requirements is greatly assisted by 

considering a Capability in a systematic manner. New tools to facilitate the 

process of assessing the impact of a proposed Capability or to compare different 

Capability options are being developed. 

Capability Impact Assessment tools seek to provide a comprehensive framework 

against which a new Capability, or a Capability upgrade can be assessed. In the 

early stages of a project, concepts may (rightly) be only loosely defined and be 

fluid. This may be particularly true for the People Component, where several 

Manning options may be available, with consequent implications for levels of 

automation and technology implementation. New technology may imply radical 



changes to existing recruiting, selection, training and deployment systems and 

practices. 

In this process, a high degree of trade-off analysis may be required to identify an 

optimum solution. Research may be needed to provide the necessary supporting 

data. It is important to understand the degree to which User Requirements and 

in particular Key User Requirements (KUR) are negotiable in order to apply tradeoff 

analyses appropriately. 

The impact assessment process should consider all aspects of the capability, 

including the essential system properties described above. The DLOD 

framework provides one schema on which to base an assessment. A refinement 

of the People Super-LOD structure is being developed (known as ‘PCOC-IMT’). 

Advice on the availability of these tools can be obtained from SSG-CSHF, 

DCDS(Pers) and Customer 1 (EC AWE-FSC), see Annex 2. 

2.5.7 People Requirements Definition 

People Requirements for Naval Capability are rightly the province of Customer 2 

(2SL). Improved methods and tools to define and communicate Customer 2 

Personnel Line of Development Principles are being developed by FLEET – 

ACOS(NPS), the PLOD champion. A strategic level generic document is being 

produced with links to related documents and information that will give guidance 

on more detailed people related requirements. 

Advice on the PLOD principles can be obtained from SSG-CSHF, CVF and T45 

2SLLO’s and FLEET-NPS SPOL CUST2 SO2 - see Annex 2. 

2.5.8 People-Related Needs 

People requirements can be separated into a number of subsets, based on 

physical, psychological, social and behavioural theory. A so-called hierarchy of 

human needs exists 2 , see Figure 2-8. Basic needs include air, water, light, 

safety, etc. At higher levels in the hierarchy, social factors such as social 

interaction, job satisfaction and self-development operate. If lower level needs 

are not adequately met, performance in the higher order functions is degraded. 

2 Maslow ’54 ‘Motivation and Personality’ [Ref 25]. 



Self-development Needs: 

personal growth and fulfillment. 

Organisation. 

Personnel. 

Training. 

Self-esteem Needs: 

status, responsibility, achievement. 

Organisation. 

Personnel. 

Training. 

Social Needs: 

Service, work group, family, friends. 

Organisation. 

Safety Needs: 

security, defined and stable rules for behaviour and 

working. 

Concepts & Doctrine. 

Organisation. 

Biological and Physiological Needs: 

air, water, food, shelter, warmth (cooling) sleep, etc. 

Infrastructure. 

Human Factors Engineering. 

Figure 2-8: Hierarchies of Human Needs 

2.5.9 Intrinsic Human Needs 

In this hierarchy, lower-level human needs are often taken to be axiomatic and 

therefore not explicitly defined by the Customer. User Requirements Documents 

(URD) will typically not address such details, simply defining overall conditions of 

operation or focussing only on capability-related human needs. A key role of the 

Human Factors discipline is to systematically define and expound such basic 

needs. Solutions to such needs can be defined using universal ergonomics data, 

and will be met through the application of best practice in the Human Factors 

Engineering HFI Domain. 

Conversely, the designers of equipment may fail to take into account the higherorder 

human needs, believing them to be under the control of the Customer and 

User organisations. Successful Human Factors Integration requires that all levels 

in this hierarchy to be addressed in development of system solutions. This 

requires fully interactive working between Capability provider, Customer and User 

organisations, to arrive at mutual understandings of the absolute and relative 

importance of Human requirements in a particular project situation. 

2.5.10 Capability Related (Extrinsic) Human Needs 

A given Capability will require the human component within the system to 

perform certain tasks and achieve certain goals. The details of these may be 

mission-specific or context-dependant. These requirements will lead to certain 

human needs. Some such needs may be expressed in the User Requirements 

Document, but are often expressed in the form of design constraints, e.g. “the 

capability shall be able to operate under environmental conditions defined in Def 

Stan 00-30”. Whilst it may be possible to design equipment to operate under 



such conditions, it may not be realistic to require humans to work under the same 

set of conditions. Such a requirement therefore leads to a secondary derived 

requirement for a more controlled work place environment for the human 

component. 

Capability-related requirements will typically be contained in System 

Requirements Documents (SRD). Typically, Capability-related Human Needs 

will be expressed in functional terms, such as “the system shall enable the 

user to … “. To determine Human Needs from such a statement requires 

decisions on how system functions are to allocate to Humans and machines, 

together with a full understanding of how the Human will interact with the 

machine and with other human components within the system. 

2.5.11 Project Related Human Needs 

In addition to intrinsic human need and capability-related human needs, other 

prescriptive requirements that impact upon human needs may have to be 

considered. For policy or doctrinal reasons, the Customer may, for example, 

dictate a particular organisational structure, method of operation or manning 

philosophy. Such decisions may present design constraints that impact upon the 

way in which the human component of a system must be integrated, and thus 

may generate Human-related needs. 

2.5.12 Readiness Levels 

Within the concept of SMART procurement and the CADMID cycle, the DPA 

Acquisition Management System defines a project-wide scheme, that of System 

Readiness Levels (SRL), through which the maturity of a project may be 

assessed in terms of Key Integration Parameters (KIP). This scheme identifies 

both Technical and Project Management issues. Key Integration Parameters 

include Human Factors Integration and Training as specific items. 

The concept of System Readiness Levels expands upon the proven, but more 

restricted concept of Technology Readiness Levels (TRLs). Within the SRL 

Schema, People issues are embedded within appropriate topic areas. It is 

important to recognise that, in this context, the term People Readiness Level 

does not refer to the readiness of individuals or groups of Service men and 

Service women to undertake their operational roles. This is assured through 

MoD recruitment, selection and training systems. In the context of SRLs, viz. 

Figure 2-9, the term refers to the maturity of the various systems and the 

processes by which sufficient people, having the appropriate knowledge skills, 

abilities and motivation will be made available at the correct time, to operate and 

maintain the capability. 

People 

Readiness 

Levels 

System Readiness 

Levels 

Technology 

Readiness 

Levels 

Figure 2-9: Readiness Level Components 

Whilst many, if not all, of these systems are under the control of Customer 2, 

DPA staff, including the HF Focus, cannot assume that the ‘systems’ will 

automatically include requirements for what is needed. Therefore a formal 

process is needed. 



For Naval Projects, a domain-specific process exists to assess project maturity, 

see previously Section 2.3. 

2.6 HFI and the CADMID Lifecycle 

Figure 2-10: The CADMID Phases 

The HFI management process follows the structure of Smart Acquisition in 

general, from Concept through to the Disposal Phase, see Figure 2-10. The 

following overview of HFI lifecycle activities applies: 

• Concept 

HFI must begin in the Concept phase, preferably in any Pre-Concept phase, with 

an analysis of human issues related to the acquisition of the proposed capability, 

and an assessment of the associated risks and requirements. This process is 

known as Early Human Factors Analysis (EHFA). The issues drive detailed HFI 

planning for subsequent phases. The HFI objective is to ensure that the HF 

issues are adequately reflected in the Initial Gate submission. 

• Assessment 

In Assessment, more detailed work explores and quantifies the HFI issues and 

risks, gathering information about user tasks, working conditions and expected 

performance. Major issues, such as manpower reduction, workload, 

performance shortfalls or safety are assessed for different options. Suppliers 

develop HFI aspects of their potential solutions, supported by demonstrations 

and other evidence. MoD’s HFI objective is to ensure that Suppliers clearly focus 

on the human-related issues, and that HFI results are fairly represented in the 

Main Gate submission. 

• Demonstration 

After Main Gate, specifications are refined to ensure robust HFI content, with 

clear human performance targets. HFI concerns must be included in the downselection 

criteria for equipment characteristics, associated services, overall 

integration and the process offered to develop and deliver the solution and 

reduce risks. The IPT provides access to user expertise to support the Supplier’s 

HFI team. 



• Manufacture 

The Supplier HFI team will lead on most aspects of equipment HFI, with MoD 

ensuring integration with training development, tactics development, support 

strategy, etc. The MoD tracks Supplier-provided evidence, with increasing input 

from representative end-user trials, in order to build confidence in equipment 

operability, leading to acceptance and subsequent hand-over to DLO. 

• In-Service 

Declaration of In-Service Date (ISD) follows demonstration of effective integration 

of the equipment with the human component (personnel, procedures, support 

and training regimes) under operational conditions. While in service, HFI 

evaluation helps to identify any human-related performance shortfalls or failures 

of human-equipment integration. Where capability increments are proposed the 

HFI process repeats in microcosm of the earlier phases. 

• Disposal 

The aim is to dispose of the equipment efficiently, effectively and safely. HFI 

involves assessment of health and safety issues of the disposal process. 

The rest of this section provides the details of the high-level HFI objectives that 

are supported by the HFI mechanisms and activities described in this Guide (and, 

to some extent, within MAP-01-011). These high-level objectives are the 

responsibility of the HFI Focus but the activities required to achieve them may be 

delegated to other HF Specialists within the IPT as required by the project. For 

example, the identification of requirements and the assessment of risk may be 

managed by the HFI Focus but may be generated by the HF Specialist. 

2.6.1 Concept Phase 

2.6.1.1 Objectives 

Project 

Objectives 

HFI Objectives HFI Activities Value Added 

1. Produce 

User 

Requirements 

Document 

(URD) 

2. Form the IPT 

3. Begin 

dialogue with 

industry 

1. Contribute to relevant 

sections of URD based 

on human-related 

issues 

2. Nominate HFI Focus 

in IPT 

3. Involve industry HFI 

teams in identification of 

HFI issues 

• Conduct Early 


Analysis 

(EHFA) 

• Develop 

Description of 

users (PSTAD) 

• Develop Highlevel 

task 

description 

• Identify 

personnelrelated 

risks 

which drive 

plans and 

requirements 

• Identify User 

data needed 

for URD 

• Develop 

baseline for 

work in 

Assessment 



Project 

Objectives 


4. Identify 

technology and 

procurement 

options for 

further 

investigation 

5. Plan and 

obtain funding 

for Assessment 

phase (with 

time, cost and 

performance 

boundaries) 

6. State outline 

cost and 

performance 

boundaries for 

whole project 

4. Identify human 

implications of 

technology and 

procurement options 

5. Plan Assessment 

work to quantify and 

mitigate HFI risks, and 

to provide HF Data 

6. Identify outline HFI 

activities to be 

conducted throughout 

the project life cycle 

7. Contribute to the IG 

submission, in terms of 

human-related costs 

and effectiveness of 

human integration 

• Specify need 

for detailed HF 

analyses 

• Conduct 

Outline 

manning 

analysis 

• User interface 

prototyping (to 

clarify 

requirements) 

• Specify 

outline 

operability 

targets 

• Ensure 

budget, 

resources and 

contracts are in 

place to 

address risks 

• Contribute to 

cost forecast 

• Develop 

content for 

URD and 

outline SRD 

7. Pass Initial 

Gate (IG) 

8. Undertake or 

commission HFI 

analysis to support the 

above 

Table 2-14: Concept Phase HFI Objectives and Activities 

2.6.1.2 HFI Focus Responsibilities during Concept 

• Contribute to URD 

The URD specifies the required military capability, which in almost all cases will 

be provided by some combination of equipment, manpower, training, doctrine, 

support, etc. The URD plays a pivotal role in the whole acquisition project, since 

it drives all later requirements and plans. It is extremely rare for personnel not to 

form part of a capability. It is therefore important to provide appropriate 

high-level ‘hooks’ in the URD to which more specific HFI requirements in the SRD 

can be traced. The URD is owned by the DEC, and for a simple project might be 

written by one or more members of the CWG. In many cases, however, the final 

document will be prepared with assistance from the IPT. See ‘Practical 

Guidance for IPTs’ [Ref 17] for the typical HFI content of each section of a URD. 

• Nominate HFI Focus in IPT 

The HFI Focus is a mandatory role within the IPT. In a small IPT, this will 

normally be shared with another role. The HFI Focus need not be (and in 

practice, rarely will be) an HF Specialist, but should be committed to properly 

managing the human issues within the project. Since much HFI activity involves 

influencing other stakeholders whose responsibility overlaps with HFI, the HFI 



Focus should be a good ‘influencer’. The IPT Leader has ultimate responsibility 

for HFI, and in some cases might assume the working-level role as well. 

• Involve Industry HFI Teams in Identification of Issues 

During Concept, the IPT will normally brief industry on the emerging requirement 

and seek ideas on relevant technology developments. These briefings should 

include reference to human-related issues, especially where the issues arise 

from weaknesses of human integration in current capability, or from proposed 

changes in the relationship between human and equipment. Ideally, the HFI 

Focus will open two-way dialogues with relevant HFI teams within industry. 

• Identify Human Implications of Options 

Identifying human implications of options is the key HFI activity in Concept 

phase. An understanding of the human-related risks and opportunities should 

drive the whole HFI effort, since the human component is a major source of cost, 

and usually a critical factor in system effectiveness. Early Human Factors 

Analysis (EHFA) is a simple, systematic process for identifying and assessing 

human issues, and then deciding what to do about them. Pointers to humanrelated 

risks can be found in operational experience, changes to the operational 

context, procurement constraints, research programmes and elsewhere. 

• Plan HFI for Assessment Phase 

Wherever significant human-related risk or opportunities are identified, there will 

be a need to quantify and then mitigate HFI risks, and to explore the 

opportunities. This work, whether analysis, experiment, prototyping or trials must 

be planned to ensure it provides timely results to influence project decisions. 

Clearly, planning is a project-wide activity. See also Chapter 4 on the Human 

Factors Integration Plan (HFIP). 

• Identify Outline Life Cycle HFI Activities 

The two major, long-range project plans that begin in Concept phase are the 

TLMP and the ITEAP. Both require inclusion of activities related to HFI. The 

TLMP will show how HFI activities, methods and data integrate with other 

activities. The ITEAP will show how HFI requirements are quantified in testable 

terms, how the performance targets are evolved and how the integration between 

equipment and human components will be progressively evaluated, tested and 

ultimately accepted. 

• Contribute to the IG Submission 

The high-level business case submitted at Initial Gate (IG) would not normally 

mention HFI explicitly, but the strength of the case will rest on the underlying 

project results, including HFI. Where the human component plays a major part in 

the proposed capability, or where there are critical human-related shortcomings 

to overcome, being able to demonstrate that the key human-related issues have 

been considered and properly accounted for will be an important part of this 

support. 



• Undertake or Commission HFI Analysis 

The sections above describe how HFI supports the main project objectives for 

Concept phase. In order to do this, supporting analysis will need to be 

undertaken. The type of analysis carried out at this phase will depend on the 

project’s specific needs and on the human-related issues identified. MAP-01-011 

describes a range of supporting HFI analysis techniques with an introductory 

table to show when, and under what conditions, each would normally be used. 

Typical activities at this phase might include exploring human aspects of 

missions and scenarios, comparison with other systems, outline description of 

key tasks and preliminary information about likely hands-on user groups. For any 

acquisition there would be HFI Input to the Concept of Analysis. 

2.6.2 Assessment Phase 


Project 

Objectives 


1. Produce 

Systems 

Requirement 

Document 

(SRD) to meet 

URD needs. 

Establish and 

maintain links 

between 

System and 

User 

requirements. 

2. Establish full 

IPT. 

3. Identify most 

cost-effective 

technological 

and 

procurement 

solution. 

4. Develop the 

SRD, trading 

time, cost and 

performance to 

identify a 

solution within 

Initial Gate 

boundaries. 

1. Identify key humanrelated 

system 

requirements for SRD 

(including interfaces, 

operability, human 

performance, training, 

safety, etc). Trace to 

statements in URD. 

Develop HF subsystem 

requirements, 

particularly with respect 

to feeding into the 

development of 

prototype designs. 

2. Fully resource role of 

HFI Focus. 

3. Identify human 

impact on cost and 

performance for 

different options. 

4. Explore and quantify 

human-related tradeoffs 

as part of option 

assessment process. 

• Conduct 

detailed HF 

analysis 

• Quantify 

human 

performance 

and cost of 

options 

• Review and 

update list of 

human issues 

• Conduct User 

interface 

modelling 

• Develop HFI 

aspects of 

solutions 

(Suppliers and 

MoD) 

• Specify 

detailed 

operability 

targets 

• Plan HFI work 

for 

Demonstration 

• Analysis etc 

quantifies HFI 

risk 

• Research, 

evaluations, etc 

contribute to 

trade-off 

• Drive project 

risk register 

• Help clarify 

requirements 

for SRD 

• Ensure 

Supplier 

solutions 

address human 

issues 

• Contribute to 

evaluation 

criteria for down 

selection in 

Demonstration 



Project 

Objectives 

5. Reduce risk 

to permit 

delivery of 

acceptable 

performance 

within tight time 

and cost 

bounds. 

6. Refine TLMP 

and agree 

funding and 

plan for 

subsequent 

phases. 

7. Pass Main 

Gate (MG) with 

approved time, 

cost and 

performance 

boundaries. 


5. Undertake analysis 

and evaluation to 

quantify and mitigate 

human-related risks to 

overall performance 

and cost. 

6. Ensure adequate 

provision for HFI 

analysis and evaluation 

in support of other 

activities during future 

phases. 

7. Contribute to the MG 

submission, in terms of 

human-related costs 


human integration. 



analysis or evaluation 

to support the above. 

9. Continue HFI 

dialogue with industry. 

Table 2-15: Assessment Phase HFI Objectives and Activities 

2.6.2.2 HFI Focus Responsibilities during Assessment 

• Identify Requirements for SRD 

The SRD specifies what a system must do to provide the military capability 

required by the URD. It does not specify a particular solution, but where there 

are important constraints, the SRD must identify component boundaries and 

performance budgets for components (e.g., the need to inter-work with an 

existing system or specific manning constraints). The SRD specifies the whole 

system, including the human components, structured so that industry can 

contract for a solution to meet a well-defined subset of its requirements. A 

baseline allocation of function for each technology option will help define these 

boundaries. Key human-related requirements must be included to ensure that 

equipment and human components properly integrate. System requirements 

must trace back to the URD. This might reveal areas where the URD needs 

clarification. ‘Practical Guidance for IPTs’ [Ref 17] indicates the typical HFI 

content of an SRD. 



• Fully Resource the Role of HFI Focus 

The role of HFI focus includes a large degree of co-ordination. Even if the role 

remains a shared one, the responsibilities with which it is shared must leave 

sufficient time to do the job effectively. The HFIP for Assessment should indicate 

the size of the task and care should be taken that this co-ordination task is not 

underestimated. 

• Identify Human Impact on Cost and Performance 

The decision at Main Gate is dependent on being able to make good estimates of 

overall cost and effectiveness of each technology option. Human-related costs 

typically dominate Whole Life Costs, and detrimental human performance caused 

by poor Human Factors Integration can undermine the effectiveness of 

apparently good equipment. The human dimension of the Combined Operational 

Effectiveness and Investment Appraisal (COEIA) is therefore critical, more so 

when the options differ significantly in nature. See ‘Practical Guidance for IPTs’ 

[Ref 17] for guidance on how to assess human performance impact and humanrelated 

costs in support of the COEIA process. 

• Explore and Quantify Human-Related Trade-Offs 

The equipment component of the solution cannot be optimised in isolation. 

Equipment trade-offs that change the performance or function at the interface 

with the human component (operators, maintainers or support staff) must be 

assessed to determine how they affect the human performance. Likewise, 

opportunities to improve human performance, to reduce training or manning, etc 

by changes to equipment must also be explored. 

• Quantify and Mitigate Human-Related Risks 

Risks identified in Concept should be reviewed, and any new risks assessed. 

Quantifying human-related risks requires detailed analysis, which will vary with 

the nature of the risk. 

• Ensure Adequate Provision for Later HFI Analysis and Evaluation 

Depending on the human-related issues and risks identified, significant effort 

might be required in future phases for modelling, prototyping, evaluation or trials. 

This must be made clear in the TLMP. Where it is most appropriate for MoD to 

undertake or commission the work this needs to be budgeted for. Where other 

agencies undertake the work, e.g. training analysis, this necessitates a Customer 

Supplier Agreement (CSA). Where Suppliers will be expected to do the work and 

submit the results as evidence, this must be made clear in the Statements of 

Work (SoWs) accompanying Invitations to Tender (ITTs), Invitations to Submit 

Outline Proposals (ISOPs) and Invitations to Negotiate (ITNs). Where service 

personnel are needed for trials or evaluation, this must be agreed with the 

appropriate organisation, bearing in mind operational requirements. 

• Contribute to Main Gate Submission 

The high-level business case submitted at Main Gate is a relatively short 

document that summarises the whole project output. Explicit references to HFI 

will be few and short, but the strength of the case, even at high level, will rest on 

an understanding of the issues and assumptions about integration and 

performance of the human component within the system. The business case 



must demonstrate that key human-related issues have been considered and 

properly accounted for. 


The plan prepared during Concept phase will determine major areas of analysis 

to be done, but the scope and priorities should still be driven by the currently 

assessed risks. See MAP-01-011, HFI Technical Areas (Chapters 4 through 17) 

for guidance on different supporting HFI analysis activities. Typical HFI activities 

at this phase might include a high-level task analysis (for operation, maintenance 

and support), human performance modelling (linked to the main OA to determine 

key HFI trade-offs and effectiveness levels) and producing a Project Specific 

Target Audience Description (PSTAD) for the selected option. Related activities 

might include review of manpower and personnel requirements and costs (in 

conjunction with manning and complementing authorities), and Training Needs 

Analysis (in conjunction with training organisations). 

• Continue HFI Dialogue with Industry 

Industry insights should help MoD to understand the human issues associated 

with various options. It is also important that the Human Factors Suppliers are 

aware of the human-related risks MoD needs to address. During Assessment, 

Suppliers may be in competition, and this presents barriers to communication 

that need to be addressed. 

2.6.3 Demonstration Phase 


Project 

Objectives 


1. Eliminate 

development 

risk to fix 

performance 

targets for 

manufacture, 

maintaining 

linkage 

between 

solution and 

SRD, URD. 

2. Place 

contract(s) to 

meet SRD. 

1. Evaluate HFI aspects 

of proposed solutions. 

Predict human-related 

performance where 

necessary, and relate 

this to SRD and URD. 

Continue to develop HF 

sub-system 

requirements. 

2. Ensure contracts 

cover provision of HFI 

evidence in support of 

proposed solutions. 

Ensure industry access 

to HFI information and 

user experience. 

• Further 

analysis, 

evaluation 

trials, and 

design support 

working with 

Supplier 

prototypes, etc. 

• Ensure HFI 

content of 

specifications 

is robust. 

• Define human 

performance 

and operability 

targets. 

• Continued 

exposure of HFI 

issues, and 

involvement of 

users to 

mitigate risk. 

• Focus 

Supplier efforts 

on achieving 

good 

human-system 

integration. 



Project 

Objectives 


3. Demonstrate 

ability to 

produce 

integrated 

capability. 

4. Down select 

to single 

Supplier. 

3. Demonstrate ability to 

deliver operability. 

Co-ordinate human 

aspects of system 

design, training analysis 

and support analysis. 

Conduct progressive 

operability trials. 

4. Contribute HFI criteria 

for solution and Supplier 

assessment. 



analysis or evaluation to 

support the above. 

6. Work closely with 

industry to manage HFI 

risks of the solution. 

• Co-ordinate 

human aspects 

of system 

design, training 

analysis and 

support 

analysis. 

• Resolve HFI 

issues as they 

arise 

throughout 

detailed 

design. 

• Refine HFI 

acceptance 

strategy. 

• Undertake 

progressive 

operability 

trials. 

• Ensure 

training and 

support 

systems are 

matched to 

human needs of 

system. 

• Help keep 

detailed design 

focus centred 

on human 

needs. 

• Provide 

evidence of 

operability, and 

feedback of any 

shortfalls to be 

addressed. 

Table 2-16: Demonstration Phase HFI Objectives and Activities 

2.6.3.2 HFI Focus Responsibilities during Demonstration 

• Evaluate Proposed Solutions 

Risk reduction is one of the key elements of Demonstration. Some of the HFI 

risks at this phase relate to human performance. The use of prototypes and 

demonstrators has proved valuable in evaluating technical solutions. This will not 

cover the whole scope of system operation, and so performance prediction will 

still be needed in critical areas. The SRD and URD should provide the basis of 

which areas to evaluate. Modelling, careful extrapolation from the prototypes, or 

appropriate comparison with operational experience can help. 

• Ensure Contracts Cover Provision of HFI Evidence 

Prior to contract let, competitive pressures will encourage Suppliers to supply any 

evidence they perceive MoD will value. After contract let, the contract will 

dominate what is or is not provided, even with co-operative working. The 

contract must therefore clearly state wherever Suppliers need to provide 

evidence to justify the acceptability of their proposed solutions. HFI evidence is 

often overlooked in favour of issues such as technical (i.e., equipment) 

performance, unless the requirement for it is explicitly specified. Much HFI 

evaluation requires access to representative users, including hands-on users. 

Suppliers should be required to state their needs, to permit planning for adequate 

provision. 



• Demonstrate Ability to Deliver Operability 

Demonstrating the ability to deliver integrated capability includes operability 

evaluation and trials of prototypes and demonstrators (and similarly for 

maintenance and support). It also involves putting in place the mechanisms to 

ensure integration of human aspects of system design across many 

organisational boundaries: equipment development, training analysis, support 

analysis and the evolution of operational thinking. 

• Contribute HFI Assessment Criteria 

Down selection and commitment to a single Supplier is a critical decision. Once 

selected, the Supplier will control many aspects contributing to effective humanequipment 

integration. The Supplier’s ability to deliver a solution that meets HFI 

requirements must be thoroughly covered by the assessment criteria. 


The plan prepared during Assessment phase will identify major areas of analysis 

to be done, but the scope and priorities should still be driven by the currently 

assessed risks and, prior to selection, on the need to differentiate between the 

competing solutions. MAP-01-011 gives guidance on different supporting HFI 

analysis activities. Typical activities at this phase might include detailed 

performance modelling (supported by more detailed task analysis), 

anthropometric assessment and cross-domain analyses, e.g. the interaction of 

design and training. 

• Manage HFI Risks with Industry 

Management of risks in the solution is a shared responsibility, especially 

following down-selection when the Supplier becomes a full member of the IPT. 

While the Supplier (through acceptance criteria) will carry the risk for 

equipment-induced aspects of operability, there are still risks in the wider aspects 

of how people, operational procedures and equipment perform together, 

especially where the capability is to be met by a people-intensive system. 

Guidance on HFI risk assessment is given in Chapter 3 of this guide. 

2.6.4 Manufacture Phase 


Project 

Objectives 


1. Deliver 

solution within 

time and cost 

limits 

appropriate to 

this phase. 

2. Complete 

development 

and production. 

1. Co-ordinate 

development of humanrelated 

components of 

capability, i.e. 

manpower, training, 

support. 

2. Support Supplier 

with input to continued 

HFI evaluation. 

• Support 

Supplier with 

input to 

continued HFI 

evaluation. 

• Continue to 

resolve HFI 

issues as they 

arise. 

• Helps Supplier 

to maintain 

user-centred 

focus. 

• Ensures 

trade-offs take 

account of 

human-related 

issues. 



Project 

Objectives 


3. Accept the 

system in 

accordance 

with the SRD. 

4. Transfer 

management to 

Defence 

Logistics 

Organisation 

(DLO). 

5. Transfer 

customer 

function to 

Customer 2. 

3. Accept operability by 

monitoring operability 

acceptance trials and 

assessing the evidence 

produced. 

4. Transfer HFI 

information produced in 

procurement for use in 

the support phase. 

5. Support HFI 

evaluation of field trials, 

feeding back lessons 

learned. 

• Monitor 

operability 

trials and 

assess 

evidence 

produced. 

• Support HFI 

evaluation of 

operational 

work-up trials, 

feeding back 

lessons 

learned. 

• Transfer HFI 

information 

generated 

during the 

procurement 

phase for use 

in the support 

phase. 

• Demonstrates 

achievement of 

operability 

targets. 

• Identifies any 

operability 

shortfalls for 

remedial action. 

• Ensures HF 

Data and 

insights do not 

‘get lost’. 

Table 2-17: Manufacture Phase HFI Objectives and Activities 

2.6.4.2 HFI Focus Responsibilities during Manufacture 

• Co-ordinate Development of Human Component 

New or upgraded capability normally involves significant change or development 

to the human component: for example, operational procedures, manpower, 

training, support, and so on, in parallel with equipment production. These 

developments will require information about the equipment (and about each 

other) to ensure time and cost limits are met. They might also generate issues 

that need to be addressed by changes to the equipment. Some of this coordination 

will occur between the groups involved, but the IPT as overall coordinator 

will need to be involved, especially in equipment related links. 

• Support Supplier HFI Evaluation 

Smart acceptance is based on helping the Supplier to ‘get it right’, as much as on 

testing to see whether this has actually been achieved. While completing the 

development, the Supplier will continue to meet technical issues that must be 

resolved. Some HFI issues will not be readily resolvable internally, and will 

require MoD support by way of information, decision or compromise. If this 

support is not readily forthcoming, the Supplier will be faced with either 

compromising the project timescale or circumventing the issue, and thus possibly 

building HFI risk into the solution. 



• Accept Operability 

Acceptance of operability (and also maintainability and supportability) is 

potentially complex, because of the need to account separately for those aspects 

that are properly the responsibility of the equipment Supplier, and those that 

accrue from the wider interaction of human and equipment components within 

the overall system. These aspects should be stated separately in the SRD, but it 

can be difficult to draw the boundary between them during testing, especially for 

people-intensive or information-intensive systems. Acceptance of equipment 

operability should conform to the overall project acceptance strategy: normally 

the Supplier presents evidence based on conducting agreed tests (which MoD 

may witness if desired). Detailed schedules and procedures for carrying out the 

tests must also be agreed. The Supplier will require support in the form of 

suitably experienced service personnel to take part in the tests. 

• Transfer HFI to Support Phase 

During the transfer of the project from DPA to DLO, relevant issues are likely to 

include some re-distribution and re-sizing of IPT roles, which could affect the role 

of HFI Focus, and the need to ensure that HF Data gathered during the 

procurement phase can be transferred and maintained through life, ready to 

support the acquisition of future capability increments. 

• Feed Back Lessons Learned 

The formal transfer to Customer 2 will be accompanied by extensive trials and 

work-up with Customer 2’s personnel. This will be a more severe test of the 

human-equipment integration and performance than that which preceded it. It is 

important to capture the valuable HFI lessons learnt during this phase. 

2.6.5 In-Service Phase 


Project 

Objectives 


1. Confirm the 

required 

capability is 

available for 

operational use. 

2. Support the 

frontline. 

3. Maintain 

performance 

within agreed 

levels, while 

driving down 

annual cost of 

ownership. 

1. Initiate in-service 

HFI audit. Identify 

issues requiring action. 

2. Monitor exercise and 

operational reports for 

evidence of HFI issues. 

Act if needed. 

3. Monitor efficiency 


maintenance, support, 

operation, etc. 

• Develop In- 

Service HF 

Issues Log 

• Maintain and 

initiate 

mitigating 

actions to 

resolve HF 

issues 

• Picks up ‘real 

use’ issues not 

detected in lab 

and factory 

tests. 

• Picks up HFI 

issues 

emerging from 

changes in 

operational 

practice, 

personnel, 

training, 

equipment 

ageing, etc. 



Project 

Objectives 


4. Carry out 

agreed 

upgrades or 

improvements, 

refits or 

acquisition 

increments. 

4. Re-run procedures 

used during main 

procurement, at a 

reduced scale, and 

drawing on stored HF 

Data. 

• Ensure 

Health and 

Safety 

requirements 

are defined, 

understood 

and met 

• Evaluate 

training 

effectiveness 

• Brings all 

benefits of HFI 

to the 

capability 

increment, as 

well as the 

initial 

capability. 

Table 2-18: In-Service Phase HFI Objectives and Activities 

2.6.5.2 HFI Focus Responsibilities during In-service 

• In-Service HFI Audit 

When the system is bedded down in service, an audit should be conducted to 

determine the level of integration of human and equipment, and to identify any 

HFI issues requiring action. Some issues slip through trials and ‘work-ups’ 

unnoticed, but these may become more significant during sustained routine 

operation. Others could not have been detected earlier but only become evident 

during their full operational use. 

• Support Operation 

From time to time throughout the system’s life, front-line personnel will detect HFI 

weaknesses in the system, often because some facet of operational practice has 

changed. Equipment fault reporting mechanisms often cannot handle these 

problems, because they are not clear-cut equipment failures. The IPT should put 

in place a means to detect and respond to usage problems that cannot be 

resolved locally by the operational personnel, e.g. by periodically checking 

exercise and operational reports for evidence of HFI issues. 

• Monitor Cost Effectiveness 

Once equipment has been procured, manpower, training and support dominate 

the ongoing system costs. Service experience might lead to more efficient ways 

of operating, maintaining or supporting the system. Cost reduction is not the 

primary goal of front-line forces, so the IPT should put in place means to detect 

such opportunities, possibly using the same links and reporting mechanisms as 

above. 

• Re-Run Procedures for Upgrades 

Whenever a significant modification or upgrade is required, the acquisition 

procedures described for earlier phases will be re-enacted on a scale appropriate 

to the magnitude of the undertaking. 



2.6.6 Disposal Phase 


Project 

Objectives 


1. Dispose of 

the equipment 

efficiently, 

effectively and 

safely. 

1. Assess HF issues of 

proposed disposal 

process. Take action as 

required. 

• As for HFI 

Objectives 

• Ensures 

human aspects 

of disposal are 

cost-effective 

and safe. 

Table 2-19: Disposal Phase HFI Objectives and Activities 

2.6.6.2 HFI Focus Responsibilities during Disposal 

• HF Issues in Disposal 

Many disposal activities are routine, and are adequately managed by disposal 

Suppliers. In other cases, disposal can entail significant hazards to the disposal 

personnel or to other people. The hazards must be assessed, and quantified. 

Any appropriate mitigating actions must be put in place. Other agencies might 

undertake this process, but the IPT will be responsible for ensuring it is properly 

executed. 

2.7 Project Role Terms of Reference 

2.7.1 IPT Leader and Systems Project Managers 

The IPT Leader is responsible for ensuring that MoD HFI Policy is applied within 

the platform or equipment programme. Specific terms of reference are as 

follows: 

1. Development of the strategy for the project. 

2. Allocation of funding and resources to fully address issues, priorities and 

risks. 

3. Organisation of roles and responsibilities. 

4. Identification of staff training needs to conduct HFI. 

5. Development of a coherent HFI Programme across all phases of 

procurement. 

6. Co-ordination of the platform or equipment HFI Programme with other 

related HFI Programmes (see Chapter 3). 

For specific systems, the IPT Leader will be assisted in carrying out the above 

terms of reference by the Systems Project Managers. 



2.7.2 HFI Focus Terms of Reference 

The HFI Focus is responsible for actively co-ordinating human issues throughout 

the project and for ensuring that these issues are brought to bear on every 

aspect of the design. In practice this will involve extensive liaison within and 

outside the project as well as ensuring that the Supplier’s Human Factors 

Integration Plan (HFIP) is properly conducted. Specific terms of reference are as 

follows: 

1. To manage integration of all Human Factors issues in the system for which 

the project is responsible. 

2. Implementation of the HFI strategy in the project, as defined in the HFIP. 

3. To ensure all project staff are aware of the project’s Human Factors issues, 

and how they will be integrated into the project. 

4. Co-ordination of the HFI Programme with other disciplines. 

5. Establishment of liaison and steering groups and the conduct of liaison with 

other programmes, HF Specialists and MoD Authorities. 

6. Managing the involvement of RN, RM, Army and RAF user representatives 

for the purposes of requirements analysis, design assessments and 

acceptance tests. 

7. Development of any outline MoD HFIP and its incorporation into the Project 

Management Plan (PMP). 

8. Production of HFI elements of Invitations to Tender (ITT) and the 

assessment of the Suppliers’ proposals for the HFIP. 

9. Monitoring of activities and outputs against milestones in the Supplier’s 

HFIP. 

10. Monitoring the development of data to enable HFI and evaluating the 

implications for the resolution of issues, priorities and risks. 

11. Technical quality control of all activities and outputs until acceptance of the 

platform or equipment. 

12. Maintenance of HFI risks and risk mitigation elements in the project risk 

management register. 

13. Monitoring the results of assessment and acceptance tests and 

communication of implications within the IPT. 

14. To obtain training in HFI if no previous experience (see Chapter 1 for HFI 

liaison and contacts). 

2.7.3 Supplier Terms of Reference 

The Supplier is the organisation contracted to develop the platform or equipment. 

This role is responsible for conducting the technical project within one or more 

phases of the procurement. 



Proposed outline terms of reference are as follows: 

1. Preparation of the Supplier’s Human Factors Integration Plan (HFIP). 

2. Specification of proposed involvement of user representatives. 

3. Liaison with MoD IPT and with other MoD Authorities as directed by the 

HFI Focus. 

4. Conduct of HFI activities and development and delivery of HFI outputs. 

5. Maintenance of the format, media and content of HF Data accumulated 

during the project, and production of the Human Factors Integration Log 

(HFIL). 

6. Conduct of assessments of the platform or equipment. 

7. Development of the HFI content of the Acceptance Questionnaire. 

2.7.4 HF Specialist Terms of Reference 

In addition to those responsibilities allocated as a result of any role in support of 

the HFI Focus or the Supplier, the HF Specialist’s terms of reference will depend 

upon the specific responsibilities that are allocated as a result of applying the 

Technical Guidance in MAP-10-011 within the context of the HFIP and their role 

within a multidisciplinary group. 

2.8 Multidisciplinary Groups HFI Focus Checklist 

The development of a system delivering effective operational capability with 

minimal support costs requires the effective application of a multidisciplinary 

approach. The unique contribution of HFI is to concentrate on the human 

performance and support requirements and HF characteristics to be delivered. 

HFI works with other disciplines in a number of general ways as follows: 

• HFI provides basic data on human limitations and capacities that drive 

design decisions in other disciplines, e.g. data on basic visual acuity is 

used to determine display characteristics. 

• HFI provides techniques, methods and models that enable assessment of 

the feasibility and value of design options proposed by other disciplines, 

e.g. human workload analysis is used to assess the feasibility of alternative 

human-computer interface designs. 

• HFI provides unique contributions to the overall design concept, e.g. 

techniques for modelling complement size and the future organisation of 

the crew. 

The Human Factors Integration Plan (HFIP) must identify the dependencies and 

interfaces between HFI activities with other disciplines in the context of the 

overall Project Management Plan (PMP). It is important to realise that closer 

integration with other disciplines can also lead to greater efficiency and real cost 

savings to the overall project. Poor integration leads to risks of sub-optimal 

human performance due to inferior product design (limiting operational 



capability), higher support costs, greater health and safety risks and waste of 

development resources and costs. 

The sections below provide guidance about how HFI works with other disciplines 

during platform and equipment development. The advice contained within these 

sections is primarily aimed at the HFI Focus for the project or programme. 

2.8.1 HFI and Operational Analysis 

Operational Analysis provides techniques, mathematical models and simulations 

that can be applied to a wide range of issues. These include Force and battle 

simulation, establishing performance parameters for the use of technology, e.g. 

in sensors and weapons, estimating through-life costs and indeed supporting the 

understanding of HFI issues. These techniques are of most direct value to the 

overall procurement during the early phases particularly when used in the 

Combined Operational Effectiveness and Investment Appraisal (COEIA). 

2.8.1.1 Operational Analysis HFI Focus Checklist 

• Identify types of human performance that can limit the operational 

effectiveness of the platform or equipment (see MAP-01-011: Chapter 6 

(Crew Characteristics), & Chapter 15 (Operability and User-Equipment 

Interaction)). 

• Estimate critical human performance parameters through the use of 

historical data, specific modelling of operator performance or empirical data 

from demonstrators and prototypes. 

• Determine the effect of human performance capabilities and limitations on 

the operational effectiveness of different options. 

• Estimate the manning required for each option and the likely profile of roles 

and skills (see MAP-01-011: Chapter 4 (Manpower, Complementing and 

Accommodation) & Chapter 5 (Team Organisation)). 

• Establish the support costs for each option in terms of direct costs, training, 

accommodation, communications, overheads etc. (see: MAP-01-011: 

Chapter 7 (Training), & Chapter 8 (General Arrangement)). 

• Establish the feasibility of supporting a particular organisational profile 

given the likely Target Audience Description and future manning policy. 

• Establish the survivability of human personnel in each design option (see 

MAP-01-011: Chapter 17 (Safety)). 

• Identify trade-offs between different options and establish effects on 

development and through-life costs, e.g. reductions in automation may 

require higher investment in training and/or the selection and maintenance 

of more skilled personnel. 

2.8.2 HFI and Ship Design 

The platform design process defines the overall hull size and shape, motion 

characteristics and the configuration of upper and lower deck areas. 



2.8.2.1 Ship Design HFI Focus Checklist 

• Identify the dependencies that exist between ship design and HFI and 

reflect these in the ship design and HFI parts of the Project Management 

Plan (PMP). 

• Identify the effects of motion characteristics of hull form on human 

performance and comfort (see MAP-01-011: Chapter 13 (Habitability and 

Internal Environment)). 

• Design the general arrangement of compartments and deck areas to meet 

operational task demands for the optimal positioning, survivability, comfort 

and movement of personnel (see MAP-01-011: Chapter 8 (General 

Arrangement), Chapter 9 (Operational Spaces), Chapter 11 (Miscellaneous 

Spaces) and Chapter 12 (Personnel Movement and Material Handling)). 

• Design accommodation and define habitability requirements to meet the 

needs of the estimated size and composition of the complement (see MAP- 

01-011: Chapter 10 (Accommodation Spaces) and Chapter 13 (Habitability 

and Internal Environment)). 

• Design passageways, positioning of hatches and doors, and deckhead 

clearances to match the anthropometric (i.e. range of body size) 

characteristics of the crew and for the efficient and safe execution of 

movements and material handling (see MAP-01-011: Chapter 12 

(Personnel Movement and Material Handling)). 

• Design environment and control of noise, vibration, heating, ventilation, airconditioning, 

lighting, atmospheric conditions, radiation and waste disposal 

to avoid degradations to human performance and to maintain comfort, 

health and safety (see MAP-01-011: Chapter 13 (Habitability and Internal 

Environment) and Chapter 17 (Safety)). 

2.8.3 HFI and Systems Engineering 

Systems engineering is applied to the development of Combat System and 

Marine Engineering equipment. The systems engineering design process 

consists of a number of stages, which may be performed sequentially or 

iteratively (e.g. rapid application development). These stages include 

requirements analysis, the identification of logical functions and data 

requirements, and the selection of the software and/or hardware architecture, 

detailed system and subsystem design, integration, testing and installation. 

MAP-01-011 Annex 2 references standards that apply to the construction of a 

range of marine engineering equipment. 

2.8.3.1 Systems Engineering HFI Focus Checklist 

• Identify the dependencies that exist between systems engineering and HFI 

and reflect these in the relevant parts of the Project Management Plan 

(PMP), see MAP-01-011: Chapter 14 (Equipment Layout) and Chapter 15 

(Operability and User-Equipment Interaction). 

• Ensure that the results of Human Factors Engineering studies are used in 

the requirements analysis. 



2.8.4 HFI and ILS 

• Identify the implications of the logical and physical design for future 

operator task demands and roles. 

• Select a Human Factors Style Guide and ensure that this is applied during 

the design. 

• Obtain user assessments of the user-equipment interface design for all 

mission critical functions prior to full construction. 

• Ensure that the design of the user-equipment interface is presented to user 

representatives in the form of project documentation and prototypes from 

the earliest stage of design. 

• Maximise the consistency of the full range of user-equipment interface 

styles presented to each user role and compensate for any inconsistencies 

with unacceptable risks to operational performance or safety. 

• Ensure that the design of on-board user support facilities (including on-line 

help and user manuals) support operator performance of tasks and 

procedures. 

Integrated Logistics Support (ILS) is the accepted discipline for managing the 

support life cycle cost, for causing support considerations to influence the design 

or selection of equipment and for delivering and monitoring a consistent support 

environment for the fielded equipment, see the ‘Support Solutions Envelope 

(SSE)’ [Ref 30] area of the AMS. 

ILS is implemented as a process, as is HFI, to run concurrently with equipment 

design. The Logistic Support Analysis (LSA) consists of specified tasks and subtasks 

that are adapted for use, and performed iteratively, during an equipment 

programme in order to identify trade-offs with the aim of optimising the cost of 

ownership of the equipment. The LSA also identifies the support operations and 

resources required for the selected design. The results of the LSA are recorded 

in the Logistics Support Analysis Record (LSAR), which is maintained throughout 

the life of the equipment. The ILS Plan (ILSP) defines the specific activities and 

deliverables to be produced within a programme. 

The ILSP for naval projects includes a HFI element plan, which addresses the 

ILS aspects of Human Factors in the Detailed Design and Build stage of 

procurement. 

HFI and ILS are separate but complementary processes that make use of 

common HF Data. The Logistics Support Analysis (LSA) also provides 

information for use in HFI. The areas of commonality between the data 

requirements for ILS and HFI must be exploited in a programme to improve 

product design, to reduce the cost of ownership of the system and to control the 

procurement costs involved in the conduct of HFI and ILS activities. In order to 

achieve this the data formats produced by either discipline must be compatible 

with that required by the other. 

Common data and, to some extent, common techniques are used in ILS and HFI 

to estimate manpower requirements, to identify skill and other personnel 

characteristics, to identify training requirements and training support, to identify 

and allocate functions between personnel and equipment and to deal with health 



and safety. However, HFI is also concerned with wider manpower issues raised 

by fielding a new system as well as the operational effectiveness and efficiency 

of the system. HFI also provides data and techniques for use in optimising the 

design of equipment whilst ILS focuses on its support implications. 

The steps that need to be undertaken to ensure that HFI is co-ordinated with ILS 

are as follows. These have been ordered by the sequence of tasks comprising 

the LSA (LSA Task numbers are shown where these are applicable). 

2.8.4.1 ILS HFI Focus Checklist 

• Identify common data requirements for HFI and LSA processes and ensure 

that these are supported without unnecessary duplication in the LSA and 

HFI strategies for the programme (LSA Task 101). 

• Identify the dependencies, which exist between ILS and HFI and reflect 

these in the ILS and HFI parts of the Project Management Plan (PMP) 

(LSA Task 102). 

• Ensure that the Use Study incorporates the results of the Early Human 

Factors Analysis of issues and risks including estimates of complement 

size and the Target Audience Description (LSA Task 201). 

• Ensure that the results of HFI studies of health hazard and system safety 

are incorporated into the mission and support systems definitions (LSA 

Task 203) (see MAP-01-011: Chapter 17 (Safety). 

• Co-ordinate the development of functional allocations and task inventories 

for use in LSA and HFI (LSA Task 301) (see MAP-01-011: Chapter 16 

(Maintenance and Support). 

• Identify and apply HFI information of use in specifying the system support 

concept including manning implications, required and available skills 

profile, ease of performing maintenance activities, ease of material 

handling, human safety implications and health hazards (LSA Task 303). 

• In conjunction with the ILS Manager co-ordinate the collection and use of 

the HFI elements of the operator and maintainer task analysis information 

(LSA Task 401). 

• In conjunction with the ILS Manager co-ordinate the conduct of the HFI 

elements of the Training Needs Analysis (TNA) and training options (LSA 

Task 401) (see: MAP-01-011: Chapter 7 (Training). 

• In conjunction with the ILS Manager co-ordinate the development of the 

HFI elements of the user and technical documentation (LSA Task 401). 

• In conjunction with the ILS Manager co-ordinate the development of the 

HFI elements of the operating and maintenance procedures (LSA Task 

401). 

• Apply HFI techniques during the evaluation of maintenance operations on 

prototypes, the equipment and in early fielding analysis to assess usability 

of equipment and ergonomic constraints, e.g. on maintainer access, skill 

requirements, health and safety implications (LSA Tasks 402 and 501) 



(see MAP-01-011: Chapter 15 (Operability and User-Equipment 

Interaction)). 

2.8.5 HFI and Health & Safety 

JSP 430 [Ref 6] describes the mandated approach to safety policy and 

standards. Many areas of system safety and health hazard are covered by 

existing Naval Engineering Standards (see MAP-01-011, Annex 2) and other 

sources. The HFI Programme contributes techniques and data for the 

identification, assessment and mitigation of health and safety hazards. 

2.8.5.1 Health & Safety HFI Focus Checklist 

• Identify the dependencies that exist between safety and Health Hazard 

Assessment programmes and the HFI Programme and reflect these in the 

Project Management Plan (PMP). 

• Perform HAZOPS and human reliability analysis where safety and health 

hazards risks arise within the context of crew activities to determine the 

probability of these risks (see MAP-01-011: Chapter 17 (Safety)). 

• Assess the impact of health hazard and safety risks on the crew. 

• Identify health hazard and safety risk mitigation options. 

• Apply Human Factors Engineering techniques in the design of health 

hazard and safety procedures, features and equipment (see MAP-01-011: 

Chapter 8 (General Arrangement)), Chapter 12 (Personnel Movement and 

Material Handling), Chapter 13 (Habitability and Internal Environment), 

Chapter 14 (Equipment Layout) and Chapter 15 (Operability and User- 

Equipment Interaction). 

• Ensure that training options include material addressing health hazard and 

safety awareness and crew safety procedures (see: MAP-01-011: Chapter 

7 (Training). 

2.8.6 HFI and Training 

The Defence Systems Approach to Training is described in DSAT QS [Ref 8] and 

its supporting Training Support Manuals [Ref 9] through [Ref 14]. The purpose of 

DSAT QS is to provide policy guidance and quality standards for implementation 

of the Defence Systems Approach to Training (DSAT). The DSAT quality 

system, for which the DSAT QS provides the Quality Standard (QS), is 

documented on several levels. Guidance on training administrative procedures 

surrounding the DSAT is provided within the relevant HLB Holder’s Administrative 

Procedures. Training Support Manuals (DTSM1 through DTSM6) provide 

specific details on the application of the elements of the DSAT Quality Standard. 

The remaining documentation, i.e. a quality manual, operating procedures and 

training documentation will be generated under guidance of the QS by individual 

Training Organisations, see Annex 2 viz. Intelligent Customer Group (ICG, 

formerly RNSETT). 

MOD policy requires that an analysis of the training requirement is conducted 

when new equipment(s) are acquired. DTSM3 ‘Training Needs Analysis’ [Ref 11] 

provides the tri-Service guidance on the conduct of a TNA but see also JSP 502 

‘Tri-Service Guide to TNA’ [Ref 20]. The acquisition strategy must ensure that 



training requirements are articulated in the TLMP and appropriate funding lines 

put in place. The HFI and ILS programmes play a major role in identifying 

training needs and training options during acquisition; one early decision that 

needs to be made on larger projects is whether training should fall under the 

umbrella of ILS or HFI. 

2.8.6.1 Training HFI Focus Checklist 

• Identify the dependencies that exist between training and the HFI 

Programme and reflect these in the Project Management Plan (PMP). 

• Identify new equipments and/or crew and other roles, including new roles, 

requiring an analysis of the training requirement. 

• Identify the new Operational Performance requirement. 

• Determine the change to knowledge, skills and attitudes required on 

introduction of the new equipment(s)/changed roles based on the likely 

Target Audience Description. Decide whether there is a training 

requirement. 

• Estimate training throughput 

• Carry out an analysis to determine the balance between cost-effectiveness 

and training effectiveness of a range of media solutions. 

• Agree the most cost/training-`effective solution. 

• Agree an acquisition strategy for the proposed solution. 

Develop an Implementation strategy for the agreed solution, including 

documentation requirements and funding arrangements. 






CHAPTER 3 – MANAGING THE HFI PROCESS 

CONTENTS 

3.1 Introduction ..................................................................................................................3-3 

3.1.1 Co-ordination ........................................................................................3-3 

3.1.2 What is Involved....................................................................................3-4 

3.1.3 CWG and IPT Roles within HFI ............................................................3-5 

3.1.4 HFI Steering Groups and Working Groups ...........................................3-5 

3.1.4.1 Organisation .......................................................................3-5 

3.1.4.2 The Requirement for HF Steering Groups and Working 

Groups................................................................................3-5 

3.1.4.3 Who is Involved ................................................................3-6 

3.1.4.4 Specialist HF Capability .....................................................3-8 

3.1.4.5 Other HF Stakeholders.......................................................3-8 

3.2 HFI Management of Requirements, Issues and Project Control ......................3-10 

3.2.1 Identifying and Managing Requirements ............................................3-10 

3.2.1.1 The Requirements Management Process........................3-10 

3.2.1.2 HFI content of the URD and SRD ....................................3-11 

3.2.1.3 Acceptance Criteria ..........................................................3-11 

3.2.1.4 HFI in Requirements Change Management.....................3-11 

3.2.2 Identifying and Managing HFI Issues and Risk...................................3-12 

3.2.2.1 Introduction.......................................................................3-12 

3.2.2.2 Early Human Factors Analysis (EHFA) ............................3-12 

3.2.2.3 Establish the baseline for HFI ..........................................3-13 

3.2.2.4 Identify HFI Issues............................................................3-14 

3.2.2.5 Assess Impact of HFI Risks .............................................3-16 

3.2.3 Risks and the Project Risk Register....................................................3-16 

3.2.4 Content of the Human Factors Integration Log (HFIL)........................3-18 

3.2.5 Assess the Impact of HFI Related Issues and Risks ..........................3-18 

3.2.6 Managing Issues Through-Life ...........................................................3-18 

3.2.7 Importance of Whole Ship HFI Issues and Co-ordination...................3-19 

3.2.7.1 Whole Ship HFI Co-ordination Process............................3-20 

3.2.7.2 Responsibilities for Whole Ship HFI Issues and Coordination..........................................................................3-21 

3.2.8 Managing and Monitoring the Project .................................................3-22 

3.2.8.1 Scope ...............................................................................3-22 

3.2.8.2 Managing the Project .......................................................3-22 

3.2.8.3 Monitoring HFI Programme ..............................................3-22 

3.2.8.4 Managing Subcontracts....................................................3-23 

3.2.8.5 Assessment of Supplier HFI Activities..............................3-24 

3.3 Managing Acceptance ......................................................................................3-25 

3.3.1 The Acceptance Process....................................................................3-25 

3.3.2 HFI Activities in Acceptance ...............................................................3-26 



3.3.3 Monitoring HFI Assessment & Acceptance Performance ...................3-27 

3.3.3.1 HFI Focus Responsibilities...............................................3-27 

3.3.3.2 Monitoring Acceptance Testing ........................................3-28 

3.3.4 Design of Assessment and Acceptance Testing.................................3-30 

3.3.4.1 Use of Human Factors (HF) Characteristics and Criteria.3-31 

3.3.4.2 Types of HFI Assessment and Acceptance Tests............3-32 


Chapter 3 – Managing the HFI process 

3.1 Introduction 

This Chapter addresses managing the HFI Process. It starts with the issue of 

HFI co-ordination within the project organisation and Working Groups, continues 

with the management of HFI requirements, issues, risks and programme and 

concludes with the management of the acceptance process for HFI. 

3.1.1 Co-ordination 

Co-ordination is concerned with the project organisation and Working Groups in 

connection with Human Factors Integration (HFI). HFI issues are relevant to 

many areas of design and therefore require active and effective co-ordination 

across disciplines. The key to achieving successful HFI is clear and adequate 

delegation of roles within and outside the IPT. The IPT Leader is responsible for 

ensuring that HFI is applied in the project through the allocation of roles and 

responsibilities within the IPT in conjunction with other MoD authorities and the 

supplier(s). 

Note … Some information contained within this section is taken from the 

‘Introductory Guide’ [Ref 3]. 

The allocation and terms of reference of HFI roles will be influenced by the 

following factors: 

• The importance of, and risks associated with, HFI issues at each phase of 

procurement. 

• The degree of liaison required with other disciplines and organisations. 

• The amount of work to be monitored assessed and accepted. 

An effective organisation will show the following characteristics: 

• Clear ownership for the effect of HFI issues on total-system performance 

and supportability. 

• Full understanding of the priorities and risks to be addressed in the HFI 

Programme. 

• Recognition of the effects of HFI issues on costs, not just on performance 

and supportability. 

• A single HFI Focus responsible for monitoring the development of, and 

work associated with, the Human Factors Integration Plan (HFIP). 

• Awareness of the HFI process from previous experience or training. 

• Adequate allocation of project resources to address HFI issues. 

• Regular co-ordination of HFI activities and output products during 

requirements analysis, design, construction, installation and support. 

• Regular liaison with other MoD Authorities and Agencies about HFI 

responsibilities, issues and progress. 



The whole HFI process depends on effective integration: within the project team 

and across the many external agencies involved in acquisition. Integration with 

other aspects of the project is particularly important for HFI because of its 

breadth and the range of other specialisms it overlaps. The MOD recognises the 

crucial role of the human element within military capability. Through HFI, 

knowledge of human capabilities, limitations and requirements can inform the 

activities of many other disciplines and thus system performance, time-scale and 

cost targets can be met. It is important to ensure that HF effort is properly 

integrated within the overall project effort. The Joint Capability Board may 

provide useful input of ‘pan IPT’ issues and requirements. 

An HFI working group should be formed as soon as possible. HFI activities for 

the Concept phase should be planned as soon as the embryonic IPT forms. 

Later phases will inherit endorsed plans prepared during the preceding phase. 

Different sizes of project will typically vary in the way that HFI is organised within 

the IPT. All projects should ensure that the staffs allocated HFI responsibilities 

receive adequate briefings or training in the conduct of this process. An IPT may 

decide to organise for HFI according to the procurement strategy and the 

resources available. 

3.1.2 What is Involved 

The HFI working group provides a means for effective communication, coordination 

and consensus formation among the stakeholders in HFI. The scale of 

its activities will depend on the project. Typically, activities include the following: 

• Set up and manage HFI Working Group as early as possible. 

• Define its terms of reference. 

• Obtain support and backing from the lead DEC and/or IPT Leader, with a 

clear line of reporting to them. 

• Include representation from user representatives, other technical areas of 

the project and all stakeholders with an interest in human aspects of the 

capability. 

• Identify other working groups with significant impact on the effectiveness of 

the HFI effort and ensure HFI is represented on them (in addition to them 

being representatives within the HFI working group), for example: 

o 

o 

o 

o 

o 

ILS 

Maintenance 

Safety 

Acceptance, Test and Evaluation 

Requirements management 



3.1.3 CWG and IPT Roles within HFI 

The responsibility for HFI is inherently shared between Capability Working Group 

(CWG) and IPT. The desired capability will be achieved by a combination of 

people, procedures and equipment. The CWG, and in due course Customer 2, 

must ensure the provision of the right people and procedures, whilst the IPT must 

ensure the provision of the right equipment. HFI helps the IPT and CWG work 

together, trading off changes to equipment with changes to people and 

procedures in order to ensure total system effectiveness. HFI management is 

embedded within the wider project team. It is driven by, and contributes to the 

same information and products as the rest of the team. The HFI strategy should 

show how the key goals of the HFI effort will help achieve overall project goals. 

HFI technical activity normally involves other stakeholders. 

Effective HFI requires a co-ordinator, nominally called the ‘HFI Focus’. The 

responsibility for HFI might be undertaken by another role within the team, or by 

the project manager. During most phases of acquisition, the role of HFI Focus 

will fit naturally within the IPT. During Concept phase someone in the CWG 

should take responsibility for HFI and act as the HFI Focus before the embryonic 

IPT is formed. Started early, HFI will yield the greatest gains for least cost. 

Waiting until the IPT is established loses valuable time, increases risk and could 

lead to a less valuable HFI contribution to the documents supporting the business 

case at Initial Gate. 

3.1.4 HFI Steering Groups and Working Groups 

3.1.4.1 Organisation 

In order to manage HFI at the level of platform procurement, two types of HFI 

Groups are often formed. At an overall platform level, a Human Factors Steering 

Group (HFSG) is formed. Beneath this, Human Factors Working Groups 

(HFWG) are formed, based on different areas or subsystems within the platform, 

for example ‘Escape and Evacuation’. Figure 3-1 gives an example for a project 

involving the procurement of a large naval system. 

Human Factors Steering 

Group 

HF Working Group 

Accommodation 


Complementing 


Combat Systems 


Seamanship/RAS 


Bridge 

Figure 3-1: Organisation of HF Steering Group and HF Working Groups 

3.1.4.2 The Requirement for HF Steering Groups and Working Groups 

The HFI Focus may need to form an HFSG and associated Working Groups for 

the duration of the programme or during a specific project. Whether or not an 

HFSG is formed, the HFI Focus must identify all stakeholders and seek their 

involvement as appropriate. 



The HF Steering Group may be needed under the following circumstances: 

• The project is large and complex, as is normally the case with the 

procurement of a new platform or Combat System. 

• The HFI Programme represents a critical path in the overall TLMP and 

needs to be formally discussed with other IPT members, stakeholders, 

Supplier personnel (including subcontractors) and MoD Authorities. 

• The HFI Programme is used as the focus for some aspect of project 

development, e.g. complement studies, user-equipment interface design, 

Training Needs Analysis etc. 

The development of the total system to deliver an effective operational capability 

with minimal support costs requires the effective application of a multi-disciplinary 

approach. The unique contribution of HFI is to concentrate on the human 

performance and support requirements and HF characteristics to be delivered. 

HFI works with other disciplines in a number of general ways as follows: 

• HFI provides basic data on human limitations and capacities that drive 

design decisions in other disciplines, e.g. data on basic visual acuity is 

used to determine display characteristics. 

• HFI provides techniques, methods and models that enable assessment of 

the feasibility and value of design options proposed by other disciplines, 

e.g. human workload analysis used to assess the feasibility of alternative 

human-computer interface designs. 

• HFI provides unique contributions to the overall design concept, e.g. 

techniques for modelling complement size and the future organisation of 

the crew. 

The Human Factors Integration Plan (HFIP) must identify the dependencies and 

interfaces between HFI activities with other disciplines in the context of the 

overall Through-Life Management Plan (TLMP). It is important to realise that 

closer integration with other disciplines can also lead to greater efficiency and 

real cost savings to the overall programme. Poor integration leads to risks of 

sub-optimal human performance due to inferior product design (limiting 

operational capability), higher support costs, greater health and safety risks and 

waste of development resources and costs. 

The sections below provide guidance about how HFI works with other disciplines 

during system development. The advice contained within these sections is 

primarily aimed at the HFI Focus for the project or programme. 

3.1.4.3 Who is Involved 

HFI requires a multidisciplinary team approach within the HF Steering Group and 

Working Groups, involving: 

1. Principal Personnel Officer (PPO) – Who need to review HFI implications 

for manning, the scheme of complement, future personnel selection and 

retention aspects. FLEET-NPS and FLEET-NLM represent the PPO in 

these matters. FOTR provides a focus to explain RN training policy and to 

review training issues. RN Intelligent Customer Group (RN ICG) and 



representatives from RN training schools may also be invited to discuss 

Training Needs Analysis and training implementation. 

2. Manpower planners – Who need a dialogue to ensure that proposed 

systems will integrate as part of wider work systems that can be 

sustainably manned. 

3. Recruitment agencies – Who need a dialogue about trends in recruitment 

and abilities of service entrants to ensure a match between system needs 

and future personnel supply. 

4. Equipment specifiers – Who need to include operability and other 

requirements to ensure equipment will be ‘fit for use’. 

5. Equipment designers – Who need to understand users’ tasks, capabilities 

and limitations. 

6. HF Specialists – Who are needed to deal with specific issues, to review 

the outputs of the HFI Programme and to provide guidance on MoD policy. 

7. Industrial Suppliers – Who need to understand the context and 

constraints of operational use. They need to contribute information about 

ways in which technology can ease the integration of the people into the 

system. Suppliers are also best able to supply detailed analysis and 

performance information to support operability and other evaluations of 

human ‘fit’ for the solutions they offer. 

8. Acceptance Authorities – Who need reliable, practical means of 

evaluating effectiveness in use. 

9. Training providers – Who need to understand the gap between what is 

needed to use equipment effectively and the capabilities of the designated 

personnel. Training providers also need to feed back information so 

equipment can be designed to reduce the training burden. 

10. Safety Authorities including Naval Authorities – Who need to 

understand the human contribution to hazardous events and how design 

can enhance safety. 

11. Users – Who represent RN, RM, Army and RAF HQ units and to provide 

subject matter expert opinion. 

12. Operational Analysis – Who needs to undertake mathematical modelling 

and simulation of operational performance and develop whole-life costs of 

platform and equipment design options. 

13. Integrated Logistics Support (ILS) – Who need to develop the support 

concept and assess Availability, Reliability and Maintainability of the 

system. 

14. Whole Life Support (WLS) – Who need to co-ordinate the Integrated 

Logistics Support (ILS) work programme and to review the HFI implications 

for support options. 

15. Sea Systems Group - Ship Safety Management Office (SSG-SSMO) – 

Who need to co-ordinate requirements for the ship safety case and the 

ship safety management system. 



MAP-01-011 identifies the Authorities and other stakeholders that are involved 

with each HFI activity at each phase of procurement. These may also need to be 

represented in the HFSG. Whether or not an HFSG is formed, the HFI Focus 

must identify all stakeholders and seek their involvement as appropriate. 

For naval systems, the HF Steering Group typically consists of at least the 

following members, see Table 3-1. 

IPT 

HFI Focus (often from 

ILS) 

Prime Contracting 

Organisation 

HF Lead 

INM 

Other Stakeholders 

ILS Manager Quality Assurance MLS (MoD Abbey Wood) 

Requirements Manager Safety SSG (SSG-CSHF) 

Subsystem HF Foci Subsystem specialists Customer 1 (DEC) 

Customer 2 

Table 3-1: HF Steering Group Members 

Each HF Working Group will comprise representatives from the stakeholders 

listed in Table 3-1, along with engineering and personnel from each of the 

subsystem areas. 

3.1.4.4 Specialist HF Capability 

Performing HFI successfully depends on specialist capability in disciplines such 

as human physiology, biomechanics, psychology, ergonomics and, indeed, HFI. 

Some activities though, particularly in the first pass conducted in Concept phase, 

may be carried out by other disciplines with suitable guidance. In most areas it is 

not possible to undertake HFI in isolation from the other stakeholders who are 

often the owners of key data as well as the means to implement the solutions. 

Specialist support in HFI can be obtained by consulting the full list of Registered 

Ergonomics Consultancies and Registered Members and Fellows from the 

Ergonomics Society (ES) website [Ref 26]. 

3.1.4.5 Other HF Stakeholders 

Good HFI depends on good relationships, as well as on well-applied knowledge. 

Many organisations and specialities have a stake in HFI. All stakeholders should 

be involved in the process as early as possible, although they may not 

necessarily be members of either the HF Steering Group or Working Groups. 



The following activities need to be conducted to ensure that stakeholders are 

involved: 

• Identify key and peripheral stakeholders (including those who will be useful 

sources of information and those who will be affected by the project), see 

Figure 3-2; see also ‘Practical Guidance for IPTs’ [Ref 17] for information 

on stakeholder type and role. 

• Identify and make contact with those who can contribute to thinking on HFI 

(e.g. those organisations that hold information about user characteristics, 

lessons learned from in-service equipment and knowledge about future 

technologies and operations). 

• Review other project plans and activities for required HFI inputs. 

Personnel 

agencies 

Operational 

commands 

Training 

Training 

agencies 

Safety 

authorities 

Personnel 

System Safety 

Recruitment 

agencies 

HFI Domains 

Logisticians 

Manpower 

Health Hazard 

Manning 

planners 

Cost 

forecasters 

HF Engineering 

Acceptance 

authorities 

System 

engineers 

Equipment 

developers 

Figure 3-2: Stakeholders in HFI Domains (excluding Organisational and 

Social Domain) 

Some terms are used differently by different stakeholders. HFI concerns crossorganisational 

boundaries within MoD, and responsibilities within the project 

team. The emphasis of HFI should be on integration across the whole system. 

The range of issues covered by the HFI activity will usually be far larger than the 

available resources can support. Effective sharing and re-use of activities and 

information from other areas of the project can significantly add to what HFI can 

achieve from its own budget. Re-use and sharing of information should be 

encouraged and may be enhanced by the use of common databases. 



3.2 HFI Management of Requirements, Issues and Project Control 

This section describes the HFI roles and responsibilities for: 

• Identifying and managing requirements for the HFI element of the project. 

• Identifying and managing issues for the HFI element of the project. 

• Managing the control of the HFI programme. 

3.2.1 Identifying and Managing Requirements 

The process of identifying and managing requirements ensures that the customer 

requirement is fully defined and mutually understood by the customer and the 

IPT. 

The HFI Focus is responsible for ensuring that HFI aspects of the customer 

requirements are fully understood and for incorporating these requirements for 

the procurement into the URD and SRD. The URD and SRD should therefore 

include human performance requirements and design characteristics, and the 

methods by which satisfaction of these are assessed and accepted. 

The HF characteristics (see Chap 1) of the system will play a major role in 

determining ultimate operational capability, supportability and safety. 

Requirements in the URD and SRD must therefore ensure that these HF 

characteristics are studied, assessed and used during the design and 

development of platforms and equipment. 

For some legacy projects, the customer requirement may have been developed 

into Agreed Characteristics that are traceable from the URD. 

3.2.1.1 The Requirements Management Process 

Investment in HFI must ensure that any human-related issues with a significant 

impact on a system’s ability to deliver the required capability are properly 

captured in the requirements at Initial Gate, Main Gate and subsequent 

evolutionary approvals. To be effective, the HFI contribution must be fully 

integrated with all other material. The process is essentially the same in both 

Concept and Assessment phases. 

• Identify what documents are to be produced and who ‘owns’ those with a 

bearing on the human aspects of the capability. 

• Identify sections in relevant requirements documents that will require (or 

benefit from) consideration of human-related issues. 

• Discuss with the document owner what contribution HFI can make. 

• Agree the form and time-scales for HF contributions: identify key human 

issues in high-level documents and more detail in lower-level documents. 



• Ensure contributions reflect human performance assumptions and humanrelated 

risks and opportunities. 

• Ensure that contributions are properly integrated with other parts of the 

document. 

3.2.1.2 HFI content of the URD and SRD 

The HFI content of the URD and SRD, including their type, content and format 

are discussed in ‘Practical Guidance for IPTs’ [Ref 17]. 

3.2.1.3 Acceptance Criteria 

All requirements should be accompanied by agreed acceptance criteria. These 

might not be fully defined at initial issue, but should be completed before Main 

Gate. Pass thresholds (values of criteria to be exceeded) should be agreed 

before contract. If this is not possible, the ITEAP should define a mechanism and 

a programme for agreeing them. 

3.2.1.4 HFI in Requirements Change Management 

‘Practical Guidance for IPTs’ [Ref 17] discusses the role of HFI in deriving and 

managing requirements more fully. The HFI domains (Manpower, Personnel, 

Training, Human Factors Engineering, System Safety, Health Hazard 

Assessment, and Organisational and Social) also provide a structure for deriving 

requirements. It is recommended that the HFI Technical Areas in MAP-01-011 

be used to fully define the customer requirement. MAP-01-011 provides 

guidance on HFI activities, outputs and methods for use by the HFI Focus when 

understanding and developing the customer requirement and for assessing the 

HFI issues, risks and through-life implications of technical options. 

HFI concerns must be integrated into the process of creating and managing the 

requirements, especially as requirements change. Requirements may change 

because: 

• The need changes during acquisition. 

• One component might have to change in response to new information 

about what is and is not achievable with another component. 

• Requirements need clarification and interpretation in order to support 

design decisions with information at a level of detail not contained in the 

SRD. 

The skill in HFI is to understand the side effects of the changes on the extensive 

web of dependent assumptions, requirements, constraints and design decisions. 

Because of the pervasive nature of human issues, trade-offs made anywhere in a 

system design can have potential implications for the HFI requirements. These 

all need careful management. 

HFI requirements can be complex and difficult to specify precisely. Managing 

change in HF requirements is challenging even with the support of a good 

change management system, but it is one of the most important aspects of 

effective HFI. For more information, including a checklist to ensure that HFI is 

applied to requirements change management, see ‘Practical Guidance for IPTs’ 

[Ref 17]. 



3.2.2 Identifying and Managing HFI Issues and Risk 

3.2.2.1 Introduction 

Identifying and managing human related issues and risks are central to HFI. The 

process consists of a series of activities that are performed iteratively, including 

the following: 

• Identifying HFI issues. 

• Assessing their impact. 

• Managing and tracking the issues to their eventual resolution. 

3.2.2.2 Early Human Factors Analysis (EHFA) 

The basic process for identifying and assessing the impact of HFI issues is 

known as EHFA (Early Human Factors Analysis). Within Smart Acquisition, the 

process should be started in the Concept phase, developed in Assessment, and 

be periodically revisited at major decision points through the life of the system. 

Based on established risk management techniques, EHFA helps define and track 

key human related issues at an early stage when there is limited information 

about potential solutions. It contributes directly to project requirements and risk 

management. 

EHFA need not be complex nor require major resource. Project size and 

complexity drive the effort needed, as does the expected human role in the 

system and the quality and ease of access to suitable information sources. 

Where limited resources are available (e.g. with smaller projects), the technique 

can be undertaken effectively by one person who has appropriate analysis skills 

and awareness of the potential scope of human issues. EHFA comprises three 

steps: 

1. Establish the baseline for HFI. 

2. Identify HFI issues. 

3. Assess the impact of HFI related risks. 

The results of the Early Human Factors Analysis (EHFA) will indicate the initial 

issues and risks that need to be addressed in the HFI Programme. Chap 1 of 

this guide discusses HF issues by HFI domain (Manpower, Personnel, Training, 

Human Factors Engineering, System Safety, Health Hazard Assessment, etc for 

platforms and equipment). MAP-01-011 HFI Technical Areas should be used to 

help the HFI Focus to understand the implications of these issues for the 

procurement strategy. 

The Human Factors Integration Plan (HFIP) (discussed in Chap 4 of this guide) 

must clearly describe each of the issues that are to be addressed. 

The following information on actions required to address the three steps for 

EHFA highlighted above is taken from ‘Practical Guidance for IPTs’ [Ref 17]. 



3.2.2.3 Establish the baseline for HFI 

• Actions 

• Outputs 

• Identify all material defining the baseline (the fixed inputs, background, 

objectives and scope of the project, relevant standards etc.). 

• Check for content relevant to the HFI domains, noting what is ‘core’ to HFI. 

• Identify what is known, or is current thinking, about human-related issues. 

• Determine what is ‘fact’ and what is ‘assumption’ and document both. 

• Note any likely HFI distinctions between options under consideration. 

• Identify areas where there is no information on HFI matters and decide 

how to fill gaps. 

• Agree HFI analysis activities, time-scales and outputs. 

• HFI Baseline, with reference to facts, decisions, assumptions, constraints. 

• HFI Assumptions register including (for each assumption): 

o 

o 

o 

o 

o 

A unique reference number and description of the assumption. 

Related concept options or concerns. 

The source of the assumption and when it was raised. 

A statement of the assumption’s validity. 

The sensitivity of the project to the assumption. 

• Checklist 

Documents containing human related information could be about: 

• The operational need 

o 

o 

Missions, scenarios and operational context. 

Concept of use, interoperability. 

• Predecessor system(s) 

o 

o 

o 

o 

Manpower or personnel problems. 

Training methods, facilities and problems. 

User interface, workplace layout or environment features and 

problems. 

Maintenance and support philosophy, organisation, facilities, 

practices and problems. 



o 

Operator, maintainer and support personnel performance. 

• Future trends 

o 

o 

o 

o 

Demographics, recruitment. 

Policy for manning, training, maintenance and support. 

Philosophy, organisation and infrastructure for maintenance and 

support. 

Legislation of safety, health and working conditions. 

• Capability options 

o 

o 

o 

o 

Organisational structure. 

Personnel options, problems and/or constraints. 

Recruitment and retention policy. 

Equipment, maintenance and support options. 

3.2.2.4 Identify HFI Issues 

• Actions 

• Outputs 

• Set up registers to manage HFI assumptions and issues. 

• Review information sources for a high level assessment of potential HFI 

assumptions and issues. 

• Consult stakeholders to identify assumptions and issues. 

• Identify areas where HFI is likely to have a high impact on cost, timescales, 

personnel safety or system effectiveness. 

• Document the assumptions and issues. 

• HFI Issues Register, including (for each issue) 

o 

o 

A unique reference number and description. 

A likely impact on cost, time-scale, safety or system effectiveness. 

• Checklist 

For each option, have you considered 

• The system 

o 

o 

Human-related risks of procurement strategy. 

Time available for HFI activities. 



o 

o 

Availability of Human Factors (HF) data. 

Human-equipment integration. 

• Manpower 

o 

o 

o 

o 

o 

Potential manpower shortages or surpluses. 

Cost of too high or too low manpower forecast. 

Potential accommodation problems. 

Wider organisation implications (e.g., manning for damage control 

or guard duty). 

Allocation of tasks between organisations, teams and individuals. 

• Personnel 

o 

o 

o 

Potential skill or knowledge mismatch, risks of new skill 

requirements. 

Requirements for increased multi-skilling. 

Task failures and errors. 

• Training 

o 

o 

o 

o 

o 

Training capacity and likely training demand. 

Potential new training needs. 

Novel types of training need. 

Skill fade (i.e., loss of basic skills due to infrequent use). 

Negative transfer (mismatch of responses learned from other 

experience). 

• HF Engineering 

o 

o 

o 

o 

o 

Physical or mental workload (operation, maintenance or support). 

Workplace layout and environment. 

Situation awareness with automated systems. 

Quality of teamwork. 

Maintenance problems. 

• System safety 

o 

o 

o 

Workspace and platform constraints – visibility, ingress and egress. 

Work/rest cycles. 

Safety related tasks. 



• Health hazard assessment 

o 

o 

o 

Hazardous operations or conditions. 

Hazardous equipment or material. 

The working environment, posture and duty cycles. 

3.2.2.5 Assess Impact of HFI Risks 

• Actions 

• Outputs 

• Enlist support of people with operational experience and HF Specialists as 

needed. 

• Assess the likelihood and impact of each risk (high, medium or low) – 

ensure impact ratings conform to project wide definitions. 

• Combine these using a standard risk matrix to give an overall score, and 

hence priority. 

• Document the assessment. 

• Record HFI risks in the Project Risk Register. Where necessary, 

aggregate to achieve granularity consistent with other project risk 

statements. 

• Provide EHFA report to CWG for review. 

• HFI Issues Register including (for each issue): 

o 

Proposed strategy for mitigating the associated risks. 

• EHFA report (that can then be called up by the TLMP) containing: 

o 

o 

Validated assumptions, requirements, constraints and concerns. 

Prioritised, agreed risks with mitigation strategies for each. 

3.2.3 Risks and the Project Risk Register 

Once identified, HFI issues for which risk management activities are required 

should be described in the Human Factors Integration Plan (HFIP). The EHFA 

and subsequent activities will indicate risks that should be entered into the risk 

register. HFI issues should be expressed in the same way as other types of risk. 

Probability and impact on the operational capability, supportability, health and 

safety, and on the project itself should be expressed for each risk. 

HFI risks to be addressed in a programme fall into four broad categories: 

1. Failure to meet the full operational requirement, e.g. operator workload in 

projected scenarios limits overall response times to threats. 



2. Failure to produce a supportable system within the costs and resources 

available, e.g. skill and knowledge required to operate new equipment 

exceeds that planned in current manpower and training policy. 

3. Failure to meet health and safety requirements, e.g. excessive heat in 

operational compartments in particular climates. 

4. Failure to complete the programme within cost and time, e.g. equipment 

user interface design is found to be unusable during Trials and Acceptance 

and requires significant redesign. 

HFI issues should also be fed into the Project Risk and Issues Register. Figure 

3-3 shows the relationship between the Project and the HFI mechanisms used to 

resolve HF issues and risks. 

Through Life Management Plan 

(TLMP) 

HF Policy 

Paper 


Integration Plan 

(HFIP) 

Project Risk & 

Issues Register 

HF Issues 

Register 


Activity 


Output 

Stakeholders 

Human Factors Integration Log 

(HFIL) 


Deliverables 

Human Factors Data 

Collection 

Figure 3-3: Activities to Address HF Issues 

The project Through-Life Management Plan (TLMP) is the starting point for the 

HFI deliverables. The HF Issues Register should form a sub-set of the Project 

Risk and Issues Register, with a two-way exchange of information between 

Project and HFI databases. Issues and risks arising from the HF Issues Register 

will be entered into the Human Factors Integration Log (HFIL) in order to track 

their progress and eventual resolution. The Human Factors Integration Plan 



(HFIP) will be updated to reflect the activities required in order to investigate and 

ultimately resolve the issues and risks. HFI deliverables will be the result of 

those HFI activities addressing the issues and risks. 

Thus the HFIP sets out the plan of action, while the HFIL records past decisions 

and data and shows present status. 

3.2.4 Content of the Human Factors Integration Log (HFIL) 

The Human Factors Integration Log (HFIL) is a concise summary of the 

accumulated project Human Factors (HF) data and it records important decisions 

relating to HFI issues, risks and trade-offs. 

The following information must be recorded in the HFIL: 

• Summary of issues and risks for project (from the Human Factors 

Integration Plan (HFIP) and project reviews) cross-referred to HFI Domain 

and HFI Technical Area. 

• Minutes of all Human Factors Steering Group (HFSG) and Human Factors 

Working Group (HFWG) meetings. 

• Index to HFI deliverables and cross-index to other deliverables with related 

content. 

• Results of HFI system and design trade-offs, e.g. selection of options 

during Combined Operational Effectiveness and Investment Appraisal 

(COEIA), use of results of assessments, major conclusions from studies. 

• Results of HFI assessment and acceptance tests. 

The HFIL must be maintained to provide information that can be used as the 

basis for subsequent HFIPs in the programme. The log must be structured to 

allow an audit trail for all decisions. The development of the log is the 

responsibility of the HFI Focus and this responsibility may be delegated to the 

Supplier. The HFIL should be referred to and maintained during In-Service 

updates and modifications to the platform or equipment. 

3.2.5 Assess the Impact of HFI Related Issues and Risks 

Having identified and recorded HFI issues and risks, actions are required to 

assess their impact on the design of the system and the whole-life implications. 

‘Practical Guidance for IPTs’ [Ref 17] describes the actions required to assess 

this impact, along with a risk-scoring matrix to prioritise the level of risk. 

3.2.6 Managing Issues Through-Life 

EHFA is most important during Concept and Assessment, when the options are 

being explored and defined. Many of the HFI issues identified early will not be 

fully resolved by Main Gate, and more will arise during subsequent phases. The 

HFI issues register and other relevant project/HFI risk registers should be kept 

live throughout the project, and the Human Factors analysis of issues revisited at 

all key events. As the project progresses, the main source of issues to be 

managed will shift progressively from exploratory work, research and experience 

with other systems to feedback from the evolving experience of the system itself. 

It is necessary to ensure the necessary communication mechanisms are in place 



to capture this experience. Table 3-2 is a summary of activities required to 

manage HFI issues through the life of the system. 

Phase Event/Activities HFI Activity Feeding Issues 

Concept & 

Assessment 

Demonstration 

Manufacture 

In-Service 

Requirements Capture; 

Trade-off studies 

Contract award 

Major trials 

Equipment acceptance 

trials 

Initial operational work up 

Routine deployment 

Extended use 

Proposed upgrade 

Main phases for EHFA 

Identify impact of negotiated 

changes 

Assess impact of human 

performance 

Assess impact of any shortfalls 

Draw issues out of military 

user’s initial experience 

In service HFI audit after settling 

down 

Feedback from the front line 

Assess new issues driven by 

change 

Disposal Decommissioning Identify any non-routine hazards 

Table 3-2: Summary of HFI Activities to Manage HFI Issues by Procurement 

Phase 

3.2.7 Importance of Whole Ship HFI Issues and Co-ordination 

The role of any procurement programme, including those that are part of 

updates, is to develop, select or modify a system that provides the capability and 

performance required in the operational requirement. Every system, whether at 

platform or equipment level, will eventually need to be successfully integrated 

with other existing or newly developed systems, subsystems or products. A 

major factor determining success is the resolution of the HFI issues that will 

inevitably arise as a result of entering new platforms and equipments into service. 

In the past, HFI Programmes have often been limited to addressing the design of 

specific issues associated with individual equipments. The delivery of effective 

performance and control of support costs, however, requires that a total-system 

approach be applied. A total-system approach recognises that it is the 

combination of the future operational context, the application and design of 



technology, the deployment and the tasks and characteristics of personnel that 

determines performance and supportability. 

Two general types of procurement situation exist in which a Whole Ship 

approach is applied: 

• Development of a new platform that may include a mixture of existing and 

new equipments. 

• Development of modifications or new equipments for an existing platform. 

3.2.7.1 Whole Ship HFI Co-ordination Process 

Whole Ship co-ordination of HFI requires a total-system perspective. The key to 

an effective Whole Ship approach is to consider the effect of every procurement 

decision on the user. In terms of project or programme management this is 

achieved by applying the HFI guidance contained in MAP-01-010 and MAP-01- 

011. 

The Whole Ship co-ordination process consists of two general components: 

• Monitoring Human Factors Integration Plans (HFIPs) between different 

projects in a top-down manner from the platform level down to the level of 

individual equipments. 

• Execution of HFI activities and the collection of data that address the 

impact of design decisions on the Whole Ship. 

The relationship between HFIPs and Human Factors Integration Logs (HFILs) in 

the Procurement Process is illustrated in Figure 3-4. 

Platform 

Supplier 




IPT Human 




Execution 


Integration Log 


HFIP 

Co-ordination 


Data Collation 

Equipment 

Supplier 




IPT Human 




Execution 


Integration Log 


Figure 3-4: Whole Ship HFI Co-ordination using HFIPs and HFILs 



In a procurement project, HFIPs will be developed for each part of the project. In 

practice each plan is separate though each will need to take account of the 

Through-Life Management Plan (TLMP) for the wider system. Project plans must 

ensure that HFI, at each phase of procurement, makes provision for joint conduct 

of activities and sharing of data with all related projects where common issues 

may be affected. 

Each project will execute activities and generate data that is recorded in the 

HFIL. This data is used to understand the implications of procurement decisions 

top-down from the platform, and bottom-up from specific equipments. 

MAP-01-011 contains detailed guidance about the process for achieving Whole 

Ship co-ordination. 

3.2.7.2 Responsibilities for Whole Ship HFI Issues and Co-ordination 

The IPT Leader is responsible for Whole Ship HFI co-ordination for new 

platforms. Individual Project Managers are responsible for ensuring that their HFI 

Programmes provide the information required by the IPT Leader for new 

platforms. System Project Managers are responsible for Whole Ship coordination 

for existing vessels often in close collaboration with existing crews and 

Service authorities. 

Whole Ship HFI co-ordination requires the following management steps: 

Project Co-ordination Checklist 

Identify the procurement programmes and projects of relevance to the 

development of a new platform or equipment or the modification of an existing 

platform or equipment. 

Organise contact points and steering groups responsible for HFI and specify 

their terms of reference – MAP-01-011 lists stakeholders involved in each HFI 

Technical Area. 

Identify the issues that require liaison across different procurement and support 

programmes and projects. 

Collate existing Human Factors (HF) data relevant to the new equipment or 

modification from previous procurements or field studies. 

Adapt the Human Factors Integration Plan (HFIP) to ensure that activities 

address shared issues and risks. 

Describe dependencies between the plans in various programmes and 

projects. 

Identify the products and data needed for Whole Ship co-ordination to ensure 

that the information required is available. 

Table 3-3: Whole Ship HFI Co-ordination Actions 



3.2.8 Managing and Monitoring the Project 

3.2.8.1 Scope 

Responsibilities for managing and monitoring HFI activities and HFI suppliers fall 

to different project roles as identified in Chapter 1 of this document. The 

responsibilities include the following: 

• Managing the project 

• Managing and monitoring the HFI activities 

• Managing subcontracts 

• Assessment of Supplier HFI 

Integrating Human Factors activities within a project can be challenging. Coordinating 

contributions from the many stakeholders with an interest in human 

issues can be complicated by the organisational boundaries involved. The 

Integration Authority (IA) or Joint Capability Board (JCB) might provide useful 

input regarding ‘pan IPT’ issues and requirements. The foundation work for HF 

integration should begin as early as possible in acquisition, when ideas are 

embryonic, i.e. during the Concept phase. 

3.2.8.2 Managing the Project 

The HFI Focus manages the Supplier(s) to ensure that the product or service is 

delivered within timescale and budget to meet the required specification. 

The HFI Focus monitors progress against the Human Factors Integration Plan 

(HFIP). Progress monitoring may take the form of HFI progress reports and 

meetings in addition to overall project design reviews. The HFI activities and 

products are checked to ensure that they comply with requirements stated in the 

CSA and the ITT. The management of HFI risks is monitored. The HFI Focus 

assesses the impact of HFI on the overall project and provides approval or 

otherwise to the on-going work programme. Other stakeholders may be invited 

to help monitor, assess and direct the HFI work (see Section 3.1 and MAP-01- 

011). HF Specialists can be used to assess the technical worth and implications 

of the HFI work. 

3.2.8.3 Monitoring HFI Programme 

The HFI Focus is responsible for monitoring the HFI work conducted in the 

project. At a detailed level this is achieved by comparing Supplier HFI activities 

and products against the Human Factors Integration Plan (HFIP). More 

generally, the HFI Focus should also assess the following: 

• The impact of the HFI work on overall system operational capability, 

supportability and safety. 

• That Whole Ship HFI co-ordination is achieved (see Chap 1). 

• The cost-benefits of each part of the HFI work, in terms of the contribution 

to operational effectiveness, reduction of whole-life costs and reduction of 

product development costs and risks. 



• That Human Factors (HF) data and recommendations are actually applied 

in the system development process. 

• That appropriate and timely liaison about HFI issues and risks is 

maintained with other parts of the MoD. 

• Continuity of the HFI Programme is maintained so that the most important 

issues and risks are managed at all phases of the procurement. 

3.2.8.4 Managing Subcontracts 

This process is followed to purchase products and services. The Invitation to 

Tender (ITT) is developed to include the SRD, the statement of work and 

standards together with contractual and other requirements. Tenderer responses 

are assessed and contracts are placed. 

At each procurement phase the HFI Focus prepares relevant content of the 

Invitation to Tender (ITT). A skeleton Human Factors Integration Plan (HFIP) 

may be included in the ITT. Specific HFI activities and outputs may be called up 

in the statement of work. HFI standards may be applied and the tenderers may 

be invited to describe their approach to the development of project-specific 

standards. The weighting given to HFI aspects in evaluating the overall worth of 

each response is decided. The proposals from tenderers are evaluated. 

The following is a general list of topics, which will be described in the HFI Section 

of the ITT: 

• MoD approach to HFI (see Chap 2). 

• Prime Contracting Organisation (PCO) proposals for end user and 

customer participation. 

• MoD requirements for HF attributes and characteristics of the system. 

• HFI standards (see MAP-01-011 Annex 2). 

• Any HFI requirements and constraints from Early Human Factors Analysis 

(EHFA). 

• HFI Issues. 

• PCO proposals for defining and using operational scenarios. 

• Project Specific Target Audience Description (PSTAD). 

• Use of existing Human Factors Style Guide(s). 

• PCO approach to total System Integration issues (see Chap 2 and Section 

3.2.7 regarding Whole Ship co-ordination and multidisciplinary integration). 

• Requirements for Supplier’s HFIP (see Chap 4). 

• Details of additional required HFI Deliverables. 

• Requirements for new Human Factors Style Guide. 



3.2.8.5 Assessment of Supplier HFI Activities 

Down selection of Suppliers is a major project decision. Suppliers are judged not 

only on the solutions offered, but also on an assessment of their ability to deliver 

what they offer. At the time of selection, many HFI issues will be only partly 

explored, with few fully resolved. The Supplier will influence the effectiveness of 

HFI after down selection, either as an IPT member or, more significantly, in terms 

of the design and development process. For the system to be effective, the 

benefits of HFI gained during the project’s early phases must be carried through 

into implementation. Evidence of the Supplier’s competence to do this must be 

sought and used as part of a balanced selection process. 

The following activities need to be assessed in order to evaluate Supplier HFI: 

• HFI content of Supplier results produced so far. 

• HFI analysis, assessments and trials. 

• Contribution to HFI Working Group. 

• Development of prototypes and demonstrators. 

• Understanding of context of use. 

• HFI content of plans and processes offered. 

• Active management of human-related issues. 

• Involvement of users in design and review. 

• Use of prototypes and progressive evaluation of operability. 

• Acceptance tests for operability and key aspects of human performance. 

• Mechanisms by which HFI work will be able to exert influence. 

• Dependence on Government Furnished Assets (GFA). 

• Quality/credentials of HFI team. 

• Extent to which HFI is integrated in the Supplier organisation. 

• Quality of working links between HFI and development teams. 

‘Practical Guidance for IPTs’ [Ref 17] provides a Checklist of questions by which 

the HFI Focus can ensure that Supplier HFI activities are addressed. 

Additionally, the HFI Process Risk Assessment can be applied. This process 

uses a model of HFI as a benchmark to define and monitor project activity and 

assess whether the HFI guidance on the Acquisition Management System are 

being adopted and adhered to; for advice and background, see ‘HFI Process 

Risk Assessment (PRA)’ [Ref 27]. 



3.3 Managing Acceptance 

This section describes the responsibilities of the HFI Focus in managing the 

acceptance process and the responsibilities of the supplier in the design of 

acceptance testing procedures. 

3.3.1 The Acceptance Process 

Acceptance is the formal process to certify that contractual commitments have 

been met, and that the deliverables meet their requirements. Equipment 

acceptance is based on evidence that the equipment has the required attributes 

and performs as specified in the SRD. This evidence is normally based on a 

combination of inspection (of the equipment and supporting documentation) and 

tests or trials (of the equipment). Evidence should be gathered incrementally 

during development and manufacture. 

The acceptance process is described in more detail in Chapter 2 of this 

document and in ‘The Acquisition Handbook’ [Ref 2]. This section also contains 

material taken from ‘Practical Guidance for IPTs [Ref 17] which should be 

referred to for more detailed information. 

Table 3-4 below summarises the acceptance ‘stages’, although acceptance is a 

whole-life process. At an early stage during the acquisition process, the IPT 

Leader and the DEC (as the Acceptance Authority) will agree an acceptance 

strategy that will identify how the acceptance process will be applied and will 

enable an Integrated Test, Evaluation and Acceptance Plan (ITEAP) to be drawn 

up. The acceptance procedure requires that requirements be subject to 

progressive acceptance throughout the phases of the project. This will raise 

confidence that the solution will meet the requirement, and provide results at the 

most appropriate time. 

Acceptance of complete capability goes beyond the Supplier’s remit, and certifies 

that the IPT has met its obligations under the CSA (Customer Supplier 

Agreement). The IPT does not have control over all elements of the capability 

(notably the human components) but has a responsibility to work with the PPO 

and Operational Command to ensure that the capability is provided. This is a 

less clear division of responsibility. The declaration of an In-Service Date (ISD) is 

the final and most important integration between the equipment and the human 

component and evidence for this stage of acceptance is critical. It must verify 

that the capability specified in the URD has been met, and that the IPT’s 

obligation is discharged. 

Acceptance ‘Stage’ 

1. User and System 

Requirement 

2. Design 

Certification 

Description 

Acceptance occurs when end users and stakeholders 

endorse these requirements and the acceptance 

criteria. 

Agreed by the IPT Leader. 

3. Initial Acceptance This takes place where Service use is required before 

System Acceptance is achievable. 



Acceptance ‘Stage’ 

4. System 

Acceptance 

Description 

System Acceptance assesses whether the system 

acquired by the IPT satisfies the SRD as assessed by 

the DEC. 

5. In-Service Date In-Service Date is declared when the military capability 

provided by the system is assessed as available for 

operational use. In-Service Date acceptance requires 

that there is a usable quantity of the system integrated 

with all essential supporting elements declared by the 

DEC. The Acquisition Handbook does not define a 

formal ‘acceptance’ process, but just the ‘declaration of 

In Service Date (ISD)’. 

Table 3-4: Acceptance Stages in the Procurement Process 

3.3.2 HFI Activities in Acceptance 

Human Factors Integration (HFI) testing includes formal acceptance activities, but 

also includes all forms of HFI assessment conducted against requirements at all 

phases of procurement. Three factors necessitate that HF characteristics are 

included as part of the acceptance testing process in procurement: 

• The integration of the user with the equipment or platform is a major 

influence in the achievement of required levels of performance. 

• Pressures to reduce the whole-life costs of manpower needed to effectively 

operate complex systems, both through optimisation of manpower and the 

reduction of training costs. 

• The requirement to prove that the health and safety risks of the system are 

As Low As Is Reasonably Practicable (ALARP). 

HFI input is required at an early stage. In many projects, HFI input to the ITEAP 

is necessary to detail the types of Human Factors analysis, trials, testing and 

acceptance criteria required ensuring that the user requirements are met. In 

addition, HFI input to Stage 1 of the Acceptance process (above) is enabled via 

HFI mechanisms such as HFI Working Groups, HF analyses and initial user 

testing with mock-ups and early prototypes. HFI input to user trials to support 

System Acceptance is usually required. 

HFI Assessments are evaluations of the design, or components thereof. HFI 

assessments are conducted throughout each procurement phase to generate 

and assess HFI criteria for an acceptable design. HFI requirements as defined in 

the URD and SRD are therefore subject to assessments throughout the 

procurement process and lead up to final acceptance procedures during the 

Trials and Acceptance stage. HFI Assessments may be used both to support the 

design process and evaluate one or more design alternatives. 

HFI Acceptance tests are generally defined as contributing directly to the 

completion of the Acceptance Questionnaire used to ensure that the customer 

requirement can be satisfied. 



Formal acceptance generally takes place during the Trials and Acceptance stage 

although some aspects may occur at earlier stages of procurement. This is 

particularly important for General Arrangement and layout aspects within the HFI 

Technical Areas. HFI activities should include progressive, continuing, audit 

leading towards final acceptance. 

3.3.3 Monitoring HFI Assessment & Acceptance Performance 

3.3.3.1 HFI Focus Responsibilities 

The HFI Focus is responsible for ensuring that the HF characteristics of systems 

meet the requirements stated in the URD and SRD. In addition, the HFI Focus 

monitors and evaluates the implementation of the HFI assessment and 

acceptance test programme. The HFI assessments will form part of the Human 

Factors Integration Plan (HFIP). The HF characteristics of the system must be 

such that operational capability, supportability and safety objectives can be met. 

The HFI assessment and acceptance test programme is designed to ensure this 

is in fact achieved. 

The following are general responsibilities of the HFI Focus in managing the HFI 

Acceptance Process, see Table 3-5. For HFI Focus responsibilities in 

determining the adequacy and outputs of acceptance testing itself, see Table 3-6. 

HFI Focus Actions 

Ensure the Human Factors Acceptance Strategy is issued and agreed at the 

start of Demonstration phase. 

Ensure availability of adequate evidence to cover all HFI requirements. 

Work with acceptance authorities to clarify the scope of evidence required (test 

plans, test schedules, validation criteria). 

Work with developers to ensure HFI related test results are valid for 

acceptance. 

Work with trials authorities and the user community to ensure that context of 

use is adequately reflected in trials, generating evidence for acceptance. 

Work with developers to gain approval of aspects that can be ‘frozen’ once 

they have been proven to meet HFI requirements. 

Help resolve acceptance problems. 

Identify any trial or test constraints that could undermine the validity of HFI 

results. 

Seek acceptable alternative means of assessing the adequacy of the solutions. 

Identify early any risk of failing to meet HFI requirements in the URD and SRD. 

Ensure that the issues are addressed and resolved by appropriate parties. 



Provide access to suitable representative users to support HF acceptance. 

Prepare to declare ISD. 

Work with the providers of all components of the capability (equipment, 

personnel, training and operational procedures). 

Outputs 

The key output of (equipment) acceptance is the confirmation that the 

equipment supplied has the attributes specified in the SRD. This should 

enable it to integrate fully and safely with the human component. 

The key output of capability acceptance (needed to declare ISD) is evidence 

that all parts of the capability, human as well as equipment, do indeed work 

effectively together. 

Checklist 

Are all involved parties (acceptance authorities, Suppliers, customer 2, and 

other stakeholders) ‘signed up’ to the HFI acceptance strategy 

Will planned activities (Supplier, MoD and other stakeholders) generate 

evidence to cover all HFI requirements in the SRD (for equipment acceptance) 

and in the URD (for declaration of ISD) 

Tips 

Taking an active interest in the HFI acceptance process will help to gain 

commitment of other parties to make it work. 

Building early confidence of all parties in the HFI acceptance strategy, and the 

evaluation and testing that underlies it, will greatly simplify the process of final 

acceptance. 

Distinguish between the Supplier’s absolute obligations to meet the 

requirements of the SRD and his (shared) responsibility to help resolve any 

shortcomings to satisfy the overall requirements of the URD. This will help 

ensure that conflicts regarding responsibilities do not arise and that shared 

responsibilities are identified early. 

Table 3-5: HFI Focus Responsibilities – Acceptance Process 

3.3.3.2 Monitoring Acceptance Testing 

The following questions must be asked for each HFI requirement: 

• What assessment and acceptance tests are planned 

• When will the assessment and acceptance tests be performed 

• What form will the assessment and acceptance tests take 



• What resources will be required to perform assessment and acceptance 

tests 

• What impact will the results have on the system design or development 

• What information will the results provide about overall system operational 

capability, supportability or safety 

MAP-01-011 describes HFI activities to assess systems in each of the HFI 

Technical Areas (MAP-01-011 Chap 4 through Chap 17). 

During and following assessment and acceptance testing, the HFI Focus should 

perform the following, see Table 3-6. 

Assess HF aspects of evolving design. 

HFI Focus Actions 

Review prototypes, demonstrators, and partial items of equipment. 

Involve users in identifying human related issues and risks. 

Ensure evaluation will read across to intended operational equipment. 

Assess HF aspects of emergent equipment. 

Seek opportunities to gain extra value from equipment trials, by inclusion of 

explicit assessment or evaluation of human related aspects. 

Ensure Suppliers are clear where evidence adequate for acceptance has been 

or has not been demonstrated. 

Ensure that any deficiencies revealed by HF evaluation are tackled. 

Assess HF aspects of equipment in service. 

Undertake post-introduction HFI audit. 

Put in place feedback mechanisms. 

Conduct usage review when considering major upgrade. 

Outputs 

Early warning of any failure to meet HFI requirements in SRD or URD. 

Objective information to guide any necessary design interventions. 

Evidence to support HFI acceptance. 



Checklist 

Are early HFI evaluations planned to assess all currently identified human 

related risks 

Are the HFI evaluations producing useful, valid results 

Are all parties conducting the HFI evaluations in an open and constructive 

way 

Is maximum value being extracted from HFI evaluations, and are results being 

fed back to drive design of the equipment, training, operational procedures, 

support systems, etc 

Are the HFI evaluations being co-ordinated with other development and 

experimental work in a way that minimises overall cost and time to the project 

Tips 

Early evaluation should focus on finding out information and building 

confidence. 

Informal or semi formal evaluations that can be done cheaply, quickly and early 

are often much more effective than formal evaluation that requires more time 

and resources. A suitable, early evaluation will often uncover the great 

majority of human issues. 

Formal evaluation is usually necessary to gather evidence suitable for 

acceptance or design sign off. 

Operability tests must involve representative users. It is critical to allow 

adequate allowance for familiarisation and training on the new equipment 

before any data are gathered. 

Does any of the evidence generated have questionable validity 

Does any of the evidence that has been generated fail to support acceptance 

If so, are there plans to resolve the problems Any shortcomings identified in 

HFI acceptance will be easier to resolve if the evidence is clear, unbiased and 

well presented. 

Table 3-6: HFI Focus Responsibilities – Monitoring Acceptance 

3.3.4 Design of Assessment and Acceptance Testing 

Detailed specifications for the HFI tests to be performed are developed by the 

Supplier(s) and managed as part of the Human Factors Integration Plan (HFIP). 

HF Specialists should be involved in the design and evaluation of such 

assessments from the earliest stages of system development. 



The selection of HFI assessment and acceptance tests is driven by three needs: 

• To refine requirements for the system and to define performance criteria 

that are feasible. 

• To select between different design options. 

• To prove that a design solution meets its performance criteria. 

A test specification will typically include the following information: 

• Aim. 

• Design. 

• Conditions. 

• Measures. 

• Equipment and Resources. 

• User Representatives. 

• HFI Criteria. 

• Timescale and Dependencies. 

The HFI assessment and acceptance tests must address the following questions 

about the platform or equipment: 

• Evidence that HFI policy and standards for design have been properly 

applied. 

• Evidence of traceability of system design from the requirements 

• Qualitative – evidence that the HF characteristics are fit for purpose or 

health and safety risks are as low as is reasonably practicable. An 

example of this would be subjective feedback from users and maintainers. 

• Quantitative – measurable evidence that the HF characteristics meet 

criterion levels as described in HFI standards. For example, that the 

dimensions of equipment, levels of environmental factors such as noise 

and specified performance levels of workload with given manning levels 

are achieved. 

3.3.4.1 Use of Human Factors (HF) Characteristics and Criteria 

HF characteristics and criteria represent the human aspects of platform or 

equipment requirements, design options and the selected solution. The 

Technical Chapters in MAP-01-011 describe the HF characteristics and criteria 

relevant to different aspects of Sea Systems. 

It is not necessary to test all HFI aspects of the requirements or the design at 

each phase of procurement. Selection of HF characteristics to test and the type 

of test should be based on the relative importance of the related HFI issue for the 

success of the system, implications for whole-life costs, and the level of HFI risk. 



3.3.4.2 Types of HFI Assessment and Acceptance Tests 

Where HFI requirements are expressed in terms of conventionally testable 

equipment attributes (size, weight, brightness, etc.) based on well-proven 

standards or the result of prior trials, then their acceptance is no different from 

that of any other equipment attribute. Other HFI requirements (for operability, 

maintainability, trainability and supportability) cannot be expressed and tested in 

this simple way, but require direct evidence about how the equipment and users 

interact with each other. These requirements must be tested using people as 

‘test instruments’. Doing this reliably needs special procedures and techniques. 

In rough terms, the tests are outlined below in order of increasing cost. It is 

therefore good practice to ensure that those items that can be simply tested are 

appropriately specified to permit this. The available trials budget and time should 

not be used up performing operability trials to check well-proven details. 

Operability trials and task walk-throughs should be used for areas of uncertain 

task interaction, task complexity and overall integrated task performance. They 

should also be used to test issues such as performance degradation over 

extended periods and skill retention during periods of non-use, as appropriate. 

The HFI assessments used to evaluate specific HF characteristics in each HFI 

Technical Area are outlined in MAP-01-011. 

A range of HFI test types is available for use in evaluation. These test types are 

classified into the following broad categories: 

• Analytical Tests using informal or structured representation and analysis 

methods. 

• Modelling Tests using formal representation, numerical methods or 

synthetic representations. 

• Prototyping Tests using representative personnel with simulated equipment 

performing simulated tasks. 

• Equipment Tests using representative personnel with real equipment 

performing required tasks under simulated conditions. 

• Field Tests using operational personnel with real equipment performing 

real tasks under operational conditions. 

• Analytical Tests 

Analytical tests can be used at any phase of procurement. Analytical tests are 

most useful during the early stages of procurement when there is a lack of 

quantitative data. They are of particular use in identifying inconsistencies in 

requirements. Analytical tests also include the use of checklists, for example 

based on standards, and in this respect they are very cost effective. Examples of 

analytical tests include operability, habitability and health and safety checklists. 

• Modelling Tests 

Modelling tests are of most use during the earlier stages of procurement when 

they can be used to generate predictions in order to assess design options. 

Modelling includes mathematical models of behaviour, numerical estimation of 

manpower numbers required, and cost-effectiveness calculations for system 



options. Simulation-based design is another form of this type of test and has 

been used successfully to test new designs where they were impossible or 

prohibitively expensive to prototype. For example, in sea systems, it may be 

difficult to simulate sea-going operational conditions without the use of computer 

aids (models exist for evaluating the effects of high angles of heel or trim, 

significant motion, reduced visibility and high temperature on the human). 

Simulation-based design also permits testing much faster and earlier in the 

procurement process. 

However, these tests must be treated cautiously, and their limitations recognised. 

Modelling of human behaviour is perhaps most problematic. Simulations of 

human behaviour in complex systems are notoriously difficult to construct and 

are rarely validated. Modelling is useful in providing information about the range 

of factors that can affect behaviour. This is particularly true of multi-crew, multiequipment 

behaviour in complex scenarios. For example, timeline analysis (with 

a relatively simple task model) is useful in showing relative amounts of time 

available to conduct activities, access requirements for displays, effect of 

different user role allocations etc. Modelling can be employed to focus later 

design activities by identifying possible critical activities or situations, and by 

providing requirements and performance criteria for platform and equipment 

design. 

• Prototyping Tests 

Prototypes may be constructed from the earliest stage of procurement onwards 

but are most useful in assessing design options during the Demonstration phase. 

Prototype tests involve the trial of systems or system components using 

simulations of equipment and/or compartments. Simulations may vary in fidelity 

from paper-and-pencil representations to fully functioning parts of the equipment. 

Tests using prototypes may vary from informal assessment to empirical 

measurement of human performance. Prototypes are most useful as they lie at 

an intermediate stage between analytic test types or modelling and later 

equipment and field trials. For example, user problems predicted from an earlier 

task synthesis can be tested with different prototype equipment design 

alternatives to determine whether predicted problems actually occur and, if so, 

what can be done about them. Prototype testing may itself lead to further 

predictions about human and system performance when the equipment is 

integrated. Prototype tests may therefore provide new estimates of performance 

criteria. 

• Equipment Tests 

Equipment tests can only start from the Manufacture phase onwards unless 

significant Commercial-off-the-Shelf (COTS) components are available. 

Equipment tests are generally conducted for Factory Acceptance Testing (FAT) 

purposes. Equipment tests are oriented towards assessments of achievement of 

performance criteria developed over the procurement. Compliance with 

functional and non-functional requirements is also assessed. A mixture of 

empirical measurement and subjective assessment using structured scales is 

recommended. 

• Field Tests 

Field tests are defined as requiring the integration of the equipment into its 

operational context and its use by the actual population of users. Field tests can 

be applied during the Manufacture and In-service (post-design support) phases 



and may be conducted in on-shore facilities or at sea. Field tests typically 

incorporate several test subjects at once and may require more use of subjective 

assessment where specialised performance recording is unavailable or 

impractical. Field tests address the ultimate performance criteria, as well as 

functional and non-functional compliance, when personnel, equipment, and 

environment are combined. 



CHAPTER 4 – THE HUMAN FACTORS INTEGRATION PLAN (HFIP) 

CONTENTS 

4.1 The Purpose of the HFIP .............................................................................................4-3 

4.2 The Structure of the HFIP...................................................................................4-3 

4.3 Multiple HFIPs ....................................................................................................4-4 

4.4 Evolution of the HFIP in Procurement ................................................................4-4 

4.5 Content of the HFIP ............................................................................................4-5 

4.5.1 HF Issues..............................................................................................4-5 

4.5.2 HF Risks ...............................................................................................4-6 

4.5.3 HF Constraints......................................................................................4-6 

4.5.4 HFI Activities to Address HF Issues and Risks.....................................4-6 

4.5.5 Allocation of HFI Activities ....................................................................4-7 

4.5.6 Dependencies affecting HFI Activities ..................................................4-7 

4.5.7 Integration of HF Data with CALS.........................................................4-7 

4.5.8 Integration of HFIP into TLMP ..............................................................4-8 

4.5.9 User Participation..................................................................................4-8 

4.5.10 HFI Deliverables ...................................................................................4-9 

4.5.11 Using HFI in Trade-Offs........................................................................4-9 

4.5.12 Monitoring and Controlling HFI Activities ..............................................4-9 

4.5.13 HFIP Contents List................................................................................4-9 





Chapter 4 – The Human Factors Integration plan (HFIP) 

4.1 The Purpose of the HFIP 

A Human Factors Integration Plan (HFIP) is required from the outset of a project, 

updated at each procurement phase. The purposes of the plan are: 

• Review HFI issues and risks (raised by Early Human Factors Analysis 

(EHFA), see Chapter 3). 

• Agree Human Factors Integration (HFI) priorities for the current phase. 

• Establish long-term HFI strategy (through assessment, demonstration, 

manufacture, in-service and disposal). 

• Co-ordinate with other specialist plans, and identify dependencies between 

organisations, and requirements for co-ordination (see Chapter 3). 

• Determine key milestones and time-scales (tied to the project plan). 

• Write HFIP for next phase. 

• Define complementary roles for MoD, its agents and Suppliers. 

• Specify how progress will be monitored and controlled. 

The HFIP is part of the overall Through-Life Management Plan (TLMP) specifying 

HFI activities, outputs and stakeholders. Associated with the HFIP is the Human 

Factors Integration Log (HFIL), discussed in Chapter 3, which maintains a record 

of Human Factors (HF) data and decisions and which tracks progress on the 

activities associated with issues and risks identified in the HF Issues Register. 

4.2 The Structure of the HFIP 

The plan should contain the following items: 

• HF issues and risks to be addressed in the project. 

• HF constraints. 

• HFI activities (inc. studies, actions and mitigation strategy) to address each 

issue or risk. 

• Allocation of actions in HFIP to MoD or Industry. 

• Dependencies between organisations and project activities, including 

Safety, ILS etc., in conduct of HFI activities. For information on 

co-ordination between relevant stakeholders and the HFI mechanisms by 

which this is achieved, see Chapter 2 and 3. 

• Strategy for integrating Human Factors (HF) data collection with 

Continuous Acquisition and Life-Cycle Support (CALS). 

• Key milestones and timescales in accord with the Through-Life 

Management Plan (TLMP). 



• Extent of need for end user participation. 

• HFI deliverables. 

• Method for including HFI in system level trade-offs. 

• Methods for monitoring and controlling progress against the plan. 

4.3 Multiple HFIPs 

In a project of significant size or complexity, and in cases where a number of 

system and equipment providers are involved, there may be a need to have a 

number of HFIPs, each dedicated to a particular area of the Works or contract 

area. In such cases, there will be a need to produce an overarching HFIP to act 

as a 'plan of plans'. The overarching HFIP should provide links to the subordinate 

HFIPs and should document all cascaded technical and management 

responsibility definitions. In particular, responsibilities for ownership of HFI 

issues should be made explicit, at an appropriate level of detail and resolution. 

4.4 Evolution of the HFIP in Procurement 

The production of the HFIP and the collection of data occur in each procurement 

phase of a project. Thus an HFIP is generated for the Concept, Assessment, 

Demonstration, Manufacture and In-Service phases, see Figure 4-1. 

HFI Plan HFI Plan HFI Plan HFI Plan HFI Plan 

Concept Assessment Demonstration Manufacture In-Service Disposal 

URD 

SRD 

Figure 4-1: HFIP Iterations 

At any stage the IPT Leader/HFI Focus may decide to include a skeleton HFIP in 

the ITT. This may be generated within the MoD or be developed by the Supplier 

at a previous procurement phase. Each potential Supplier is required to produce 

an outline HFIP as part of the tender response. The IPT’s skeleton HFIP 

therefore serves as guidance to the Supplier / Prime Contracting Organisation 

(PCO) regarding the HFI approach, issues and activities that must be addressed. 

The Supplier’s or PCO’s outline HFIP must adequately reflect the IPT’s HFIP, 

ensuring that the Human Factors (HF) requirements are addressed in the most 

suitable manner. 

At a minimum (for comparison, see Section 4.2), the outline HFIP in the tender 

response should address the Supplier’s approach to the following: 

• HF issues and risks to be addressed in the project. 



• HFI activities (inc. studies, actions and mitigation strategy) to address each 

issue or risk. 

• Allocation of actions in HFIP to MoD or Industry. 

• Key milestones and timescales in accord with the TLMP. 

• Extent of need for end user participation. 

• HFI deliverables. 

• Method for including HFI in system level trade-offs. 

On selection of the Supplier(s) for a particular procurement phase the Supplier’s 

outline HFIP(s) is detailed and implemented. As part of the project deliverables a 

skeleton HFIP may be required from the Supplier for use in subsequent phases 

of procurement. 

The activities and outputs controlled by the HFIP contribute information or data 

for use in the project. It is vital that HF Data is maintained for use across the 

whole procurement life cycle. The Supplier is responsible for the collation and 

delivery of the data produced during a project. The HFI Focus is responsible for 

monitoring the content and format of the data to ensure that it contributes to 

specific project requirements and overall programme objectives, particularly with 

respect to the requirements of the SRD. An index to the HF Data and a record of 

decisions is maintained, usually by the Supplier, in the Human Factors 

Integration Log (HFIL), see Chapter 3. 

At each phase in the procurement process the ITT requires that an outline HFIP 

be developed by industry for assessment by MoD. At each phase of 

procurement, data is developed as a result of the activities required by the HFIP 

for that phase and recorded in the HFIL. 

4.5 Content of the HFIP 

The HFI Focus is responsible for ensuring that the HFIP is developed, 

maintained and followed by the Supplier. The following sections provide 

guidance for the HFI Focus about the content of the HFIP. 

4.5.1 HF Issues 

The HFIP must clearly describe each of the issues that are to be addressed. 

Chapter 1 provides an overview of issues related to Manpower, Personnel, 

Training, Human Factors Engineering, System Safety, Health Hazard 

Assessment, etc for platforms and equipment. MAP-01-011 describes the types 

of technical issues that typically arise in each HFI Technical Area. 

The results of the Early Human Factors Analysis (EHFA) will indicate the initial 

issues and risks that need to be addressed in the HFI Programme. These issues 

and risks should have been captured in the Human Factors Integration Log 

(HFIL), see Chapter 3. MAP-01-011 is used to help the HFI Focus to understand 

the implications of these for the procurement strategy. MAP-01-011 is also used 

to ensure that all technical issues are covered for the platform and equipment. 



4.5.2 HF Risks 

Current HF issues (as in the HFIL) for which risk management activities are 

required are described in the HFIP. For more information on HF issues and risks, 

see Chapter 3. 

The EHFA and subsequent activities will indicate risks that should be entered into 

the HF Issues Register (and also fed into the Project Risk and Issues Register). 

HF risks should be expressed in the same way as other types of risk. Probability 

and impact (on the operational capability, supportability, health and safety, and 

the project itself) should be expressed for each risk. 

As stated in Chapter 3, the HF risks to be addressed in a project fall into four 

broad categories: 

1. Failure to meet the full operational requirement, e.g. operator workload in 

projected scenarios limits overall response times to threats. 

2. Failure to produce a supportable system within the costs and resources 

available, e.g. skill and knowledge required to operate new equipment 

exceeds that planned in current manpower and training policy. 

3. Failure to meet health and safety requirements, e.g. excessive heat in 

operational compartments in particular climates. 

4. Failure to complete the project within cost and time, e.g. equipment user 

interface design is found to be unusable during Trials and Acceptance and 

requires significant redesign. 

4.5.3 HF Constraints 

HF constraints act to limit the degrees of freedom of the design and may require 

study during the project. Such constraints may be indicated in the EHFA, appear 

as requirements or become apparent during the course of the project. Examples 

of HF constraints include the following: 

• Manning levels are capped. 

• Skill and knowledge requirements are not to exceed those currently 

available. 

• Training capacity is fixed. 

The HFIP lists all constraints and indicates how they will be dealt with during the 

project. 

4.5.4 HFI Activities to Address HF Issues and Risks 

The HFIP addresses each issue and risk, taking account of the constraints that 

have been identified. 

The HFI Technical Areas described in MAP-01-011 provide detailed guidance 

about how issues can be addressed for a platform or equipment. The technical 

issues that typically need to be considered in each procurement phase are 

described for each HFI Technical Area. 



For example, ‘Manpower, Complementing and Accommodation’ forms one of the 

Platform HFI Technical Areas (see MAP-01-011 Chap 4). This HFI Technical 

Area covers HF issues concerned with estimating complement size and 

accommodation capacity. A process for addressing complement size and 

accommodation needs is provided for use during the Concept, Assessment, 

Demonstration and Manufacture and In-Service phases of procurement. 

The checklists in MAP-01-011 Chap 2 summarise the HFI activities and outputs 

that are required at each phase of procurement. 

4.5.5 Allocation of HFI Activities 

The HFIP indicates to whom HFI activities and responsibilities are allocated. The 

plan must make clear how the involvement of participants will be managed. This 

aspect of the HFIP may need to be split between Defence Procurement Agency 

(DPA) / Defence Logistics Organisation (DLO) and the Supplier depending on the 

responsibility of each. For example, the HFI Focus may require the involvement 

of HF Specialists from outside the Supplier’s team to conduct HFI quality 

assurance. Liaison with other MoD Authorities will be required. The Supplier is 

expected to detail the allocation of HFI activities within its internal project team 

organisation and list any dependencies on external organisations. 

Chapter 3 provides guidance about project organisation and MAP-01-011 details 

the likely involvement of stakeholders during the conduct of an HFI Programme. 

4.5.6 Dependencies affecting HFI Activities 

The HFIP indicates all dependencies affecting the conduct of activities. 

Chapter 1 describes dependencies between HFI Programmes for Whole Ship coordination. 

MAP-01-011 provides more detail with regard to the specific 

dependencies associated with HFI activities. The following general types of 

dependency should be included in the HFIP: 

• Input from MoD specialist authorities. 

• Input from other procurement projects. 

• Access to user representatives. 

• Access to vessels or other units to collect field data. 

• Dependencies within the TLMP between the HFIP and other plans, e.g. the 

Integrated Logistics Support Plan (ILSP), the Project Safety Management 

Plan (PSMP). 

4.5.7 Integration of HF Data with CALS 

The HFIP must provide proposals for the integration of Human Factors (HF) data 

and products with the MoD Continuous Acquisition and Life-cycle Support 

(CALS) policy for the platform or equipment. 



4.5.8 Integration of HFIP into TLMP 

The HFIP must be fully integrated into the TLMP in the following respects: 

• The work breakdown structure (WBS) of the HFIP will be detailed in 

relation to the WBS for the complete TLMP. 

• The HFIP will indicate the HFI team organisation and its place in the 

project management organisation. 

• HFI activities and milestones will appear in the TLMP in the form of the 

Gantt chart, PERT chart etc. used for the project. 

• HFI resources will form part of the overall project resource plan. 

• HFI progress reviews will be incorporated into the overall project review 

plan. 

• Configuration control over documentation and Human Factors (HF) data 

will form part of overall project Configuration Control standards. 

• Quality assurance of HFI management, activities and deliverables will form 

part of the overall project Quality Assurance Plan. 

4.5.9 User Participation 

The HFIP details how, when and how many user representatives are involved in 

the project. 

MAP-01-011 details the HFI activities for which user involvement is required at 

different phases of the procurement. The level of user involvement depends on 

the information needed to perform HFI activities. Some general examples are 

provided below: 

• Surveys can provide information about users and other characteristics for 

the Project Specific Target Audience Description (PSTAD), e.g. level of 

skill and knowledge in the use of computers. 

• Current task, job and organisational descriptions can be obtained by 

interview of subject matter experts. 

• Future task, job and organisational design can be assessed by structured 

walk-throughs with subject matter experts. 

• Users and maintainers can assess platform compartment and other 

layouts, represented in plans, computer-generated designs and full-scale 

mock-ups. 

• Instructors can contribute to Training Needs Analysis (TNA) and the 

evaluation of training options and equipment. 

• Human-equipment interface design can be assessed using user opinion of 

mock-ups or user interaction with prototypes. 

• Trials in which users operate under limited scenarios can provide estimates 

of human performance. 



• HFI assessment and acceptance tests require the involvement of 

representative users. 

Service Level Agreements may be required in order to enable user participation. 

4.5.10 HFI Deliverables 

The HFIP provides details of all the HFI deliverables to be provided. 

MAP-01-011 describes the outputs generated by HFI activities (a summary is 

provided in MAP-01-011 Chap 2). The following general types of HFI 

deliverables may be provided: 

• HFI reports and documentation, e.g. description of future team 

organisation. 

• Stand-alone Human Factors (HF) data, e.g. task analysis database. 

• Integrated data, e.g. HF characteristics and criteria are consolidated into 

the project requirements. 

• HFI design products, e.g. compartment layouts, human-computer interface 

design. 

• HFI project guidelines, e.g. health and safety checklist, HF Style Guide, 

user documentation standard. 

HFI deliverables must meet stated quality criteria for Human Factors products, 

provide outputs, which help to specify product design, and address practical 

questions about performance, supportability and acceptability. 

4.5.11 Using HFI in Trade-Offs 

The HFIP describes the use of HFI in performing system and design trade-offs. 

Chapter 1 of this guide describes HFI trade-offs at the total system level. MAP- 

01-011 provides detailed guidance about the types of trade-offs conducted during 

the design process. 

4.5.12 Monitoring and Controlling HFI Activities 

The HFIP details how HFI activities are monitored and controlled. This includes 

proposed HFI project reviews, progress reports, design reviews and 

presentations, demonstrations, test and evaluation reports. For information on 

the management and control of requirements, issues, project management and 

project acceptance, see Chapter 3. 

4.5.13 HFIP Contents List 

Currently, there is no mandatory list of HFIP contents in any HF standard. Whilst 

this chapter gives guidance on the nature and extent of contents, the actual HFIP 

structure and content need to be agreed by the IPT and the Suppliers. 



The following is an indicative list of typical HFIP contents. This list is by no means 

definitive: 

• Human Factors Organisation/Organisational Context 

• Human Factors team, management and interfaces. 

• Previous relevant experience. 

• Understanding of the Requirements 

• Background. 

• Key Human Factors issues. 

• HFI Design Process. 

• Human Factors Activities 

• Systems Requirements Analysis. 

o Definition of Target Audience Description. 

o Definition and analysis of Operational Scenarios. 

o Concept of Operations and Interoperability considerations. 

o Systems requirements derivation and capture. 

o 

o 

o 

Function analysis. 

Allocation of functions. 

Task analysis. 

o Human performance analysis. 

o Information requirements analysis. 

o 

o 

Workload analysis. 

Workspace requirements analysis. 

o HCI/Controls requirements analysis. 

o Environmental and Safety analysis. 

o Maintenance requirements definition. 

o Others as relevant (see MAP-01-011 for technical areas and HFI 

activities). 

• System Design 

o 

o 

Design documents. 

Design rationale. 



o Prototyping and simulation. 

o 

Standards application. 

o HMI/HCI Design specifications. 

• Development of System Operating Procedures 

• Development of Operator Training 

• Human Engineering Test and Evaluation 

o Prototyping and simulation activities. 

o HF assessment techniques. 

o HFI contribution to ITEAP. 

• Technical Management 

• Programme plan. 

• Integration with (non-HF) project activities/dependencies. 

• Working Groups. 

• Maintenance of the Human Factors Integration Log (HFIL). 

• Visits. 

• Deliverables. 

• Meetings and design reviews. 

• Risk management (HF Issues Register and integration with project Risk 

Register). 

• Quality Assurance. 

• Design approval. 

• Design traceability. 

• Acronyms and abbreviations 

• Glossary of terms 

• Applicable standards 

• References 

• Compliancy Table 

• Quality Plan 






ANNEX 1 – GLOSSARY 

CONTENTS 

A1 Glossary.................................................................................................................... A1-3 

Nov 2006 Page A1-1 Issue 4




Annex 1 – Glossary 

A1 

Glossary 

Acceptance Test A working test of equipment/platform effectiveness, 

performance, reliability or other factors for the purpose of checking against 

contract requirements and/or suitability for Naval service. 

Accommodation Statement The number of bunks that are required on the 

platform for the crew and the margins. 

ADQUAL ‘Additional Qualification’ assigned to a billet in the Scheme of 

Complement. 

Anthropometrics The measurement of the physical characteristics of human 

beings. It includes static and functional (dynamic) measurements of dimensions 

and physical characteristics of the body as they occupy space, move and apply 

energy to physical objects. 

Aptitude A user's ability to undertake a specific task effectively. 

Basic Manning Requirement An initial estimate of the quantity of ranks/rates of 

manpower required to operate a system. This will be refined and developed 

through iterations of Draft Quarter Bills to derive a Scheme of Complement. 

Built-in Test Equipment Maintenance facilities to assist diagnosis of errors 

within a software-based equipment. Hence they are typically built in as part of the 

software design and implementation. 

Capability The fitness to perform some aspect of a naval operation. 

Cognition A general term covering all the various modes of thinking – 

perceiving, remembering, imagining, conceiving, judging and reasoning. 

Cognitive Tasks Tasks that impose their major workload on the user's 

cognition. 

Comfort Zone An environmentally defined zone that specifies comfort in terms 

of a range of physical and social habitability factors. 

Combined Operational Effectiveness and Investment Appraisal The use of 

operational analysis and through-life costing to determine the operational worth 

of a system and to identify the optimal technical option for subsequent 

procurement action. 

Command Structure The organisation of members of the Command team as 

required for each type of mission or state. 

Command Team Training Training to ensure that each individual knows his or 

her roles and duties within the Command team, so that the execution of tasks 

achieves effective mission accomplishment. 

Command (The) The top level of naval human control for any Sea System, 

which decides the course of action to be taken to achieve the mission. 

Complementing The objective process of determining that a task exists and 

allocating the least manpower at the lowest skill level to perform that task. 



Computer-Based Learning Learning acquired from the use of computer-based 

training. 

Computer-Based Training A form of training implemented upon computerbased 

equipment where the training material is provided using a combination of 

software and hardware. 

Continuation Training On-board and Shore-based training used to reinforce 

and extend the user’s skills on a specific set of tasks. 

Embedded Training Training provided through the use of the operational 

equipment and allied hardware and software. This enables training to be brought 

to the user at the place of work. 

Environment The physical characteristics of a workspace, e.g. heat, light, noise. 

These may degrade task performance or be detrimental to health and safety if 

not maintained within acceptable limits. 

Equipment The Combat System and the marine engineering items that provide 

the functions required to move, fight and provide life-support on a platform and 

any related items, which may be located at shore-based units. 

Federated Training Training on a group of equipments, which serves to bring 

together a team or sub-team of users and their equipments into a common 

training process at their place of work. 

Function A goal-defined service or facility required of a system if it is to enable 

mission requirements to be achieved. 

Graphical User Interface A human-computer interface based on the use of 

windows, icons, pull-down menus and a pointing device. 

Gross Motor Tasks Tasks that place a high load on the musculoskeletal 

systems without requiring fine control. 

Habitability Suitability of an environment to be lived in. Accommodation is a 

subset of this parameter. 

Human-Computer Interaction The method of communication and sequence of 

activities that characterises how a user works with a computer-based system. 

Human-Computer Interface The displays and controls used to communicate 

with computer-based equipment. 

Human Factors Integration (HFI) An approach to Human Factors that ensures: 

• The integration of people and technical systems. 

• The integration of different HF domains (Manpower, Training, etc) within one 

framework. 

• The integration of HF within the system acquisition process. 

Human Factors Integration Log (HFIL) A record of the products of Human 

Factors work conducted under an HFI Plan including an audit trail of related 

decisions. 



Human Factors Integration Plan (HFIP) Documentation providing a plan for 

future HFI activities. HFI Plans are produced by the DPA / SSA for in-house use 

and for contract placement, and by Suppliers when preparing tenders and 

performing work programmes. 

Human Factors Requirements These state what the user requires the system 

to do (functional requirements), how well it must do it (performance requirements) 

and how the user interfaces with the equipment to carry out tasks effectively and 

efficiently (non-functional requirements). 

Human Performance Behaviours and actions performed by personnel in the 

course of completing a task. 

Interoperability The extent to which common operability characteristics are 

shared across equipments. 

Job A set of duties allotted to an individual, defined in terms of its constituent 

roles. 

Maintainer The role responsible for checking, diagnosing faults, servicing and 

fixing operating problems with equipment. 

Man-Machine Interface The medium through which the humans in a system 

communicate with the equipment. 

Manning The process of identifying tasks to operate equipment, and 

determining the number of users needed to meet the task requirements. 

Measures of Effectiveness (MOEs) Quantitative measures that give some 

insight into how effectively an entity is performing. 

Mission A high-level operational goal to be achieved by the system. 

Mission Critical A qualifier applied to a human task or machine function where 

sub-optimal or poor performance can result in mission failure. 

On-board Training Training that is conducted by the vessel’s complement whilst 

embarked to maintain an acceptable level of performance. 

On-the-job Training The training required at sea to raise the trainee from the 

training standard to the operational standard of performance. 

Operability The extent to which an equipment's MMI/HCI provides an effective 

means of communication between the equipment and its intended users in 

support of their tasks. 

Operational Performance Statement A statement in the form of operational 

duties and tasks providing the top-level summary of a job. Training categories 

are also shown to provide a prediction of required on-job training. The OPS is a 

fundamental part of the RN training system, it gives job focus to training 

designers and is used to present a summary of the job analysis to the customer 

for ratification. 

Operator A role responsible for operating the equipment. Dual roles may also 

exist where the operator role is combined in a job with the role of the maintainer. 



Percentile A metric for denoting the proportion of the user population that 

shares a specified characteristic. In general, n percent of the population have a 

smaller characteristic than the nth percentile. Typically used for anthropometric 

data. 

Perceptual Tasks Tasks that impose their major workload on the human 

sensory system, e.g. vision, hearing. 

Platform The mechanical structure upon which all the equipments and users are 

located in order to carry out their operational mission. 

Pre-Joining Training Pre-Joining Training (PJT) provides training specific to a 

particular vessel prior to a user’s employment on that vessel. On completion of 

PJT a user is expected to be capable of carrying out duties safely and effectively. 

Procedural Tasks Tasks undertaken in predetermined or defined sequences. 

Psychomotor Tasks Tasks that impose their major workload on human motor 

or output systems, e.g. tracking, moving input devices. 

Quarter Bill The basic working document for the design of the Scheme of 

Complement for a new class of vessel. 

Repetitive Strain Injury (RSI) A symptom of the effect of small, repetitive 

movements, e.g. key presses on a keyboard, whereby the tendons and tendon 

sheaths become inflamed and painful. Particularly found in the fingers and 

hands. This is a particular type of upper limb disorder. 

Requirements Analysis The process of establishing comprehensive, coherent 

and logical statements of the functions required in a system to fulfil missions. 

Risk Analysis The quantification, in probabilistic terms, of the mission, technical 

and human risks associated with design options. 

Role A subset of a job defined by a range of tasks that can be allocated to an 

individual. 

Scheme of Complement The document which specifies the categories, roles 

and numbers of personnel required by rank/rate, Branch, PJT and ADQUAL. 

The sole authority for drafting and appointing of personnel to a unit. Produced by 

FLEET-NPS. 

Sea System The combination of platform and/or equipment and manpower to 

meet a maritime operational requirement. 

Shore-based Training Training that is conducted by naval personnel at a shorebased 

establishment. 

Simulation Based Design A design technique that utilises a simulation within 

which the designer has the illusion of being in a three-dimensional world. It is 

created by the use of a computer simulation and appropriate input and output 

devices. An extension of Virtual Reality to include accurate design data and 

analysis, and the ability to assess human interaction with a design. 

Skill The capability of the human to take in information (perception), process it 

(cognition) and take some resulting physical response (motor action) in an 

appropriate manner to achieve a goal. 



Staff Requirement A detailed statement describing the function and 

performance in operational terms of a proposed new equipment and the 

environment in which it is to operate. The statement must differentiate between 

essential and desirable features. The required in-service date must also be 

stated. A Staff Requirement for Sea Systems (SR(S)) is the responsibility of DEC 

following endorsement by central committees. This information is still relevant for 

legacy projects, although the Staff Requirement and Staff Target have, as a 

result of Smart Acquisition, been replaced by the URD and the SRD. 

Staff Target A concise statement expressing in broad terms the functions and 

desired performance of a new weapon or equipment before the feasibility or 

method of meeting the requirement or other implications have been fully 

assessed. It should be confined to stating problems and objectives without 

stipulation of solutions. A Staff Target for Sea Systems (ST(S)) is developed by 

DEC to meet an operational need. This information is still relevant for legacy 

projects, although the Staff Requirement and Staff Target have, as a result of 

Smart Acquisition, been replaced by the URD and the SRD 

Subject Matter Expert A person with specialist, in-depth knowledge of the 

current system or the system being designed. 

Task A task is a collection of human activities expressed in the form of a 

process with a goal. Tasks may be combined to create roles. 

Team A group of roles undertaken by several personnel to achieve a common 

goal or set of goals. 

Training Needs Analysis Qualitative and quantitative techniques to identify the 

most important performance gaps which can be addressed via training. 

Importantly, this analysis can also show the gaps that should be addressed by 

interventions other than training (i.e., those which are not due to knowledge or 

skills deficiencies). 

Training Performance Statement A statement in the form of a list of Training 

Objectives which describe the end product of a training event. 

Training Requirements The training necessary to teach users the skills 

required to use a system. 

Usability A measure of the ease and comfort with which a system can be 

learned or used. This may include aspects of safety, effectiveness and efficiency 

and the attitude of users towards the equipment. 

User A user is anyone that comes into contact with the system, including 

operators, maintainers, and trainers throughout the system's life-cycle. 

User Population The population identified as being most representative of 

existing or future users. 

Vessel A warship or submarine comprising a platform and equipment. 

Whole Ship Approach See Whole Ship HFI Co-ordination. 

Whole Ship HFI Co-ordination The harmonisation of Human Factors issues 

and risks when integrating equipment on to a platform. This may require sharing 

of HFI data across different procurement programmes and also includes 

consideration of the effects of adding new equipment to existing vessels. 



Workload The mental and/or physical demands placed on a user by the task 

requirements, the workplace and environment (including the organisation). 

Workspace The location and layout of space and objects in a vessel within 

which a user performs tasks. 

Workstation A functionally related group of equipments in one location at which 

a user performs tasks making use of the MMI/HCI. 

Nov 2006 Page A1-8 Issue 4 

MAP-01-010 Annex 1_07.doc

ANNEX 2 – CONTACT DETAILS 

CONTENTS 

A2 Contact Details.......................................................................................................... A2-3 





Annex 2 – Contact Details 

A2 

Contact Details 

Name Contact Details Specialist Area 

TES-ASG – Air Systems 

Group 

Ash 3 # 3311 

MoD Abbey Wood 

Bristol 

BS34 8JH 

Tel: 

E-mail: 

British Psychological 

Society 

(for the BPS Register of 

Chartered Psychologists) 

The British Psychological Society 

St Andrews House 

48 Princess Road East 

Leicester 

LE1 7DR 

Tel: 0116 254 9568 

Fax: 0116 247 0787 

E-Mail: enquiry@bps.org.uk 

BSI – British Standards 

Institute 

389 Chiswick High Road 

London 

W4 4AL 

DCDS(Pers)-Strat-DD 

(VCDS; DCDS(Personnel)) 

DEC – Directorate of 

Equipment Capability 

Tel: 020 8996 9000 

Fax: 020 8996 7001 

E-mail: cservices@bsi-global.com 

7/N/14, MoD Main Building, 

Horse Guards Avenue, 

Whitehall, London 

SW1A 2HB 

Tel: 020 7218 6796 

Fax: 020 7218 2176 

E-mail: 

MoD Main Building, 

Whitehall, 

London 

SW1A 2HB 

Tel: 020 7218 6055 

Fax: 020 7218 7335 

E-mail: 

Service Personnel 

Policy, PCOC. 

Requirements (incl 

HFI) for RN platforms 

and equipment. 




FLEET-NPS (Naval 

Personnel Strategy) 

Fleet NLM (Naval Life 

Management) 

Fleet - NTE – Naval 

Training and Education 

Dstl – Defence Sciences 

and Technology Laboratory 

Dstl – CBS – Chemical 

Biological Sciences 

Mail Point 3.1 

Leach Building 

Whale Island 

PORTSMOUTH 

PO2 8BY 

Tel: 02392 625526 

E-mail: 



Whale Island 

PORTSMOUTH 

PO2 8BY 

Tel: 02392 722351 

E-mail: 



Whale Island 

PORTSMOUTH 

PO2 8BY 

Tel: 

E-mail 

Human Sciences Team 

Room G007 

Building A2 

DSTL 

Ively Road 

Farnborough 

Hampshire 

GU14 0LX 

Tel: 01252 45 (extensions: 

5784; 5779; 5786; 5781) 

Fax: 01252 455073 

E-mail: 

Porton Down 

Salisbury 

Wiltshire 

SP4 0JQ 

Tel: 01980 61+extn 

E-mail: 

Sea Complementer: 

current and future 

Ships, Submarines, Air 

Squadrons. 

Production of 

Schemes of 

Complement and 

Quarter Bills. 

Conditions of Service. 

Policy on welfare and 

accommodation 

standards. 

HFI research and 

development in 


Engineering, 

personnel selection 

and training; HFI 

project support. 




EC AWE-FSC – EC Above 

Water Effect (VCDS; 

DCDS(Equipment 

Capability); EC Capability 

Manager Precision Attack) 

EC SEC-Dev(CaP Mgt) 

(VCDS; DCDS(Equipment 

Capability); EC 

DG(Equipment); EC 

Secretariat; Dev(CaP Mgt)) 

EENA- Escape and 

Evacuation Naval Authority 

Ergonomics Society 

(for list of ES Registered 

Ergonomists and 

Consultancies) 

FOTR – Flag Officer 

Training & Recruitment 

2/M/13, MoD Main Building, 


Whitehall, London 

SW1A 2HB 

Tel: 020 7218 2416 

Fax: 020 7218 7474 

E-mail: 

2/F/54, Main Building, 


Whitehall, London, SW1A 2HB 

Tel: 020 780 70494 

Fax: 020 721 87858 

E-mail: 

ECSEC-DevCapMgt@a.dii.mod.uk 

Ash 3C, Mail Point 3311 

MoD Abbey Wood, 

BRISTOL 

BS34 8JH 



E-mail: 

TES-SSG- 

ShipDesEE@dpa.mod.uk 

The Ergonomics Society 

Elms Court, Elms Grove 

Loughborough 

Leicestershire 

LE11 1RG 

Tel: 01509 234904 

Fax: 01509 235666 

E-Mail: ergsoc@ergonomics.org.uk 

Website [Ref 26] 

Assistant Director Naval Training 


Victory Building 

HM Naval Base Portsmouth, 

Hampshire 

PO1 3LS 

Tel: 

E-mail: 

PCOC 

Issues ‘Certificate of 

Safety - Escape and 

Evacuation’. 


Integration (HFI) 

Experts 

Naval training policy 




TES-HFG – Human Factors 

Group 

Ash 3, Mail Point 3312 


BRISTOL 

BS34 8JH 


E-mail: tes-hfg-hd@dpa.mod.uk 

HFI advice, guidance 

and SRL and SSE 

assurance to IPTs in 

the Air and Land 

environments, see 

SSG for Maritime 

environments. 

IMO – International 

Maritime Organisation 

INM – Institute of Naval 

Medicine 

ISO – International 

Standards Organisation 

4 Albert Embankmant 

London 

SE1 7SR 

Tel: 020 7735 7611 

Fax: 020 7587 3210 

Website: www.imo.org 

Crescent Road 

Alverstoke 

Gosport 

Hampshire 

PO12 2DL 

Tel: 02392 768056 

E-mail: 

Via Website: www.iso.ch 

HFI research & 

development in 

environmental 

ergonomics, health 

and anthropometrics of 

RN personnel; HFI 

project support; 

Psychological 

Technique Research. 

MLS IPT Mailpoint 4116 

MoD Abbey Wood 

Bristol 

BS34 8JH 

HF aspects of Marine 

Electrical Systems. 


E-mail: 

MoD-Industry Human 

Factors Working Group 

Contact: 

MDG(N) – Medical Director 

General (Naval) 

Victory Building, 

HM Naval Base Portsmouth, 

Hampshire 

PO1 3LS 

Tel: 02392 722351 

E-mail: 




NATO – North Atlantic 

Treaty Organisation 

NEHFILG – Naval 

Equipment Human Factors 

Integration Liaison Group 

PDG/STS – Standards 

Programme Management 

(DStan) 

PIC – HFI DTC Process 

Improvement Cell 

RAF – Royal Air Force 

Research Programme 

Leader - Human Sciences 

RT(RAO HS 1) 

Via Website: www.nato.int 

Via SSG 

Kentigern House, 

65 Brown Street, 

Glasgow, 

G2 8EX 



E-mail: 

Ash 3, O35, Mail Point 3312 


BRISTOL 

BS34 8JH 


E-mail: tes-hf-dtc1@dpa.mod.uk 

HQ Personnel & Training 

Command 

Building 255 

RAF Innsworth 

Gloucester 

GL3 1EZ 

Tel: 01452 712612 

E-mail: 

DG(R+T) 

Research Acquisition Organisation 

HF7/2 Hackett Building 

Defence Academy 

Shrivenham 

Swindon 

Wiltshire 

SN6 8JU 

Tel: 01793 314019(wk) or 

E-mail: rtraohs1@defence.mod.uk 

Group run by TES- 

SSG-ShipDes 

Defence Standards 

(DEF-STAN series) 

Knowledge transfer 

from HFI DTC to MOD 




RN ICG – RN Intelligent 

Customer Group 

(2SL/CNH; NRTA; Intelligent 

Customer Cell) formerly 

RNSETT 

Jervis Block South, 

HMS Nelson, 

Portsmouth, 

Hampshire 

PO1 3HH 

Tel: 02392 723843 

Fax: 02392 724251 

E-mail: 

Training needs 

analysis and training 

equipment design 

SSG – Sea Systems Group Ash 3C, Mail Point 3311 


BRISTOL 

BS34 8JH 

HFI Focal Point for 

provision of advice to 

all IPT projects. 

SSG-CSHF – Sea Systems 

Group, Combat Systems 


SSG-SSMO – Sea Systems 

Group, Ship Safety 

Management Office 



E-mail: 

tes-ssg-shipdes@dpa.mod.uk 



Bristol 

BS34 8JH 



E-mail: tes-ssg-cshf@dpa.mod.uk 



Bristol 

BS34 8JH 



E-mail: tes-ssg-ssmo@dpa.mod.uk 

HFI Focal Point for 

combat system HFrelated 

issues. 

Implementation of 

JSP 430. 






ANNEX 3 – REFERENCES 

CONTENTS 

A3 References................................................................................................................ A3-3 





Annex 3 – References 

A3 

References 

Underlined text indicates a short document name or identity used in the body of 

the text. 

Each reference includes the title together with the identity, issue, date, and 

author / publisher. Voids are indicated by a tilde (~). Additional information (eg 

web address) may also be provided. 

[1] Human Factors Integration (HFI) 

Technical Guide (STGP 11) 

MAP-01-011, Issue 4, May 2006, Sea 

Systems Group / MOD. 

(Previously known as STGP 11) 

[2] The Acquisition Handbook ~, Edition 6, Oct 2005, MOD. 

[3] Human Factors Integration: An 

Introductory Guide 

~, Version 1.2, 16 Aug 2000, MoD 

Corporate Research Package TG5 / 

DERA. 

[4] The MOD HFI Process Handbook Edition 1, Dec 2005, produced by MBDA 

Ltd on behalf of MOD HFI DTC 

[5] Human Factors Integration (HFI) AMS Topic 2561, AMS Build v10.2, Apr 

2006, AMS / MOD. 

‘http://www.ams.mod.uk/ams/content/top 

ics/pages/2561.htm’ 

(Part of the Acquisition Management 

System [Ref 16]) 

[6] MOD Ship Safety Management JSP 430, Issue 3, 2005, Ship Safety 

Management Office/ DPA. 

Part 1: Policy, Issue 3 Amnt 1, Mar 

2005. 

Part 2: Policy Guidance, Issue 3 Amnt 1, 

Mar 2006. 

Part 3: Naval Authority Regulations, 

Issue 3, Mar 2005. 

Part 4: Audit Manual, Issue 3, Mar 2005. 

[7] Naval Manning Manual BR 4017, 1204 edition, Dec 2004, Office 

of DNPS / MOD. 

[8] The Defence Systems Approach to 

Training Quality Standard (DSAT QS) 

[9] Defence Training Support Manual 

(DTSM) 1: The Analysis, Design and 

Development of Training 

DGTE/12/02, ~, Mar 2003, DG T&E / 

MOD. 

Tri-Service replacement for ‘The Royal 

Naval Systems Approach to Training 

Quality Standard’ (RNSAT QS) [Ref 28]. 

DTSM1, Final 1.0, May 2004, DG T&E / 

MOD. 




(DTSM) 2: The Glossary of Defence 

Training Terminology 


(DTSM) 3: Training Needs Analysis 


(DTSM) 4: The Evaluation of Training 


(DTSM) 5: Technology Based Training 

Delivery Solutions 


(DTSM) 6: The Audit and Inspection of 

Individual Training 

DTSM2, ~, Apr 2005, DG T&E / MOD. 

DTSM3, Final 1.0, Sep 2004, DG T&E / 

MOD. 

(replaces JSP 502 [Ref 20]). 

DTSM4, Final 1.1, Mar 2005, DG T&E / 

MOD. 

DTSM5, Final 1.0, Sep 2005, DG T&E / 

MOD. 

DTSM6, Draft 2.0, Sep 2005, DG T&E / 

MOD. 

[15] MOD ILS Manual ~, 2006, ILS / MOD. 

‘http://www.ams.mod.uk/ams/content/do 

cs/ils/ils_web/ilsmgt/ilsmg1.htm’ 

(Part of the Acquisition Management 

System [Ref 16]) 

Tri-Service replacement for the Royal 

Navy Integrated Logistics Support (ILS) 

Manual, Issue 3, 1998, HILS(N). 

[16] Acquisition Management System (AMS) 

website 

AMS, Build v10.3, May 2006, AMS / 

MOD. 

‘http://www.ams.mod.uk/’ 

[17] Human Factors Integration (HFI): 

Practical Guidance for IPTs 

[18] Defence Science and Technology 

Laboratory (Dstl) website 

[19] Procedure for Ship Manning for NATO 

Surface Ships 

~, Issue 1, May 2001, MoD. 

~, ~, ~, Dstl/MOD. 

‘http://www.dstl.gov.uk/’ 

ANEP 21, Edition 1, Sep 1991, NATO 

MAS. 

[20] The Tri-Service Guide to Training NeedsJSP 502, ~, July 2001, MOD. 

Analysis (TNA) for Acquisition Projects (Replaced by DTSM3 [Ref 11]). 

[21] Safety Management Requirements for 

Defence Systems 

Def-Stan 00-56, Issue 3, Dec 2004, 

MOD. 

Part 1: Requirements, Issue 3, Dec 

2004. 

Part 2: Guidance, Issue 3, Dec 2004. 

[22] Maritime System Maturity STG/103/1, Issue 4, Jan 2006, 

Complied by STG-SS / TES 

[23] Defence Lines of Development JDCC-DLOD-LM, ~, 13 Apr 2005, DG 

JDC / MOD 


Annex 3 – References 

[24] The United Kingdom Glossary of Joint 

and Multinational Terms and Definitions 

UK Joint Warfare Publication (JWP) 0- 

01.1, 6 th Edition, ~, MOD. 

[25] Motivation and Personality Maslow ‘54, First Edition, 1954, Maslow, 

A.H / NY: Harper. 

Third Edition, 1987, NY: Addison- 

Wesley. 

[26] Ergonomics Society (ES) website ~, ~, Apr 2006, ES. 

‘http://www.ergonomics.org.uk/’ 

[27] HFI Process Risk Assessment (PRA) ~, ~, May 2001, Brian Sherwood Jones / 

Process Contracting and Jonathan 

Earthy / Lloyd’s Register of Shipping. 

‘http://www.processforusability.co.uk/HFI 

PRA/HFIPRA.html’ 

[28] The Royal Naval Systems Approach to 

Training Quality Standard (RNSAT QS) 

BR 8420, Issue 2, 1999, RNSETT / 

MOD. 

Superseded by ‘The Defence Systems 

Approach to Training Quality Standard’ 

(DSAT QS) [Ref 8]. 

[29] Human Factors Integration Governing Policy GP 2.15, new at 

version 4.0, May 2006, TES-SA-SSE / 

MOD. 

’http://www.ams.mod.uk/ams/content/do 

cs/sse4/content/ksa2/gp215.htm’ 

(Part of the ‘Support Solutions Envelope’ 

[Ref 30]) 

[30] Support Solutions Envelope SSE, version 4.0, May 2006, TES-SA- 

SSE / MOD. 


cs/sse4/index.htm’ 

[31] Through Life Management - Guidance ~, ~, ~, TLM Team / DPA. 


cs/tlmp/tlmpgde.htm’

MAP-01-010 HFI Management Guide - Human Factors Integration ...

Create successful ePaper yourself

Delete template?

Save as template?