Identifying Risks

This section provides some guidance on the use of HFI PRA to identify and to mitigate project risks.

Type of risk or issue
Summary
General Project Risk Widespread project risks; if they apply, then conducting an HFI PRA is likely to be beneficial.
Using Early HF Analysis and HFI PRA together Summary of how EHFA and HFI PRA relate to each other and can be used to reduce project risk.
Risks related to project stage Common risks related to Concept and to Assessment stages are identified, and mitigation suggested.
Risks related to types of project Typical risks for projects are identified including, platform, CIS and C4I.

Back to HFI PRA home page

General Project Risks

If a project has general risks related to user aspects, then you may be considering trying HFI PRA. To help you work out whether or not an HFI PRA would help, click here for guidance.

Using Early HF Assessment and HFI PRA together

Early HF Assessment (EHFA) is an activity that helps to identify the technical risks associated with the operability of a system.

There may also be risks associated with the management, resources or programme of the project. HFI PRA can complement EHFA by assessing the risks associated with processes or programme aspects.

Additionally, specific activities may be considered necessary to mitigate technical risks identified in EHFA. Again HFI PRA can complement EHFA by assessing the project's capability to carry out the processes that embrace the required activities.

 

Back to top

Risks Related to Project Stage

This section discusses typical HFI issues or risks at the two earliest stages of a project, concept and assessment.

Stage: Concept: At this stage in the project, there will be relatively little evidence available of HSL processes having produced deliverables, and the emphasis is on checking that the processes are in place to address user aspects of design and of acquisition. The table below gives examples of risks and of how HFI PRA can be used in AMS to mitigate them.

Issue/Risk

Mitigating HSL processes

AMS Evidence, Deliverables

Possible interview questions

Equipment focus (say in URD)

Technical HCD activity (HS.3), integrated into the project (HS.2.7), backed by commitment to operability (HS.2.1), and user involvement (HS.2.6).

Report on operability risks arising (HS.2.5) from equipment focus.

Evidence of following process for URD in Smart Requirements in IPT Guide.

Statements in URD iaw requirement i.e. "the user shall be capable of..." referring to operational tasks rather than system interaction.

Risk register

How were Human-system issues accounted for in acquisition (HS.2.3)?

How was the allocation of function between the user and the equipment envisaged (HS.3.3)?

How was the context of use seen to influence user goals (HS.3.1)?

Acquisition/MPT disconnect or mis-alignment

Present the context and Human Resources options and constraints as output (HS.1.1.BP6).

Manage MPT stakeholders (HS.2.3.BP1)

Involve users (HS.2.6)

Technical activity is principally HS.4 by the PPO, aligning with project-based HS.3.1.

Assumptions and dependencies in URD or Master Data Assumptions List (TLMP).

Identity of all stakeholders in TLMP. TNA plan in TLMP.

What manpower options were developed to accompany (or generate) equipment options (HS.4.3)?

What manpower and training constraints were identified (HS.4.1)?

Human effectiveness and cost issues not in business case

Technical work is in HS.3.2.

The output appears in HS.1.1.BP8.

The inclusion of Human-system issues in financial management is HS.2.3.BP2.

Human costs and effectiveness (with uncertainties) put into business case, CEA and TLMP.

Human effectiveness appears in CONOPS.

How were human costs and effectiveness issues included in the business case (HS.2.3.BP2)? Do Human-system issues appear in the business case (HS.1.1.BP8)?

How were user performance criteria set and agreed (HS.3.2.BP4)?

Separate procurements lead to lost MPT opportunities

Identified in HS.3.1.

Risks and opportunities managed by HS.2.5

Reported in HS.1.1.BP5

On small projects a cluster IPT may address this. Assumptions and dependencies in URD.

What are the characteristics of any other equipment to be used in the system and working environment (HS.3.1.BP5)?

User Requirements abstract, open to misinterpretation, not tested with user community, consequential changes in operations missed

HS.3.2 processes for exploring requirements.

User evaluation of concept against requirements (HS.3.4).

Early prototyping (HS.1.1.BP6).

User involvement (HS.2.6)

Evidence of following the correct processes in URD production.

How are users involved in the project (HS.2.6)?

How is the concept evaluated from a user point of view (HS.3.4, HS.1.1.BP6)?

Stage: Assessment

Issue/Risk

Mitigating HSL processes

AMS Evidence, Deliverables

Possible interview questions

Equipment focus in SRD with lack of operability drivers

Gain commitment to operability (HS.2.1). Setting user requirements with measurable criteria (HS.3.2). Evaluating system (HS.3.4). Reported by HS.1.BP5.

Traceability of SRD to URD and performance goals.

How are system requirements and performance criteria linked to user requirements and criteria (HS.3.2)?

User roles missed e.g. due to focus on ‘operator’

Effect on stakeholders considered in HS.1.2.BP1

Staffing solution identified by HS.4.3

User roles identified by HS.3.1.

Users involved by HS.2.6

Users identified by HS.3.1.BP3

Identification of all users in URD.

How are the users specified (HS.3.1.BP3)?

Operability loses to cost in work up to Main Gate,

WLC loses to UPC in work up to Main Gate,

resulting in operability and MPT problems

Use operability risks in trade-offs, raise new consequential risks, advise on severity (HS.2.5.BP3).

Consider HS issues in financial management (HS.2.3.BP2)

Apply procedures for HFI sign-off (HS.2.3.BP4).

Include HFI in business case (HS.1.1.BP8)

Inputs to TLMP of consequential WLC increases.

Inputs to CEA on capability shortfalls.

Entries in risk register.

PPO aware of risks.

How do you use HS data to identify and reconcile conflicts between Human-system issues and other aspects of system design and operation (HS.2.5)?

COTS equipment designed for a different context of use is adopted without tailoring to save money

System context of use defined and analysed (HS.3.1). Trial implementation tested (HS.1.2.BP5) using HS.3.4.

Testing identified in ITEA. Context identified in URD. Mismatch identified in risk register.

How do you test key aspects of the system with users (HS.1.2.BP5)?

Inadequate HFI budget leads to potential operability problems not being identified or corrected when cost-effective to do so.

Usability is seen as a competitive asset (HS.2.1.BP1).

Plan and Manage use of HF data to mitigate HS risk (HS.2.5.BP1).

TLMP relates work programme to risks.

Risk management plan assigns resources.

HFIP shows risk-driven approach.

How do you manage the HFIP to address HFI issues and risks (HS.2.4.BP3)?

Back to top

Typical Risks for types of project

This section identifies typical risks for some types of major project and is intended as an aid to thought when starting a full risk assessment and Process Improvement exercise.

Type of project: Platform (air, sea or land)

The risk is that...

The processes that would mitigate the risk are...

The drive to reduce manpower on the platform leads to excessive workload, inappropriate job design and reduced flexibility.

HS.4 should identify the concerns from a manpower point of view.

HS.3.1 should identify issues related to this.

HS.3.4 should show these problems.

HS.2.5 should present these issues to management.

HS.2.3 should prevent them going through to acquisition.

The organisational split between platform design and onboard C4I design leads to poor workplace and workstation layout.

HS.2.4 should put management measures in place to prevent this, supported by HS.2.7 at a working level.

Design problems should be identified in HS.3.3, HS.3.4

Changing employment patterns and conditions of service are not accommodated in the emerging design leading to inappropriate job design assumptions.

HS.4.1 should identify this from a manpower point of view. Continuing HS.3.1 should identify this from a system point of view.

Separation of platform delivery and training delivery leads to difficulties in supporting rollout and initial capability.

HS.2.3 should allow input from HS.4 activities. HS.2.4 should provide suitable communication in a plan. HS.2.7 should support communication at a working level. These issues should be addressed by HS.1.3

Type of project: CIS

The risk is that...

The processes that would mitigate the risk are ...

The complex and changing context of use, particularly the technical environment, leads to a system with poor interoperability from the user point of view (i.e. with the other user interfaces in the context of use).

Describing the equipment in the context of use (HS.3.1.BP5).

HS.2.8.BP2 produces resources such as style guides to promote common features which are applied to the design.

The rapidly evolving nature of COTS-based technical solutions leads to a drift between the real requirement and the solution and the loss of key features in the design that was awarded the contract.

User requirements (HS.3.2) should anticipate drift. Evaluations (HS.3.4) should detect drift. Risk management should assess impact (HS.2.5). Drift in deliverable descriptions should be rejected by HS.2.3.BP4.

Complex system management functions are not hidden from non-specialist staff leading to a mis-match between user skill and system complexity e.g. system management role requires IT skills beyond candidate user.

HS.4 should identify skill requirements for candidate users. HS.3.1 should specify users. HS.3.2 should specify requirements that refer to user characteristics. Evaluation (HS.3.4) should reveal mismatch. In practice, likely to be detected by users (HS.2.6).

The increasing volumes of information to be managed leads to crowded displays and/or complex navigation.

Guidelines applied to the design (HS.3.3) should prevent clutter. User requirements (HS.3.2) should make such solutions non-compliant. A practical model of the design concept should identify this risk early on (HS.1.1, HS.1.2).

Type of project: C4I

The risk is that...

The processes that would mitigate the risk are...

An equipment focus leads to a neglect of understanding a) true information needs to support new types of decision b) true information flow requirements for modern battlefield organisation c) the centralisation/de-centralisation options that may be required.

Understanding user goals and the context of use (HS.3.1) should provide the material for decision centred design.

User information and decision needs relating to the operational task are specified in user requirements (HS.3.2.BP1, BP4).

Early prototypes (HS.1.1, HS.1.2) should show up problems.

Relating human performance to the business case should help drive design (HS.1.1.BP8)

‘Smart’ operator support based on mathematically appealing models of uncertainty lead to inappropriate advice to the operator in the real operational environment and inadequate access to the data that is really needed.

An equipment focus makes an assumption that complex RISTA tasks (e.g. associated with image analysis) can be done in Near Real Time in the field by front line non-specialist analysts which leads to a mismatch between operational demand and operator capability.

Human issues in concept (HS.1.1) should report on this mis-match, identified by understanding context of use (HS.3.1), generating user requirements (HS.3.2) and evaluating the design (HS.3.4).

The manpower-driven view (HS.4) should identify the excessive demands on users.

Piecemeal procurement and federated systems are specified with overlapping functionality leading to the same information presented in different ways in the same context of use.

Standards, style guides (HS.2.8) applied to the design (HS.3.3) should prevent this. Understanding the context of use (HS.3.1) should identify the risk.

The rapid pace of operational change and the need for flexibility is not translated into requirements and cost justified initially, and then not tracked leading to an evolving design that does not match the evolving requirement or context of use.

Continued tracking of concept isssues (HS.1.1), coupled with iterative design and test (HS.3.4). Continuing Context of Use process should trap this (HS.3.1).

Back to top