IAN 139/11 - Department for Transport

Interim Advice Note 139/11 Managed Motorways

Safety Risk Work Instructions

IAN 139/11 of 266 Mar 11

Interim Advice Note 139/11 Managed Motorways Project Safety Risk Work Instructions Part 0: Introduction Part 1: Work Instruction WI001 Part 2: Guidance for Work Instruction WI001 Part 3: Not used Part 4: Not used Part 5: Work Instruction WI003 Part 6: Guidance for Work Instruction WI003 Part 7: Work Instruction WI004 Part 8: Guidance for Work Instruction WI004 Part 9: Appendices to Guidance of WI001, WI003 & WI004 Part 10: Safety Report Template Ver 1.0 Part 11: Safety Plan Template Ver 1.0 Part 12: Hazard Log Report Template Ver 2.0



IAN 139/11 of 266 Mar 11

Amendment History Introduction Date Version Modification Sections Affected 1.0 Document Creation All Work Instruction WI001 Date Version Modification Sections Affected 29/10/08 1.0 Document Creation All 23/12/09 1.1 Updates to reflect HA re-organisation of

Jan 2020 and final MM Safety Approvals Process

All

??/12/10 1.2 Minor updates to formatting and content to reflect review by HA Standards team for compliance with EU Technical Standards and Regulations Directive 98/34/EC

All

Guidance for Work Instruction WI001 Date Version Modification Sections Affected 19/03/09 1.0 Document Creation All 25/11/09 1.1 Minor changes to figure numbers All 31/1/11 1.2 Minor updates to formatting and content

to reflect review by HA Standards team for compliance with EU Technical Standards and Regulations Directive 98/34/EC

All

Work Instruction WI003 Date Version Modification Sections Affected 19/03/09 1.0 Document Creation All 23/12/09 1.1 Updates to reflect HA re-organisation of


All

311/11 1.2 Minor updates to formatting and content to reflect review by HA Standards team for compliance with EU Technical Standards and Regulations Directive 98/34/EC

All

Guidance for Work Instruction WI003 Date Version Modification Sections Affected 19/03/09 1.0 Document Creation All 23/12/09 1.1 Updates to reflect HA re-organisation of


All

31/1/11 1.2 Minor updates to formatting and content to reflect review by HA Standards team for compliance with EU Technical Standards and Regulations Directive 98/34/EC

All



IAN 139/11 of 266 Mar 11

Work Instruction WI004 Date Version Modification Sections Affected 19/03/09 1.0 Document Creation All 23/12/09 1.1 Updates to reflect HA re-organisation of


All


All

Guidance for Work Instruction WI004 Date Version Modification Sections Affected 19/03/09 1.0 Document Creation All 23/12/09 1.1 Updates to reflect HA re-organisation of


All


All

Appendices to Guidance of WI001, WI003 & WI004 Date Version Modification Sections Affected 19/03/09 1.0 Document Creation All 23/12/09 1.1 Updates to reflect HA re-organisation of


All


All

Safety Report Template Date Version Modification Sections Affected 19/03/09 1.0 Document Creation All 23/12/09 1.1 Text relating to the safety objective for

road users updated All

Safety Plan Template Date Version Modification Sections Affected 20/03/09 1.0 Document Creation All Hazard Log Report Template Date Version Modification Sections Affected 16/11/09 1.0 Document Creation All 07/01/10 2.0 Final 3

Interim Advice Note 139/11 Working Instruction 001 Managed Motorways Selecting a Project Safety Management System Safety Risk Working Instructions

IAN 139/11 of 266 Mar 11

PART 0: INTRODUCTION Introduction to Work Instructions and Guidance for Managed Motorways Safety Risk Management SUMMARY This document supports the Agency’s

HSMS. It describes the suite of documents describing the Agency’s requirements for safety risk management on Managed Motorways projects

APPROVING PROCESS AND DATES H&S Programme Board/Performance, Delivery and Investment Group (PDIG)/HA Board: Awaiting Approval

AUTHOR/FURTHER INFORMATION NetServ Risk Team/National Health and Safety Team

LEAD DIRECTOR Board Director with responsibility for Health and Safety

APPLIES TO All MM projects VERSION 1 STATUS (Final/Draft) FINAL THIS DOCUMENT REPLACES None – new document DISTRIBUTION REVIEW DUE DATE 2011

ISSUED BY: TBD ISSUE DATE: TBD


IAN 139/11 of 266 Mar 11

Contents 1.1 Background 7 1.2 Objective 7 1.3 Scope 7 1.4 Implementation 7 1.5 Responsibility for Application 7 APPENDIX A: ABBREVIATIONS 8


IAN 139/11 of 266 Mar 11

1.1 BACKGROUND Projects undertaken by the Highways Agency (HA) have to be implemented with an appropriate level of safety risk management in order to provide road users, road workers and 3rd parties with adequate risk protection. Project safety risk is controlled by deploying an appropriate Safety Management System (SMS), so determining the activities that make up the SMS is important for all projects. To assist projects in putting an appropriate SMS in place the HA has developed: 1. A set of Work Instructions (001,002,003 and 004) that are used first to identify SMS

requirements for a project and then to apply the most suitable safety management activities

2. A set of Guidance Documents that explain in more detail how to apply the Work Instructions

The complexity and rigour of the SMS needed will vary significantly from project to project. Work Instructions 002, 003 and 004 describe the requirements for project safety management for increasing levels of complexity and rigour, with Work Instruction 002 describing the basic safety management requirements and Work Instruction 004 describing the most rigorous. The Work Instructions and set of Guidance Documents form part of the suite of tools and techniques that are to be used to make informed decisions about appropriate health and safety controls for projects. They support the Agency’s Health and Safety Management System (HSMS). The relationship between these documents is shown in .

HA Health and Safety Management System Overview Document

Work Instruction 001: Selecting a Project Safety

Management System

Work Instruction 002: SafetyManagement for Projects with

Type A Features


Type B Features


Type C Features

Guidance on Selecting and Applying Safety

Management Systems for Projects

Guidance for Work Instruction 001




Guidance for Work Instruction 001-004

Introduction


Appendices

HA Health and Safety Management System Overview Document


Management System


Type A Features


Type B Features


Type C Features


Management System


Type A Features


Type B Features


Type C Features








Introduction


Appendices








Introduction


Appendices






Introduction


Appendices

Figure 1-1 Structure of the Documentation


IAN 139/11 of 266 Mar 11

Owing to their nature, no MM projects will be classified as Type A; the principles of Type A safety risk management are described within this IAN for completeness only. To reflect this, there is no Work Instruction for Type A Safety Risk Management on Managed Motorways projects and the remainder of this IAN talks only about Type B and Type C safety management. At current time Works Instruction 002 is irrelevant to MM projects. If this changes in future an update to these Work Instructions will be released. Work Instruction 002 is referenced in the Work Instructions where necessary to complete the context. 1.2 OBJECTIVES The objectives of the Work Instructions and Guidance contained within this IAN are to:

1. Ensure that MM projects adopt an appropriate Safety Management System (SMS) 2. Define the requirements for different types of SMS 3. Provide guidance on how the requirements for different types of SMS can be met 4. Provide information on various supporting tools, techniques, methodologies and other

reference material 5. Provide templates for the main associated PCF products

1.3 SCOPE This document describes the safety risk management requirements for Managed Motorways projects. 1.4 IMPLEMENTATION This document applies to all Managed Motorways projects. It does not apply to any other HA projects at this time. 1.5 RESPONSIBILITY FOR APPLICATION It is the responsibility of the Project Manager to make sure that this document is properly applied, although its actual application may be delegated to other parties including the supply chain.


IAN 139/11 of 266 Mar 11

APPENDIX A: ABBREVIATIONS

Abbreviation Definition HA Highways Agency HSMS Health and Safety Management System IAN Interim Advice Note MM Managed Motorways PCF Project Control Framework SMS Safety Management System


IAN 139/11 of 266 Mar 11

PART 1: WORK INSTRUCTION WI001

Selecting a Project Safety Management System

SUMMARY This document supports the Agency’s

MAHS procedures. It describes how to classify different project features in order to select an appropriate level of safety management for projects




APPLIES TO All Agency activities VERSION 1 STATUS (Final/Draft) FINAL THIS DOCUMENT REPLACES None – new document DISTRIBUTION REVIEW DUE DATE 2010



IAN 139/11 of 266 Mar 11

Contents 1 Introduction 11 1.1 Background 11 1.2 Objective 11 1.3 Scope 11 1.4 Implementation 11 1.5 Responsibility for Application 11 2 When to Apply the SMS Selection Process 12 2.1 Appplication as Part of the Project Lifecycle 12 2.2 Application During Options Selection 12 2.3 Ongoing Documentation of Selection Process Application 15 2.4 Transfer of Ownership 16

2.5 Approval of deliverable 17 3 Selecting a Safety Management Sysytem (SMS) 18 3.1 Review Project Scope Definition 18 3.2 Classify Project Features 18 3.3 Apply SMS Selection Rules 18 3.4 Documenting Results of the SMS Selection Process 18 3.5 Approval of the Deliverable 18

4. Establishing the project arrangement for safety acceptance and approvals 19

5. Approving the project SMS 20

APPENDIX A: REFERENCES 23 APPENDIX B: DEFINITON OF TERMS 24 APPENDIX C: ABBREVIATIONS 25


IAN 139/11 of 266 Mar 11

1. INTRODUCTION 1.1 Background This document is Work Instruction 001 - Selecting a Safety Management System. It forms part of a suite documents (Work Instructions WI001, WI003 and WI004 and associated Guidance) that set out the requirements for safety risk management for Managed Motorway (MM) projects as part of the Agency’s Health and Safety Management System (HSMS). It describes how to select an appropriate level of safety management for MM projects. 1.2 Objective The objective of this Work Instruction is to describe the process to be followed in order to identify the SMS requirements that are applicable to a given MM project. 1.3 Scope The scope of this document is limited to describing how to establish the SMS requirements for a MM project. It also addresses when during the project lifecycle (in accordance with the Project Control Framework – PCF) such requirements shall be established. 1.4 Implementation This Work Instruction is applicable to all Managed Motorway projects. Where such projects are established as having no impact on either road user safety or road worker safety, no further application of this Work Instruction is necessary. It is only necessary to document this absence of impact on safety (see section 0 for details). This Work Instruction is applicable to all project lifecycle stages from Options Phase onwards. All projects shall follow the Construction (Design and Management) Regulations 2007 (CDM 2007) and will be able to demonstrate that they have done so. However, adherence to this Work Instruction in all areas of project development should address CDM 2007 requirements in relation to construction. It is not necessary to repeat any risk assessment activity carried out in following this Work Instruction in order to comply with CDM 2007, neither is it necessary to repeat work carried out under CDM 2007 to comply with this Work Instruction. 1.5 Responsibility for Application It is the responsibility of the Project Manager to make sure that this Work Instruction is properly applied, although its actual application may be delegated to other parties including the supply chain.


IAN 139/11 of 266 Mar 11

2 SELECTING A SAFETY MANAGEMENT SYSYTEM (SMS) summarises the main steps involved in the SMS selection process. Each step is explained in more detail in the sections that follow.

Classify projectfeatures

Apply SMS selectionrules

Document results

Review project scope definition

Determine SMS(Type A, B or C)

Classify projectfeatures

Apply SMS selectionrules

Document results

Review project scope definition

Determine SMS(Type A, B or C)

Figure 2-1 Application of Work Instruction 001

2.1 Review Project Scope Definition Defining the project scope is not part of the safety management activities and needs to take place prior to selecting an SMS. A project scope definition is needed to support the SMS Selection Process. The project scope definition shall be reviewed in order to gain a clear understanding of:

The main objectives that the project is intended to deliver and the impact of these objectives on network safety

How the project will deliver these objectives in terms of any proposed interventions and use of technology

Any wider organisational or network implications arising from the project

2.2 Classify Project Features A project SMS can be determined by classifying a set of project features. A project feature in this context is a high level property of the project that will affect safety management requirements.


IAN 139/11 of 266 Mar 11

The project features that need to be classified are:

1. The number and level of influence of stakeholders, where a stakeholder is considered to be a person or body with a direct interest in the project

2. The extent and locations of previous operational experience 3. The current experience of, and safety risks associated with, the use of any

technology being introduced 4. The current status of standards and legislation with respect to the project and in

particular whether any legislation imposing obligatory duties on the project has changed or been introduced

5. The impact that the project will have on existing organisational arrangements i.e. the degree of organisational change and hence responsibility change that project implementation will require

6. The project’s overall scale Each project shall classify the features listed in Table 2-1 and assign a Type (A, B or C) to each. It is not possible for Table 2-1 to be prescriptive for all projects, given the range of projects that exist. Therefore the wording used to define whether a feature is A, B or C in Table 2-1 is not to be treated as being definitive in all cases but rather as providing guidelines on classification. When considering the ‘Standards and Legislation’ feature in Table 2-1, only those departures that have an impact on safety need be considered. Following this Work Instruction does not affect in any way the requirement to gain acceptance for such departures nor does it modify the application for departures process in any way. However, project safety risk assessment work may be used to support both the departures process and Safety Management System requirements and does not need to be repeated.


IAN 139/11 of 266 Mar 11

Feature Type A Type B Type C 1. Stakeholder Interest

– Stakeholders – Impact

Single or few Limited

Several Limited

or Single or few Significant

Many Limited

or Key Significant

or Several Major/critical

2. Operational Experience – Extent – Where

Widespread UK

Limited UK

or

Some Overseas only

None in UK nor overseas

3. Technology – Technology experience

(consider degree of innovation and criticality of application)

Widespread Used in different

application

or Applied in part Not previously applied

– Level of safety risk that introduced technology affects

Low Medium High

4. Standards and Legislation – Design covered by existing

standards – Safety-related departures from

standards – Changes to legislation

All None/No significant

None

Mostly Some/Few significant Minor changes only

No Many Significant

Moderate

or

New standard Some Critical departures

Significant

– HA Guidance Existing/not applicable Relevant new guidance available Major development in relevant guidance

5. Impact on Organisation (consider structure, responsibility, competency, whole life impact)

No changes

Minor changes/responsibility transfer

Significant change or responsibility transfer

6. Project Scale – Infrastructure affected – Extent of roll-out

Single/small location None/minimal

Major location/implications Moderate

Widespread/national implications National potential

Table 2-1 Classifying Project Features


IAN 139/11 of 266 Mar 11

2.3 Apply SMS Selection Rules Once each of the project’s features have been classified, the appropriate SMS can be selected. There are three possible SMS types:

1. A Type A SMS 2. A Type B SMS 3. A Type C SMS

These Types are interpreted as follows:

o Type A: Basic safety management needs to be applied. This will be satisfied by the application of existing standards and safety management processes, plus a brief Safety Report will be needed.

o Type B: A moderate level of safety management needs to be applied. This will include the application of existing standards and safety management processes, where they exist. However it will also require some additional some risk assessment, plus a more detailed Safety Report.

o Type C: Rigorous safety management shall be applied. Where they exist, existing standards and safety management processes will still be applied, but by definition, much of the project will fall outside of existing experience. Therefore, records shall be kept of all activities undertaken, all decisions and their justifications shall be recorded and extensive risk assessment shall be carried out. A comprehensive Safety Report will be required.

The rules that are used to determine which of the three types of SMS is applicable to a project are listed in Table 2-2

Project Feature Classifications

SMS Type Applicable Work Instruction(s)

Comments

All Type A Type A 002 Where all project features are classified as Type A then the entire SMS will be of Type A and all safety management activities are to be applied in accordance with Work Instruction 002 0

All Type B Type B 003 Where all project features are classified as Type B then the entire SMS will be of Type B and all safety management activities are to be applied in accordance with Work Instruction 003 0

All Type C Type C 004 Where all project features are classified as Type C then the entire SMS will be of Type C and all safety management activities are to be applied in accordance with Work Instruction 004 0

3 or more Type B, remainder Type A

Type B 003 Where three or more project features are classified as Type B and the remainder are Type A, then the entire SMS shall be of Type B and all safety management activities are to be applied in accordance with Work Instruction 003 0

3 or more Type C

Type C 004 Where three or more project features are classified as Type C then the entire SMS shall be of Type C and all safety management activities are to be applied in accordance with Work Instruction 004 0

Table 2-2 Rules for SMS Selection

The above rules do not cover all combinations of feature classifications as it is not possible to be categorical about which SMS Type to use in all circumstances. Where only one or two projects features are of a higher Type than the others then it is a project decision as to which SMS Type to select.


IAN 139/11 of 266 Mar 11

The default position for all Managed Motorways projects is that they will require a Type B SMS. However, some projects may identify discrete issues (e.g. a combination of sub-standard features that have a significant effect on safety risk) that require a Type C approach to safety management. In this situation, a project may be classified as ‘Type B, with Type C issues’. This will not justify full application of a Type C SMS to the whole project, but may justify the application of a Type C approach to the identified discrete issues. This situation will require the project to identify those aspects of a Type C approach to safety management that are necessary in order to achieve an appropriate level of safety management for the identified issues. It is unlikely that any Managed Motorway projects will justify full application of a Type C SMS to the whole project. Application of any aspects of a Type C approach to safety management on Managed Motorway projects must be approved by the National Safety Control Review Group (NSCRG - see Section 5). As described in Part 0 of this IAN, no MM projects will be classified as Type A. The SMSs for all projects will comprise of some or all of the activities listed in Table 2-3. Activities are carried out to a greater depth as the SMS changes from A toB to C. More details are provided in Work Instructions 003 & 004. Safety Management Activity

Brief Description of Activity

Safety Baseline and Objectives

Defining the current level of safety and the level of safety that the project will work to achieve

Safety (Strategy and) Plan

Defining the approach that will be taken in order to deliver the project safety objectives.

Risk Assessment Activities

Identifying potential hazards and estimating the risk that is attributed to each of these hazards.

Hazard Log Developing a database to record all identified hazards, the associated risk from each hazard and progress with mitigation

Verification and Validation

Processes to ensure that the project meets all of its safety requirements, determining whether any assumptions made in assessing the magnitude of risks are consistent with real data and determining whether the project fulfils its original intensions.

Safety Report Producing a document that summarises how safety has been managed on the project and whether the safety objective has been achieved.

Updating Safety Documentation

Updating all safety related documentation to reflect any changes to the project that are made once it has commenced operation

Table 2-3 Safety Management Activities Constituting a Projects SMS 2.4 Documenting Results of the SMS Selection Process The results of the SMS Selection Process shall either be:

1. Documented in a standalone report, or 2. Incorporated as part of another report, such as a feasibility study or the project Safety

(Strategy and) Plan. The results will include:

A brief summary of the project scope definition A description of the characterised project features i.e. those features listed in Table 2-

1 with a corresponding ‘A’, ‘B’ or ‘C’ allocation and associated justification for this selection

Conclusions as to the type of SMS that will need to be applied to the project (this information should include a list of the activities to be performed)

An indication as to when this assessment should be reviewed


IAN 139/11 of 266 Mar 11

2.5 Approval of the Deliverable Approval of the deliverable arising from the application of the SMS Selection Process will need to be obtained from the key internal project stakeholders. This group will include the Project Manager.


IAN 139/11 of 266 Mar 11

3 WHEN TO APPLY THE SMS SELECTION PROCESS 3.1 First Application of the SMS Selection Process For most projects the first formal application of the SMS selection process will be once a project has been selected for implementation. This will normally be at the ‘Preliminary Design’ stage. At this point it will be clear what outline design the project is considering. 3.2 Application During Options Selection Whenever a project includes an options selection stage, safety will be an input into this process. Specifically, the safety implications associated with each project option may play a part in which option is selected for implementation. Application of the SMS selection process during Options Selection will provide an indication of the SMS requirements of each option. The degree of rigour with which the SMS selection process is applied will be a project specific consideration. The Options Selection process will be supported by a risk assessment. The nature of this risk assessment will be determined by application of Work Instruction 001 to each option (i.e. to determine whether a Type A, B or Type C approach to risk assessment is required). Full application of the risk assessment requirements of Work Instructions 003-004 is not expected to be necessary for Options Selection. The degree to which they are applied is a project specific consideration. 3.3 Ongoing Application of the SMS Selection Process The SMS selection process shall be re-applied whenever there is a significant change to the scope of the project, or to the detail of proposed operational regime, technology or infrastructure. This is necessary to check if the original project safety risk management regime is still appropriate, or if a more rigorous, or relaxed regime is now required. 3.4 Documenting the Application of the SMS Selection Process The main deliverable arising from the SMS selection process is described in section 2.4. Further applications of the SMS selection process will require this deliverable to be updated. Where a project requires a Safety Strategy and/or Plan, the results of ongoing applications of the SMS selection process may be documented within that document. 3.5 Transfer of Ownership Project ownership may be transferred at some point during a project’s existence and with it, responsibility for continuing to apply the appropriate approach to project safety risk management. For example, prior to a project becoming operational, ownership is expected to transfer from development to operations. At such a time, the party (or parties) taking ownership will reapply the SMS selection process in order to be clear that an appropriate approach to project safety risk management has so far been followed for the project and to establish whether any changes to this approach are now necessary. This party (or parties) will then have responsibility for the ongoing application of this Work Instruction.


IAN 139/11 of 266 Mar 11

4 ESTABLISHING THE PROJECT ARRANGEMENTS FOR SAFETY ACCEPTANCE

AND APPROVALS All Managed Motorway projects are required to establish a Project Safety Control Review Group (PSCRG) at the inception of the project. Specific responsibilities of the PSCRG will be to:

1. Review and agree Type B project safety deliverables/issues 2. Consider and make recommendations regarding Type C project safety deliverables/issues to the National Safety Control Review Group (NSCRG)

HA Project Managers may also request the PSCRG to review:

specific project safety issues, for endorsement (Type B) or referral, along with a recommendation, to the NSCRG (Type C)

specific departure applications, either before they are submitted to the relevant HA technical specialist(s), or following rejection by relevant technical specialists.

Further details about the PSCRG and NSCRG, including PSCRG membership requirements and how often the PSCRG should meet are provided in the document ‘Managed Motorway Schemes - National Safety Control Review Group and Project Safety Control Review Groups - Remit for Organisation and Governance’.


IAN 139/11 of 266 Mar 11

5 APPROVING THE PROJECT SMS The choice of project SMS must be formally approved before work to implement the SMS begins. If the project is recommending a Type B SMS, this is first submitted to the PSCRG. The PSCRG decide whether or not to agree to this recommendation; it is then either returned to the project team for further consideration, or submitted for formal acceptance and approval via the process shown in Figure 5.1. If the project is recommending any aspects of a Type C SMS, this is also submitted first to the PSCRG. The PSCRG will then submit a recommendation to the NSCRG. The NSCRG will then consider this and provide their response back to the project team. The final recommendation is then submitted for formal acceptance and approval via the process shown in Figure 5-1.

MP Project Manager

NDD Project Senior User

NetServ Group Manager

Safe Roads & Casualty Reduction

MP Project Senior

Responsible Owner

Project Consultant

TMD Project Senior User

Figure 5-1 Safety Acceptance and Approvals Process


IAN 139/11 of 266 Mar 11

Specific responsibilities within this process are defined as follows:

The Project Consultant confirms that (i) the scope and content of the document are correct and compiled with reasonable skill and care and (ii) that the document complies with the requirements of this Work Instruction, in as far as is reasonably practicable

The MP Project Manager endorses confirmation that (i) the scope and content of the document are correct and fit for purpose given the current stage of the project and (ii) that the document complies with the requirements of this Work Instruction

The NDD Project Senior User accepts that, in relation to the project operating regime, the scope and content of the document are correct and fit for purpose given the current stage of the project

The TMD Project Senior User accepts that, in relation to the operation of the project operating regime, the scope and content of the document are correct and fit for purpose given the current stage of the project

The NetServ Group Manager for Road Safety & Casualty Reduction approves that, in relation to project safety, (i) the scope and content of the document are correct and fit for purpose given the current stage of the project and (ii) that the document complies with the requirements of this Work Instruction

The MP Project Senior Responsible Owner approves that, in relation to project safety and the PCF, the document complies with the requirements of this Work Instruction

These responsibilities are reflected in the generic approvals sheet shown in Figure 5-2, which must be completed for the document describing the SMS selection process, as a record of its progress through the safety acceptance and approvals process defined above.


IAN 139/11 of 266 Mar 11

Approvals Sheet for ………………………………………………………………………………….

(Insert title of attached Project Safety Deliverable, document reference, version, status design, construction, commissioning)

Signature For Sign-Off Statement

Name ____________

Date _____________

Signature _____________

Project Consultant

(Project Director)

I confirm that:

the scope and content of the attached deliverable are correct and compiled with reasonable skill and care

the attached deliverable complies with the requirements of the relevant Work Instructions for Project Safety Risk Management, in as far as is reasonably practicable.

Name ____________

Date _____________

Signature _____________

Major Projects Project Team

(MP Project Manager)

I endorse confirmation that:

the scope and content of the attached deliverable are correct and fit for purpose given the current stage of the project.

the attached deliverable complies with the requirements of the relevant Work Instructions for Project Safety Risk Management.

Name ____________

Date _____________

Signature _____________

Network Delivery & Development (Project Senior User)

I accept that in relation to the project operating regime the scope and content of the attached deliverable are correct and fit for purpose given the current stage of the project.

Name ____________

Date _____________

Signature _____________

Traffic Management (Project Senior User)


Name ____________

Date _____________

Signature _____________

Network Services

(Safe Roads & Casualty Reduction Group Manager)

I approve that in relation to project safety:

the scope and content of the attached deliverable are correct and fit for purpose given the current stage of the project


Name ____________

Date _____________

Signature_____________

Major Projects

(Project Senior Responsible Owner)

I approve that in relation to project safety & the PCF:

the attached Project Safety Deliverable complies with the requirements of the relevant Work Instructions for Project Safety Risk Management .

Figure 5-2 Approvals Sign-off Sheet for Project Safety Deliverables


IAN 139/11 of 266 Mar 11

APPENDIX A: REFERENCES

[1] Highways Agency Guidance for Pilots and Trials [2] Managed Motorway Schemes, National Safety Control Review Group and

Project Safety Control Review Groups, Remit for Organisation and Governance


IAN 139/11 of 266 Mar 11

APPENDIX B: DEFINITION OF TERMS

Term Explanation Project Feature A high level property of the project that can be expected to affect safety

management requirements Type A Project Feature A project feature requiring a basic safety management be applied Type B Project Feature A project feature requiring a moderate level of safety management to

be applied Type C Project Feature A project feature requiring rigorous safety management to be applied


IAN 139/11 of 266 Mar 11

APPENDIX C: ABBREVIATIONS

Abbreviation Definition CDM Construction Design and Management HA Highways Agency HSMS Health and Safety Management System MM Managed Motorways NetServ Network Services Directorate NDD Network Delivery & Development NSCRG National Safety Control Review Group PCF Project Control Framework PSCRG Project Safety Control Review Group SMS Safety Management System TMD Traffic Management Directorate

Interim Advice Note 139/11 Guidance for Working Instruction 001 Managed Motorways Selecting a Project Safety Management System Safety Risk Working Instructions

IAN 139/11 of 266 Mar 11

PART 2: GUIDANCE FOR WORK INSTRUCTION WI001


SUMMARY This Guidance is part of the Agency’s

HSMS. It provides guidance on how to meet the requirements of Work Instruction 001




APPLIES TO All Agency activities VERSION 1 STATUS (Final/Draft) FINAL THIS DOCUMENT REPLACES None – new document DISTRIBUTION REVIEW DUE DATE 2010



IAN 139/11 of 266 Mar 11

Contents 1 Introduction 29 1.1 Background 29 1.2 Objective 29 1.3 Scope 29 1.4 Implementation 29 1.5 Responsibility for Application 29 2 Selecting a safety management Sysytem (SMS) 30 2.1 Review Project Scope Definition 30 2.2 Classify Project Features 30 2.3 Apply SMS Selection Rules 40 2.4 Projects that do not match the SMS selection rules 40 2.5 Documenting the results ofg the SMS selection process 40

2.6 Approval of deliverable 41

3 When to apply the SMS SELECTION PROCESS 42 3.1 Application as Part of the Project Lifecycle 42 3.2 Application During Options Selection 44 3.3 Ongoing Documentation of Selection Process Application 44 3.4 Transfer of Ownership 44 4 Additional Guidance (1) – Application of Work Instruction 001 Worked Examples 45 4.1 Project 1: Introduction of Ramp Metering to an ATM (Active Traffic Management)

Scheme 45 4.2 Project 2: Bridge Pier Strengthening 49 4.3 Project 3: Provision of Traffic Officers in the West Midlands 52 5 Additional Guidance (2) – SMS Selection Report template 56


IAN 139/11 of 266 Mar 11

GUIDANCE ON WORK INSTRUCTION 001: SELECTING A PROJECT SAFETY MANAGEMENT SYSTEM Summary This document provides guidance on the application of Work Instruction 001 - how to select an appropriate Safety Management System (SMS) for a project. It is concerned with how to apply Work Instruction 001 and illustrates the application with several worked examples. In this document, the phrase “No further guidance is provided – all required information is within the Work Instruction itself.” means that the information provided in the Work Instruction is self explanatory. In Section 5 of this document a template is provided for users to complete with their project specific information to provide a record of how the project safety management system has been selected.


IAN 139/11 of 266 Mar 11

1. INTRODUCTION 1.1 Background Work Instruction 001 describes how to select and gain approval for an appropriate Safety Management System (SMS) for a MM project. 1.2 Objective No further guidance is provided – all required information is within the Work Instruction itself. 1.3 Scope No further guidance is provided – all required information is within the Work Instruction itself. 1.4 Implementation Work Instruction 001 is applicable to all MM projects. Work Instruction 001 should also be applied to feasibility studies for MM projects. Applying Work Instruction 001 will provide an indication as to the type of SMS that may be required if the project was to go ahead. This may be a useful input into the study - determining the type of SMS provides an indication as to what cost and resource implications further development and implementation of a project may have. Work Instruction 001 applies to all Agency staff and directly supervised contractors and consultants who work for, or with, the HA that are required to perform identical or similar duties to Agency staff. It also applies to the activities of the Agency’s Supply Chain consultants and contractors. In implementing Work Instruction 001 it may be possible to make use of existing safety related work/documentation. Any existing piece of work deemed to be appropriate for re-use in the application of Work Instruction 001 must be thoroughly reassessed before use. The work should not simply be copied over and incorporated within the new project. The project safety risk management procedures described within the Work Instructions and those procedures carried out as part of CDM are two separate processes. Some of the requirements of the Work Instructions and CDM regulations will be the same. Where this is the case, the activity need not be repeated but should be carried out only once to fulfil the obligations of both the Work Instructions and CDM regulations. 1.5 Responsibility for Application No further guidance is provided – all required information is within the Work Instruction itself.


IAN 139/11 of 266 Mar 11

2 SELECTING A SAFETY MANAGEMENT SYSYTEM (SMS) 2.1 Review Project Scope Definition To best support the selection of an SMS, the project scope definition should include a description of:

The carriageway and associated infrastructure that will be affected by the project. Information provided should include an assessment of the extent to which network operation (i.e. access and maintenance) may be affected. For instance the introduction of a hard shoulder running regime will change driver behaviour on the stretches of motorway on which it will be implemented and may lead to different driver behaviour on other parts of the network

Any technical equipment that will be introduced or changed e.g. the introduction of automatic signalling

The people involved in the operational aspects of the project and the impact the project will have on them e.g. a change in operational responsibilities within a control centre

The people involved in the maintenance of the project and the impact the project will have on them e.g. where new technical equipment is deployed, maintenance activities may need to be reassessed

The operational procedures that will be implemented or are affected The maintenance regimes that will be implemented or are affected

A detailed project scope definition may not be available at the beginning of the project. If this is the case assumptions will have to be made in order to apply Work Instruction 001. Any assumptions made should be clearly stated and documented in the deliverable arising (see Section 2.4 of Work Instruction 001). When a more detailed project scope definition becomes available, initial assumptions made in applying Work Instruction 001 should be reviewed to check that they are still applicable. 2.2 Classify Project Features Use of Table 2-1 from Work Instruction 001 Table 2-1 in Work Instruction 001 should be used to assist in the classification of the six project features. The words listed supporting classification of each project feature Type are there as a guide only and should not be viewed as being prescriptive or covering all circumstances that may affect projects. It is not possible to cover all circumstances in such a table and by limiting its content the principles to follow can be presented with greater clarity. In some cases then a degree of interpretation of Table 2-1 is required. To take stakeholder interest as an example, the options available are:

Many/limited or Key/significant or Several/major/critical

However, it is possible that there could be one single, critical stakeholder. This is not covered by the options given in the table but could still lead to a Type C classification. Deciding which feature Type is appropriate is a project specific issue. In some cases, when classifying a particular project feature it may be that the project has elements that are appropriate to more than one Type. In such cases some degree of interpretation is needed and an example is now described, using the feature of project scale.


IAN 139/11 of 266 Mar 11

Example: Project Scale Working through the feature characterisation table that is shown inTable 2-1 and circling the appropriate Type can be a helpful way to proceed with project characterisation. In the example, the first five features have been characterised as Type B and now project scale is considered in more detail. Not all details of the example project are defined but in respect of ‘project scale’ it is known that it will be installed at 2/3 important locations. The project feature ‘project scale’ therefore has both Type B and C elements. The fact that the project will be installed at an important location immediately implies a Type of ‘B’ for this feature (Major location/implications). However, as it is known that it will be installed at more than one location, it also has some Type ‘C’ characteristics (moving towards Widespread/national implications). As a result both ‘B’ and ‘C’ Types are circled. However, an overall assessment of SMS ‘B’ is likely to be appropriate given that all other features are of Type ‘B’. While not all projects will be as clear cut as this example, it illustrates the point that exact classification of Types is not always necessary in making an assessment of the SMS that is to be applied. In all such cases where a feature does not clearly map to one Type, while it is up to the project to decide on the most appropriate Type, the following should be taken into account:

The weight each classification holds. For example, if the majority of the project feature is described by a Type A classification and only a small proportion is described by Type B, it may be appropriate to select a Type A.

Taking a more cautious approach. In other cases it may be more appropriate to be cautious and select the more rigorous feature Type. By doing this, the resulting SMS chosen will also address the features of the less rigorous Type. For example if a feature has both Type A and Type B elements, it may be appropriate to select a Type B because any safety activities required by Type A SMS will also be included within Type B SMS and to a greater level of rigour


IAN 139/11 of 266 Mar 11


– Stakeholders – Influence


Several Limited


Many Limited

or

Key Significant



Widespread UK

Limited UK

or

Some Overseas only

None Neither UK nor overseas




application


– Safety risk technology affects Low Medium High 4. Standards and Legislation

– Design covered by existing standards

– Departures from standards – Changes to legislation

All None None

Mostly Some None

No Many None

or

New standard Critical departures

Yes



No changes Minor changes/responsibility transfer Significant change or responsibility transfer

6. Project Scale – Infrastructure affected – Potential for wider roll-out




Table 2-1 for Work Instruction 001, Example Showing where a Project Feature can be Classified as More than One Type


IAN 139/11 of 266 Mar 11

Table 2-2 within this Guidance Document provides further assistance on classifying a project by:

Providing further clarification of the definitions for each of the project features Posing questions that should be considered during the categorisation process Describing what will usually be a typical Type A, B and C for each feature Providing guidance as to what may be an appropriate selection for Type A, B and

C features Project Scale and National Roll-out

When considering ‘project scale’ a distinction needs to be made between Pilot/Trial projects and the wider roll-out of a scheme following such a Pilot or Trial. Confusion can arise when it is known that such a Pilot or Trial is likely to be followed by a larger scale roll-out. Should the project be considered as just the Pilot/Trial or should the wider roll-out be considered too? The answer is that it depends on how the project is defined and must be assessed by each project individually. It is likely to be the case that when a project is genuinely a Trial, in other words after implementation there will be a period of assessment and possible re-design, before any further roll-out is initiated, then the Trial would be best considered in isolation with respect to project scale. If, on the other hand, the first roll-out is expected to be followed by much wider roll-out with little or no modification to the project, then the scale may be better considered in terms of the complete roll-out. It may be helpful for a project to consider both possible project scale options and see whether there is any impact on the SMS selected. Documentation of this activity could then assist the project in the future, one the initial Pilot/Trial is complete. The HA document ‘The Guide for Pilots and Trials’ provides further guidance on the approach to Pilot and Trial projects.


IAN 139/11 of 266 Mar 11

Project Feature Feature Questions to be Considered Feature Requirement Indicators for Selecting Type A, B or C Type A A ‘Type A’ will represent projects where few stakeholders are expected to have a significant impact (i.e. none of whom are ‘key’) and there are no significant issues or strongly opposing views to be addressed. Type B A ‘Type B’ will represent projects that have only a single or a few stakeholders but their impact may be significant. Alternatively it will represent a project that has several stakeholders but the amount or types of issues involved are limited.

1. Stakeholder Interest The degree of interest that an individual or group have in the success of the project Stakeholders can be both internal and external. Internal stakeholders can be considered as those within the HA or contracted by the HA e.g. the Project Manager, the project team members, the associated operations staff. External Stakeholders are people outside the HA such as the emergency services, local authorities, breakdown support organisations such as the AA and RAC and people who live nearby

Which groups/individuals can be considered as stakeholders?

How many stakeholders are there? What kind of influence does each of

the stakeholders have? Which stakeholders have the most

influence? Are there any key stakeholders on

which project ‘go ahead’ depends?

The projects needs to demonstrate to stakeholders that safety issues, as they perceive them, are well understood and will be fully addressed

Type C A ‘Type C’ will represent a project where stakeholder impact will be significant, either owing to the large number involved, the impact of the project on key stakeholders, or conflicting needs arising that will need to be addressed.


IAN 139/11 of 266 Mar 11

Project Feature Feature Questions to be Considered Feature Requirement Indicators for Selecting Type A, B or C Type A A ‘Type A’ will represent Projects for which there is significant operational experience and will therefore be less likely to require major safety studies or risk assessments. Previous safety studies should be available, and some project features might have been codified in a standard. Type B A ‘Type B’ is applicable to projects for which there is either limited operational experience in the UK, or some overseas which is deemed sufficiently similar to the project in question to be relevant. In this case, some additional safety work is likely to be required. There may also be local and site specific issues to take into account that could affect the relevance of the available operational experience.

2. Operational Experience The degree of knowledge available from operating or running a similar project

Is there operational experience available from previous projects?

How similar is the operating environment of the previous project?

Is the experience local to this project or to somewhere else in the UK?

Where there is previous experience, does it mean that Grandfather Rights may apply to some aspects of safety approval?

If there is no relevant UK experience, is there relevant experience overseas?

The projects needs to demonstrate that the risks associated with the operation that will be introduced are sufficiently understood and mitigated

Type C A ‘Type C’ will represent projects for which there is no previous experience. These projects will need a more robust SMS to support the more detailed safety analysis work that will be required.


IAN 139/11 of 266 Mar 11

Project Feature Feature Questions to be Considered Feature Requirement Indicators for Selecting Type A, B or C Type A A ‘Type A’ project will represent a project where the technology involved is currently in widespread use or limited/no technology will be introduced by the project. Re-examination is unlikely to be needed. Type B For ‘Type B’ projects there may be some experience of the technology, but from use in either another application or perhaps from overseas in which case some additional work may be required to demonstrate that safety can be assured for the intended application.

3. Technology Measure of technical novelty the project brings

Has the technology associated with the project been applied elsewhere?

If so, how was the technology applied elsewhere?

How effective has the technology been?

Are previous risk assessments associated with the technology available?

Will there be any modifications to the technology for the proposed project that have not yet been applied on previous projects?

Where technology novel or new to the highway is used, its operation must be understood and appropriately tested to ensure that risk levels are not adversely affected

Type C ‘Type C’ projects are those that will use a new technology for which there is no previous experience in the UK or elsewhere and extensive safety assessments are likely to be required.


IAN 139/11 of 266 Mar 11

Project Feature Feature Questions to be Considered Feature Requirement Indicators for Selecting Type A, B or C Type A For a Type A project the work involved is substantially or entirely covered by existing standards. No changes in legislation will be required and there will be no safety related departures from current standards. Type B For a Type B, the design will be largely or entirely covered by existing standards however there may be some minor changes to existing legislation required and/or a few significant safety related departures may be needed. It may also be the case that new HA guidance is available which will need to be considered.

4. Standards and Legislation

Consideration as to the applicability of current standards and legislation and to whether new standards or changes in legislation will be required

Is the project covered by existing standards?

Will the project require significant safety related departures from existing standards?

In order to implement the project will a change need to be made to existing legislation? What is the extent of this change?

What legislation (if any) imposes additional safety related duties on the project?

Has legislation affecting this project changed?

Have any safety related projects standards that affect this project changed?

Is there any available HA guidance on the project?

A project needs to demonstrate that the interventions it will introduce and the means by which it will deliver these interventions are covered by standards and legislation

Type C ‘Type C’ projects will represent more novel projects that are not covered by existing standards. Any project that does not conform to existing legislation, or may require new legislation, should be classified as ‘Type C’, as it is likely that a strong case for safety would need to be made to support a change to legislation. A Type C characterisation will also be needed when new legislation is created that imposes additional safety related duties on a project which did not previously exist. While the number of safety departures from standard may affect the classification the nature and type of a given departure is the most important element in determining characterisation. A large number of safety departures that can be addressed straightforwardly will have less impact on feature Type than a single safety departure that requires a detailed risk assessment to support it.


IAN 139/11 of 266 Mar 11

Project Feature Feature Questions to be Considered Feature Requirement Indicators for Selecting Type A, B or C Type A ‘Type A’ projects will apply to many projects and they have no impact on the organisation of the HA.

Type B ‘Type B’ projects will apply to projects where minor organisational changes will occur. However, new roles and responsibilities and organisational arrangements would need to be defined, as would competency, training requirements, recruitment needs and the way that responsibility would be transferred when the new roles are introduced.

5. Impact on Organisation The effect that the project will have on the current Agency organisational arrangements and in particular and changes in roles and responsibilities

Will the project have an impact on the organisation of Agency operations?

Will the project have an impact on the maintenance activities carried out on affected infrastructure?

Will the project require changes to organisational structure or changes to the safety organisation?

Will any new responsibilities be required?

What are the competency requirements for the project? Are they currently covered?

Will new staff need to be recruited? Will the project have a different

impact on the organisation as it progresses through the life cycle? What will these changes be?

A project needs to demonstrate that the impact of the project on the organisation are fully understood and accounted for.

Type C ‘Type C’ projects will represent projects requiring major changes in organisational arrangements and more particularly a change in core safety roles and responsibilities. Demonstration that they will deliver an adequate safety performance will also be required.


IAN 139/11 of 266 Mar 11

Project Feature Feature Questions to be Considered Feature Requirement Indicators for Selecting Type A, B or C Type A Projects that involve either a single or limited number of locations, or where the affected infrastructure/interventions are limited in nature, can expect to be categorised as Type A.

Type B For projects which are concerned with larger, major locations with larger implications. There will only be a moderate scale roll-out. Such projects will be classified as Type B.

6. Project Scale Consideration of the size of the project to be implemented

What infrastructure will be affected by project implementation?

Will the project have a local/regional/national impact?

Is the project a Pilot or Trial?1 Does the project involve the wider

roll-out of a previous Pilot/Trial/local project?

Is there potential for wider roll-out of the project?

Is it possible to group each small project into one? For example, can routine maintenance activities be grouped as one single project with a single SMS being applied?

A project needs to ensure that adequate safety measures are taken in proportion to the scale of the project.

Type C A large project is likely to affect a large number of people and will therefore be associated with a large potential impact on risk. For these large projects, more comprehensive risk analysis may be justified. Such projects would be classified as ‘Type C’.

Table 2-1 Guidance on Characterising Project Features

1 For the application of Work Instruction 001, Pilots and Trials are to be treated differently from the roll-out of a scheme. Pilots and trial projects are usually conducted on a more

localised scale whereas the roll-out of schemes will be conducted on a much wider scale, possibly national. Pilots and Trial projects may therefore require a less rigorous SMS

approach


IAN 139/11 of 266 Mar 11

2.3 Apply SMS Selection Rules Each of the project features are categorised as one of three Types – A, B or C. The way in which all project features are categorised determines the overall SMS that is selected. The rules given in Table 2-2 of Work Instruction 001 will cover the majority of projects in terms of selecting an SMS once features have been characterised. However, it is not possible to provide rules that cover all combinations of feature Types for all projects, as the impact of one particular feature on one project may have a different influence on another, owing to the individual circumstances of each project. Therefore there will be occasional circumstances where project specific factors will need to be taken into account. These will include occasions where one or two features are ‘C’. If the project considers these factors to sufficiently important, then the SMS selected should be Type ‘C’. Alternatively, the project may be classified as ‘Type B with Type C issues’. Once the SMS selection process has been implemented and used by a number of projects, a list of standard project categorisations will become available which can be used to aid in the SMS selection process by providing direct comparisons with other projects. Projects that Do not Match the SMS Selection Rules The most frequent cases of projects that do not match with the rules given in Table 2-2 of Work Instruction 001 will be where one or two features are classified as leading to a more onerous SMS than the others, for example two features are Type C and the other four are Type B. It then becomes a project decision as to whether to choose a Type B SMS, Type B with Type C issues, or Type C. The steps to follow in making this decision are as follows: Assess the particular contribution that the features assessed as Type C make to this

project. How crucial are they? Are they central to what the project is trying to achieve? If no clear arguments emerge in respect of the previous point, consider whether to bring

in external support in making this decision If there is still no clear view as to whether to go for the less onerous or more onerous

SMS then select the more onerous (i.e. C over B and B over A) Efforts should be made to see whether the more onerous SMS is really required because of the additional expense that will be involved in applying it. 2.5 Documenting Results of the SMS Selection Process An outline description as to what should be captured in the documented output of the SMS Selection Process is given in the table below:


IAN 139/11 of 266 Mar 11

Section Reference Content Guidance 1. Introduction The introduction of the report should provide a brief overview of the project

being considered and of what is included within the report

1.1 Project Background It is useful for the Project Background to include details such as: The location of the project and the position of the project within the context

of any wider project programme that may be carried out The main design features of the project The reason why the project is being considered for implementation

1.2 Purpose of the Report

This should clearly state that the report is documenting the results and reasoning behind the Project Safety Risk management SMS Selection Process

2. Selecting a SMS The purpose of this section is to describe how the project features have been categorised and the reasons behind the decisions made

2.1 Review Project Scope Definition

This section is to define the functionality and interventions that the project scheme will deliver. This will include reference to the points made in Section 2.12 of this guidance and the corresponding section within the Work Instruction

2.2 Classify Project Features

This section should include a list of the project features highlighting how they have been classified. It may be useful to include the ‘Characterising Project Features’ table (Table 2-1 in Work Instruction 001), highlighting the selections made

3. Implications/ Conclusions of the SMS Selection

This section needs to include clear reasoning behind the decisions made in classifying the project features and the choice behind the SMS selected for the project. This will include a reference to the applicable rule (Section 2.3.1, Work Instruction 001) being applied

4. Assessment Review

This section should provide some indication as to when during the development cycle the project will be reviewed. As the project design develops, features may be reclassified. This will have an impact on the safety management system and the activities involved in delivering the project safety report. It is important that this is reassessed continually. The results of the reviews also need to be documented, either as new reports or as extensions to the initial report

Table 2-3 Outline Content for SMS Selection Report The content of the SMS Selection Report will depend on which SMS Type has been selected. The material identified Table 2-3 represents what would be required for a Type C SMS. Considerably less would be needed for a Type A SMS. Outline requirements are given below:

A Type A SMS - will usually only require a brief (less than one page) summary and will form the basis for a brief Safety Report

A Type B SMS – will require a more detailed summary of the outcome of the process, but will not necessarily require a standalone report. It may be more appropriate to include the results in the Safety Plan

A Type C SMS – may require a standalone SMS Selection Report which will eventually be included within the Safety Strategy and Plan

This variation in documentary requirements is reflected throughout the SMS and holds true particularly for the final deliverable, the Safety Report. All projects need to produce a Safety Report but its size and complexity will vary greatly. For example, for a Type A project many safety requirements may be satisfied by CDM, so the safety documentation need only record the outcome of the application of WI 001 and may be a document that is one or two pages in length. Section 5 provides a report template for the SMS Selection Report. 2.6 Approval of the Deliverable No further guidance is provided – all required information is within the Work Instruction itself.


IAN 139/11 of 266 Mar 11

3 WHEN TO APPLY THE SMS SELECTION PROCESS 3.1 Application as Part of the Project Lifecycle The exact number of times Work Instruction 001 needs to be applied will vary depending on the nature of the project although fewer applications will be required for projects with a Type A SMS, where a single application will generally be sufficient. Initial Application Applying the SMS selection process during the early stages of the project lifecycle e.g. during the Options Phase is of particular benefit as it is around this time that many important decisions in respect of the project will be taken. The outcome of the SMS selection process can be used to further inform these decisions. If an initial application of Work Instruction 001 results in a Type A project classification, indicating that a basic level of safety management needs to be applied, it is likely that minimum costs will be incurred and limited resources required in order to satisfy the Type A SMS requirements. If however the initial application of Work Instruction 001 results in a Type C project classification, indicating that a more rigorous safety management system will need to be applied, satisfying the SMS requirements will have a bigger impact on the overall project cost and an increased level of resources will be required to support the relevant SMS activities. Application of Work Instruction 001 therefore forms a part of the value management activity that is required for a project. It is not always necessary to have assessed in detail what SMS activities are required, but it is necessary to know whether the SMS needed is of Type A, B or C. Further Applications For all types of projects a further application of the SMS selection process is required once the investment decision has been made to proceed. This acts as a check to make sure that the SMS approach, associated costs and resource requirements still remain valid. It will usually be the case that Type C projects require the greatest number of applications owing to the complexity of the projects. Such reapplications are needed if there is a significant change to the project. Examples of such changes include:

A change in the project design to be implemented Alterations to how the project will operate Changes in the way that staff will be used to support operation and maintenance

of the project Example: Reapplication of Work Instruction 001 during the Project Development Stage During the Project Development Phase e.g. during the detailed design stages new design decisions are being made which may result in changes to the initial preliminary design proposal. For example, a decision made to change the type of technology being introduced by a project from one which is novel to one which is already proven in use will have an impact on the project feature classifications in Table 2-1 of Work instruction 001. The ‘Technology’ project feature and the ‘Standards and Legislation’ project feature originally classified as Type Cs may now be newly categorised as Type Bs. This change will have an impact on the SMS to be applied, reducing the amount of rigour required for the overall project SMS.


IAN 139/11 of 266 Mar 11

If the SMS requirements do change, then such changes need to be documented and approved by the project’s internal stakeholders. Figure 3-1 (below) shows that Work Instruction 001 is expected to be applied during the Options and Development Phases of the Project Lifecycle, using Project Control Framework (PCF) terminology.

Safety Baseline & Objectives

Safety Plan

Hazard Identificationand

Risk Assessment

Verification

Safety Report

Validation

Update Project Safety Documentation

Apply Work Instruction 001

Apply Other Work Instructions

Options Phase

DevelopmentPhase

Construction Phase

Project Lifecycle

Hazard Log

Operation


Safety Plan


Risk Assessment

Verification

Safety Report

Validation



Apply Other Work Instructions

Options Phase

DevelopmentPhase

Construction Phase

Project Lifecycle

Hazard Log

Operation

Figure 3-1 Application of Work Instruction 001 During the Project Lifecycle


IAN 139/11 of 266 Mar 11

3.2 Application During Options Selection Refer to Appendix B of the Guidance for more information in respect of options risk assessment activities and the application of the Work Instructions during these activities. It is the project’s decision to make as to whether the Work Instructions should be applied at the Options Selection stage. Application of Work Instruction 001 at this point in time can be useful in that it is possible to get some form of indication as to the type of SMS likely to be required by each project option. This information can in turn help inform project decision making. Determining the type of SMS provides an indication of the cost and resource implications associated with further development and implementation of each project. The degree of rigour with which a project wishes to apply with Work Instructions may depend on how much safety is an influencing factor. For example, the project may wish to consider the following:

Whether the project is a safety project or is being implemented primarily for other reasons e.g. maintenance projects

The potential impact on both road user and road worker safety the project will have e.g. the influence the project may have on driver behaviour

3.3 Ongoing Documentation of Selection Process Application Any changes as a result of further applications of Work Instruction 001 shall be documented within the original deliverable (see section 3.4 of Work Instruction 001). Once this has been updated the documentation should be re-submitted to the key internal project stakeholders, including the Project Manager, for approval. 3.4 Transfer of Ownership Example: Transfer of Ownership on Commencement of Project Operation On commencement of operation, project ownership will generally transfer from Major Projects Directorate (MPD) to NDDD (Network Delivery & Development Directorate) and TMD (Traffic Management Directorate) and with it, ownership of the safety work. The new project owners should be involved in the safety work at as early a stage as possible so that the transition of ownership is smooth and to make sure that the safety work is well understood and managed appropriately following transfer. Overall responsibility for the safety work, including application of the SMS, will remain with the new project owners until project decommissioning. At the decommissioning stage, any safety work that has been undertaken can form the basis for the safety work of replacement projects. 1. ESTABLISHING THE PROJECT ARRANGEMENTS FOR SAFETY ACCEPTANCE AND APPROVALS No further guidance is provided – all required information is within the Work Instruction itself. 2. APPROVING THE PROJECT SMS No further guidance is provided – all required information is within the Work Instruction itself.


IAN 139/11 of 266 Mar 11

4 ADDITIONAL GUIDANCE (1) – APPLICATION OF WORK INSTRUCTION 001 WORKED EXAMPLES

This section of the Guidance provides worked examples in order to demonstrate how Work Instruction 001 is to be applied. The following three examples are used: Project 1 - Introduction of Access Management to an ATM (Active Traffic Management)

Scheme Project 2 - Strengthening Bridge Piers Project 3 – Provision of Traffic Officers in the West Midlands It is recommended that while working through the examples direct reference is made to the relevant sections of Work instruction 001 4.1 Project 1: Introduction of Ramp Metering to an ATM (Active Traffic

Management) Scheme 4.1.1 Project Background Ramp metering is any type of intervention that manages the throughput of traffic, or a certain class of traffic, from one road to another. One application is to reduce disruption to motorway traffic flows caused by traffic entering from slip roads and to maintain sustainable flows on the main motorway. For the ATM scheme on the M42 these interventions can also be used to control access to the motorway in order to minimise the level of increased traffic that may start using the motorway once an improvement in flows is evident. It has therefore been proposed that ramp metering should be installed on the on-slips at junctions 4, 5 and 6 of the M42 motorway during the operation of three-lane Variable Speed Limits (VSL). 4.1.2 Step 1: Review of Project Scope Definition (Section 2.1, Work Instruction 001) The scope of Project 1 has been analysed and a summary of the definition is given below. Section 2.1 of this Guidance document has been used as a guide:

The carriageway and associated infrastructure that will be affected by project implementation including the extent of the complete network

– On-slips at junctions 4, 5 and 6 of the M42 motorway – Traffic flowing between junctions 4-6 on the M42 – Additional traffic lights on on-slips – Traffic on roundabouts leading to affected on-slips

Any technical equipment that will be introduced or changed – Detection of traffic flows on M42 between affected junctions – Monitoring of traffic backing up on on-slip

The people involved in the operational aspects of the project and the impact the project will have on them

– Those involved in RCC monitoring usage The people involved in the maintenance of the project and the impact the

project will have on them – Maintenance of new equipment that was been introduced (additional

telematics to what is currently present)


IAN 139/11 of 266 Mar 11

The operational procedures that will be implemented/are affected – New operational procedures needed for implementation of ramp metering

The maintenance regimes that will be implemented/are affected – Maintenance of equipment on on-slips and approach to doing so

The above provides a brief overview of project scope definition as this is an illustrative example only. In reality, as much detail as possible should be documented. 4.1.3 Step 2: Classifying Project Features (Section 2.2, Work Instruction 001) Table 4-2 shows the pre-determined list of project features (as defined in Table 2-1, Work Instruction 001). Using the guidance contained within this document (Section 2.2) the terms highlighted show the project feature selections made for this project. Table 4-3 describes the rational behind the decisions made. 4.1.4 Step 3: Selecting the SMS (Section 2.3, Work Instruction 001) In summary the following categorisations have been made for each of this project’s features:

Project Feature Categorisation 1. The number and level of influence of stakeholders B 2. The extent and locations of previous operational experience B 3. The current experience of, and safety risks associated with, the use of any

technology being introduced A

4. The current status of standards and legislation with respect to the project B 5. The impact that the project will have on existing organisational arrangements B 6. The project’s overall scale B

Table 4-1 Summary of Feature Categorisations Now, consider the rules for selecting the SMS Type as described in Section 2.3.1, Work Instruction 001: The rule that applies in this case is: ‘Three or more project features are of Type B and a minority are Type A’ Implication: The SMS is of Type B, therefore apply Work Instruction 003.


IAN 139/11 of 266 Mar 11




Several Limited


Many Limited

or

Key Significant

or Several Major/ critical


Widespread UK

Limited UK

or

Some Overseas only





application


– Level of Safety risk that introduced technology affects

Low Medium High





None

Mostly Some/Few Significant

Minor changes only

No Many Significant

Moderate

or


Significant








Table 4-2 Classifying Project Features for Project 1 (Access Management)


IAN 139/11 of 266 Mar 11

Feature Results for project Stakeholder interest Type B. Motorway users on the M42 J3a–7 would be one group of stakeholders. However, it is unlikely that their interest

and influence on the project would be significant Other stakeholders include: The Area Liaison Group (a forum hosted by the NEC including representatives from Birmingham Airport, International

Station, the NEC, Virgin Trains, the NTCC, Local Authority, the Police, other emergency services, Amey Mouchel and others)

Local residents (who would be affected by changes in traffic patterns on the urban network), although influence and interest will probably be limited

The Department for Transport (will become involved in discussions around the application of reduced red/amber and amber periods for slip road signals). They will have significant influence

Additional groups include the adjoining Local Authorities traffic managers, the Area 9 team and the Highways Agency’s Integrated Traffic Management (ITM) who are to determine whether traffic signals at Junctions 4 and 6 can be adjusted to limit traffic entering the slip roads to existing levels

Operational experience Type B. There has been some operational experience in the UK of this scheme e.g. the schemes operating in North West of England It is also possible to draw on experience from other countries e.g. the US, France and Holland

Technology Type A. Standard technology will be used. There will not be any novel technology for this scheme Standards and legislation Type B. The project scheme will already be covered by legislation, however the implementation for ATM will be slightly

different as it will include ramp management (to control entry onto the motorway to agreed levels), and it is intended to implement it at 50mph, rather than the normal maximum threshold of 43mph. Specific guidance does not exist for implementing ramp metering at 50mph, however it can be derived from existing guidance

Impact on Organisation Type B. Ramp metering will be automatic, although the Regional Control Centre (RCC) will be able to switch it off. Ramp management would need to be implemented by the RCC, and would need monitoring for queuing beyond the on slip onto the junction, with the potential to cause queuing at the off slip if the junction becomes significantly congested. As a result of the impact on the RCC, this feature is categorised as Type B

Project Scale Type B. The project will affect all of the roads around which the highway that is being controlled. After the introduction of the four-lane VSL intervention, the signals providing ramp management will limit the traffic that can utilise the slip roads during the peak periods to existing flows, but any increase in demand will be held back on the slip roads and this may cause congestion on the roundabouts with knock-on effects on the main carriageway and the local road network

Table 4-3 Reasoning for Project 1 (Access Management) Classification Decisions


IAN 139/11 of 266 Mar 11

4.2 Project 2: Bridge Pier Strengthening 4.2.1 Project Background A bridge’s piers were damaged by an HGV impact and subsequent fire. The piers have been temporarily repaired but need to be strengthened permanently to reach current standards. 4.2.2 Step 1: Review of Project Scope Definition (Section 2.1, Work Instruction 001) The scope of Project 2 has been analysed and a summary of the definition is given below. Section 2.1 of this Guidance document has been used as a guide:

The carriageway and associated infrastructure that will be affected by project implementation including the extent of the complete network

– The bridge in question – Carriageway running over the Bridge – Traffic on the carriageways passing over and under the Bridge

Any technical equipment that will be introduced or changed – None

The people involved in the operational aspects of the project and the impact the project will have on them

– Those involved in RCC roadwork operation

The people involved in the maintenance of the project and the impact the project will have on them

– Maintenance of bridge pier same as currently – no change

The operational procedures that will be implemented/are affected – None

The maintenance regimes that will be implemented/are affected – Maintenance of bridge pier same as currently – no change


Project Feature Categorisation 1. The number and level of influence of stakeholders A 2. The extent and locations of previous operational experience A 3. The current experience of, and safety risks associated with, the use of any


4. The current status of standards and legislation with respect to the project A 5. The impact that the project will have on existing organisational arrangements A 6. The project’s overall scale A

Table 4-4 Summary of Feature Categorisations


IAN 139/11 of 266 Mar 11

Now, consider the rules for selecting the SMS Type as described in Section 2.3.1, Work Instruction 001: The rule that applies in this case is: ‘All of the project features have been classified as Type A’ Implication: The SMS is of Type A, therefore apply Work Instruction 002.


IAN 139/11 of 266 Mar 11




Several Limited


Many Limited

or

Key Significant


2. Operational Experience

– Extent – Where

Widespread UK

Limited UK

or

Some Overseas only





application



Low Medium High





None


No Many significant

Moderate

or


Significant








Table 4-5 Classifying Project Features for Project 2 (Bridge Pier Strengthening)


IAN 139/11 of 266 Mar 11

Feature Results for project

Stakeholder interest Type A. Expect stakeholder interest to be relatively limited from a safety perspective, although the disruption to traffic while the project is in progress may result in raised interest from local road users and other organisations

Operational experience Type A. The strengthening of piers that are known to be weaker than the new standard is common practise. Should be widespread

Technology Type A. No technology/Limited technology likely to be deployed Standards and legislation Type A. The design is already covered by exiting standards and legislation.

It does not involve any departures Impact on Organisation Type A. There will be no changes or organisational effects Project Scale Type A. The project is only being carried out in one signal, small location

Table 4-6 Reasoning for Project 2 (Bridge Pier Strengthening) Classification Decisions 4.3 Project 3: Provision of Traffic Officers in the West Midlands 4.3.1 Project Background The Agency Roles and Responsibilities (R&R) Programme introduced changes in the responsibility for incident and safety management related services on England’s strategic road network. The Agency took over some non-crime related services currently provided by the Police, through the introduction of Traffic Officers and HA operated Regional Control Centres (RCCs). The introduction of Traffic Officers was implemented in the West Midlands first, followed by a wider roll-out of the service. 4.3.2 Step 1: Review of Project Scope Definition (Section 2.1, Work Instruction 001) The scope of Project 3 has been analysed and a summary of the definition is given below. Section 2.1 of this Guidance document has been used as a guide: The carriageway and associated infrastructure that will be affected by project

implementation including the extent of the complete network – All carriageway and infrastructure covered by the Governmental region of the West

Midlands

Any technical equipment that will be introduced or changed – None

The people involved in the operational aspects of the project and the impact the project will have on them – Police, Traffic Officers and RCC workers within the area

The people involved in the maintenance of the project and the impact the project will have on them – Maintenance – no change

The operational procedures that will be implemented/are affected

– Traffic Officers provided with some of the necessary powers for taking on further services from the Police e.g. stopping and directing traffic and placing temporary traffic signs

– Traffic Officers enabled to authorise exceptions to the Motorway Traffic Regulations and remove, store and dispose of certain vehicles

– New Traffic Officer and RCC operator procedures required for these processes, and updates to other procedures required

The maintenance regimes that will be implemented/are affected

– Maintenance same as currently


IAN 139/11 of 266 Mar 11


Project Feature Categorisation 1. The number and level of influence of stakeholders C 2. The extent and locations of previous operational experience C 3. The current experience of, and safety risks associated with, the use of any


4. The current status of standards and legislation with respect to the project C 5. The impact that the project will have on existing organisational arrangements C 6. The project’s overall scale B/C

Table 4-7 Summary of Feature Categorisations Now, consider the rules for selecting the SMS Type as described in Section 2.3.1, Work Instruction 001: The rule that applies in this case is: ‘Three or more project features have been classified of Type C’ Implication: The SMS is of Type C, therefore apply Work Instruction 004.


IAN 139/11 of 266 Mar 11




Several Limited


Many Limited

or

Key Significant



Widespread UK

Limited UK

or

Some Overseas only





application



Low Medium High





None


No Many significant

Moderate

or

New standard Some Critical

departures Significant








Table 4-8 Classifying Project Features for Project 3 (Introduction of Traffic Officers)


IAN 139/11 of 266 Mar 11

Feature Results for project

Stakeholder interest Type C. This was a new concept for the HA and therefore was expected to receive additional scrutiny from a range of stakeholders. These included existing operational staff, police who are transferring responsibilities, the Agency board, driver representation organisations and driver rescue services (such as the AA and RAC). The Agency and the Police were Key stakeholders

Operational experience Type C. No previous experience of this project Technology Type A. No significant new technology introduced as part of this project Standards and legislation Type C. The procedures and processes for Traffic Officers were new, they

were taking on some of responsibilities of the Police. New procedures and amendments to current procedures were needed. Changes to legislation also required to give Traffic Officers the same responsibilities in some areas as the police. New approaches to operation, which may mean in turn that new operational standards will also be needed

Impact on Organisation Type C. There were large changes to the roles and responsibilities of Traffic Officers and requirements for more staff

Project Scale Type B/C. The project was being conducting in the West Midlands Area

Table 4-9 Reasoning for Project 3 (Introduction of Traffic Officers) Classification Decisions


IAN 139/11 of 266 Mar 11

5 ADDITIONAL GUIDANCE (2) – SMS SELECTION REPORT TEMPLATE

PROJECT SAFETY RISK MANAGEMENT WORK INSTRUCTION 001 DELIVERABLE

Results of Safety Management System Selection Process NAME OF PROJECT SUMMARY This report documents the outcome of the

application of Work Instruction 001 on Project X

DELIVERABLE APPROVER APPROVING PROCESS AND DATES TBD AUTHOR/FURTHER INFORMATION TBD LEAD DIRECTOR TBD VERSION 1 STATUS (Final/Draft) Draft DISTRIBUTION TBD REVIEW DUE DATE TBD ISSUED BY: TBD ISSUE DATE: TBD


IAN 139/11 of 266 Mar 11

Amendment History Date Version Modification Sections Affected TBD 1.0 Document Creation All


IAN 139/11 of 266 Mar 11

1 INTRODUCTION 1.1 Project Background Provide a summary which includes the following:

The current project lifecycle stage The location of the project and the position of the project within the context of

any wider project programme that may be carried out The main design features of the project The reason why the project is being considered for implementation

1.2 Purpose of Report This report documents the results of the application of Project Safety Risk Management (PSRM), Work Instruction 001, Safety Management System (SMS) Selection Process. 1.3 Approval of this Deliverable Approval of this deliverable has been obtained from the following project stakeholders:

Provide names of internal project stakeholders Provide the name of the Project Manager


IAN 139/11 of 266 Mar 11

2 SELECTING A SAFETY MANAGEMENT SYSYTEM (SMS) 2.1 Review of Project Scope Definition This section is to define the functionality and interventions that the project scheme will deliver. This will include reference to the points made in Section 3.1 of Work Instruction 001 and this Guidance document. It may also be appropriate to refer to additional documentation for example Project Feature Overview documents (if they exist for your project), construction drawings or tender design assumption documentation 2.2 Classifying Project Features Work Instruction 001 provides a list of the project features that must be characterised in order to understand what might be the most appropriate SMS for a project. These features are interpreted as requiring differing levels of safety management. The safety activities relate to the feature types as follows: Type A: Basic safety management needs to be applied. Note that even in this case, a

record shall be kept as to how the decision was reached, justifying the level of safety evidence that is to be recorded

Type B: A moderate level of safety management needs to be applied. Some kind of Safety Report will be needed and some level of risk assessment will need to be carried out

Type C: Rigorous safety management shall be applied. Records shall be kept of all activities undertaken, all decisions and their justifications shall be recorded and extensive risk assessment shall be carried out. A comprehensive Safety Report will be required

The feature classifications for this project are given in the table below.


IAN 139/11 of 266 Mar 11




Several Limited


Many Limited

or Key Significant



Widespread UK

Limited UK

or

Some Overseas only





application



Low Medium High





None

Mostly Some/Few significant

Minor changes only

No Many Significant

Moderate

or


Significant








Complete


IAN 139/11 of 266 Mar 11

2.3 Application of SMS Selection Rules The feature classifications are used to determine the type of SMS that must be applied to a project. Work Instruction 001 has a number of rules that can be used to define which SMS to apply in these circumstances. The applicable rule for this project is given in the table below. Select appropriate rule from the table below and delete those not applicable.

Project Feature Classifications

SMS Type Applicable Work Instruction(s)

Comments

All Type A Type A 002 Where all project features are classified as Type A then the entire SMS will be of Type A and all safety management activities are to be applied in accordance with Work instruction 002

All Type B Type B 003 Where all project features are classified as Type B then the entire SMS will be of Type B and all safety management activities are to be applied in accordance with Work instruction 003

All Type C Type C 004 Where all project features are classified as Type C then the entire SMS will be of Type C and all safety management activities are to be applied in accordance with Work instruction 004

3 or more Type B, remainder Type A

Type B 003 Where three or more project features are classified as Type B and the remainder are Type A, then the entire SMS shall be of Type B and all safety management activities are to be applied in accordance with Work instruction 003

3 or more Type C

Type C 004 Where three or more project features are classified as Type C then the entire SMS shall be of Type C and all safety management activities are to be applied in accordance with Work instruction 004

This means that the project has been determined as needing a Type X SMS, Work Instruction X is therefore to be implemented at this stage in the project lifecycle.


IAN 139/11 of 266 Mar 11

3 IMPLICATIONS AND CONCLUSIONS This section needs to include clear reasoning behind the decisions made in classifying the project features and the choice behind the SMS selected for the project. It is useful to summarise this in a table as shown below. The reasons for the feature selections are provided in the table project are described in the table below.

Feature Implications for project

Stakeholder interest TBC

Operational experience TBC

Technology TBC

Standards and legislation TBC

Impact on Organisation TBC

Project Scale TBC


IAN 139/11 of 266 Mar 11

4 ASSESSMENT REVIEW This section should provide some indication as to when during the development cycle the project will be reviewed. As the project design develops, features may be reclassified. This will have an impact on the safety management system and the activities involved in delivering the project safety report. It is important that this is reassessed continually. See section 2.1 of this guidance document for further information.

Interim Advice Note 139/11 Work Instructions 003: Managed Motorways Safety Risk Mangement for Projects with Type B Features Safety Risk Working Instructions

IAN 139/11 of 266 Mar 11

PART 3: (Not Used)


IAN 139/11 of 266 Mar 11

PART 4: (Not Used)


IAN 139/11 of 266 Mar 11

PART 5: WORK INSTRUCTION WI003

Safety Risk Management for Projects with Type B Features SUMMARY This document supports the Agency’s

HSMS. The document describes the safety management activities for MM projects that have been classified by Work Instruction 001 as requiring a Type B SMS

APPROVING PROCESS AND DATES H&S Programme Board – Awaiting Approval Performance, Delivery and Investment Group (PDIG) – Awaiting Approval HA Board – Awaiting Approval

AUTHOR/FURTHER INFORMATION NetServ Safety Risk Team/National Health and Safety Team


APPLIES TO MM projects classified as Type B/have Type B requirements

VERSION 1 STATUS (Final/Draft) Final THIS DOCUMENT REPLACES None – new document DISTRIBUTION Intranet REVIEW DUE DATE 2011



IAN 139/11 of 266 Mar 11

Contents 1 Introduction 68 1.1 Background 68 1.2 Objective 68 1.3 Scope 68 1.4 Implementation 68 2 Summary of Safety Risk Management Activities 69 3 Safety Baseline & Safety Objectives 72 3.1 Objective 72 3.2 Requirements 72 3.3 Deliverable 73 4 Safety Plan 74 4.1 Objective 74 4.2 Requirements 74 4.3 Deliverable 74 5 Risk Assessment Activities 75 5.1 Objective 75 5.2 Requirements 75 5.3 Deliverables 75 6 Hazard Log 77 6.1 Objective 77 6.2 Requirements 77 6.3 Deliverable 77 7 Verification And Validation 78 7.1 Objective 78 7.2 Requirements 78 7.3 Deliverables 78 8 Safety Report 79 8.1 Objective 79 8.2 Requirements 79 8.3 Deliverables 79 9 Updating Safety Documentation During Operation 80 9.1 Purpose 80 9.2 Requirements 80 9.3 Deliverables 80

10. Safety acceptance and proposals 81

APPENDIX A: REFERENCES 84 APPENDIX B: DEFINITION OF TERMS 85

APPENDIX C: ABBREVIATIONS 86


IAN 139/11 of 266 Mar 11

1 INTRODUCTION 1.1 Background This document is Work Instruction 003 - Safety Risk Management for Projects with Type B Features. It forms part of a suite documents (Work Instructions 001, 003 and 004 and associated Guidance) that set out the requirements for safety risk management for all MM projects as part of the Agency’s Health and Safety Management System (HSMS). 1.2 Objective The objective of this Work Instruction is to describe the required safety risk management activities for MM projects requiring a Type B Safety Management System. 1.3 Scope This Work Instruction applies to all MM projects where the application of Work Instruction 001 has shown that Type B safety management is required. 1.4 Implementation This Work Instruction is applicable to all MM projects where Type B SMS activities are appropriate. All MM projects shall follow the Construction (Design and Management) Regulations 2007 (CDM 2007) and will be able to demonstrate that they have done so. Adherence to this Work Instruction in all areas of project development should address CDM 2007 Designer responsibilities (as set out under Regulation 11). All MM projects shall also follow all other relevant existing HA project processes, such as the Departures and Road Safety Audit processes. It is not necessary to repeat any risk assessment activity carried out in following this Work Instruction in order to comply with the requirements of any other project processes; neither is it necessary to repeat work carried out under any other project processes to comply with this Work Instruction. Wherever an existing piece of safety work is available for a project, it shall be assessed for how well it meets the requirements of this Work Instruction. If deemed acceptable, those aspects that it covers need not be repeated as part of fulfilling this Work Instruction. This point is of particular relevance to any existing risk assessments.


IAN 139/11 of 266 Mar 11

2 SUMMARY OF SAFETY MANAGEMENT ACTIVITIES Table 2-1 summarises the safety risk management activities for Type B projects.

Safety Management Activity Brief Description of Activity Reason for Carrying Out the Activity

Safety Baseline & Objectives Defining the current level of safety and the level which the project will work to achieve

A baseline is required in order to be able to measure achievement of the safety objective

Safety Plan Defining the specific safety activities that will be undertaken for the project

Supports the planning of safety activities and demonstrates that a defined safety management approach is being used

Risk Assessment Activities and Development of Hazard Log

Identifying potential hazards associated with the project and conducting appropriate risk assessments

Supports the identification of the hazards that will affect the project enabling them to be risk assessed and subsequently mitigated

Verification & Validation The processes to demonstrate that the project meets all of its safety requirements and to determine whether or not it fulfils its original intentions

Verification allows the project to demonstrate that project requirements have been met. Validation checks that the project design satisfies its intended purpose

Safety Report Documenting the safety work that has been carried out on the project

Provides documented evidence of if and how the project safety objectives were achieved

Updating Safety Documentation During Operation

Updates safety documentation to reflect any changes made once the project has commenced operation

Maintains documentation as accurate record of project status and records ongoing achievement of safety objectives

Table 2-1 Summary of Safety Risk Management Activities The above activities are shown diagrammatically in Figure 2-1 as a safety lifecycle, which also illustrates the interaction between the safety management activities and more general projects lifecycle activities. Figure 2-1 represents an idealised situation and some limited variations in its practical application are to be expected.


IAN 139/11 of 266 Mar 11


Safety Plan


Risk Assessment

Verification

Safety Report

Validation




Options Phase

DevelopmentPhase

Construction Phase

Project Lifecycle

Hazard Log

Operation


Safety Plan


Risk Assessment

Verification

Safety Report

Validation




Options Phase

DevelopmentPhase

Construction Phase

Project Lifecycle

Hazard Log

Operation

Figure 2-1 The Safety Risk Management Process for Type B Projects


IAN 139/11 of 266 Mar 11

The main deliverables produced as a result of applying this Work Instruction are:

Safety Plan Hazard Log and Hazard Log Report Safety Report

Through the course of applying this Work Instruction, projects may also identify discrete safety issues that require discussion and approval in order to allow the project to progress. The acceptance and approvals process for all project safety issues and deliverables arising from the application of this Work Instruction is defined in Section 10 of this Work Instruction. As the project progresses to construction and operation any changes made to the design must be analysed. The impact of these changes on each safety output shall be assessed and any updates required made. See Section 9 for details on safety documentation updates throughout the safety lifecycle and Section 10 for details on re-issuing the project Safety Report.


IAN 139/11 of 266 Mar 11

3 SAFETY BASELINE AND SAFETY OBJECTIVES 3.1 Objective The objective of setting a safety baseline is to define the level of safety against which the project safety objectives will be measured. The purpose of considering safety objectives is to establish the level of safety that the project will aim to deliver. 3.2 Requirements For Type B projects, the safety baseline and objective shall be defined in quantitative terms. Projects must consider the need to define separate safety baselines and objectives for the different parties affected by the project i.e. separate safety baselines and objectives for road users, construction operatives, Traffic Officers and/or 3rd parties. For some projects, it may be necessary to break these groups down further e.g. to split ‘road users’ into car drivers, LGV drivers, motorcyclists etc. The appropriate level of disaggregation for the safety baseline and objective will need to be decided on a project-specific basis. 3.2.1 Safety Baseline The safety baseline for parties affected by a Type B project will be either: The level of safety risk associated with the current situation at the proposed project site,

or The average level of safety risk for a similar section of road or similar activity to that

which the project will deliver 3.2.2 Safety Objectives Project safety objectives shall reflect: The need to meet established safety targets Any specific requirements of HA policy or standards to upgrade or renew infrastructure The requirements of Strategic and Area Safety Action Plans Any local/route-specific targets for casualty reduction or safety improvement measures For Managed Motorway projects, the safety baseline and safety objectives for road users will be identified through existing HA processes i.e. the Project Appraisal Report (PAR) and/or Technical Appraisal Report (TAR). Achievement of the safety objectives will then be assessed through the Post Opening Project Evaluation (POPE) process. Where projects are using all three elements of a Managed Motorway, namely Triple Package, Controlled Motorway and Dynamic Hard Shoulder, 15% safety benefits will be specified. Managing risks so that they are reduced So Far As Is Reasonably Practicable (SFAIRP) is a legal requirement of the Health and Safety at Work Act and so must be used as the safety objective for construction operatives and Traffic Officers. This approach must also be used for managing safety risks to road users and 3rd parties resulting from the activities of construction operatives and Traffic Officers. The project will be able to show that other hazards that may affect 3rd parties have been adequately mitigated.


IAN 139/11 of 266 Mar 11

3.3 Deliverable The deliverable will be a statement of the safety baseline and objectives for the different parties affected by the project. As a minimum, this shall include the following groups: Road Users Construction Operatives Traffic Officers 3rd parties Further disaggregation of these groups shall be considered on a project-specific basis. Where any of these groups is not affected by a particular project, this shall be documented. However the need for a baseline and objectives for all of these groups must be considered for all projects. The safety baselines and objectives will be documented within a ‘safety baseline & objectives’ section within the Project Safety Report. In some circumstances a separate safety objectives and baseline report may be needed but this will be a project specific consideration.


IAN 139/11 of 266 Mar 11

4 SAFETY PLAN 4.1 Objective The objective of the project safety plan is to describe the safety activities that will be undertaken as part of the SMS and how these activities will lead to the safety objectives being met. 4.2 Requirements The safety plan describes what the project will do in order to achieve the project safety objectives. For a Type B project it shall include a: Summary of the application of WI 001 Description of the project safety baseline and safety objectives Description of the project safety organisation, including who on the project has overall

responsibility for safety, plus a description of the process for sign-off of any safety decisions

Description of how the project safety objectives will be achieved, including a list of the main safety-related technical procedures to be followed as part of the project design, construction, operation, maintenance, emergencies and demolition

Description of the project approach to stakeholder consultation Brief description of the main safety challenges for the project 4.3 Deliverable The deliverable will be a project Safety Plan that addresses the requirements outlined in Section 4.2 above. A Safety Plan template is provided in the Appendices to this IAN.


IAN 139/11 of 266 Mar 11

5 RISK ASSESSMENT ACTIVITIES 5.1 Objective The objective of the risk assessment activities is to make sure all project safety hazards are identified and appropriately mitigated. 5.2 Requirements For Type B projects, this activity effectively ‘plugs the gap’ of existing standards and experience and makes sure that the project design and build includes appropriate controls for the safety hazards and risks associated with the project. The process of hazard identification and risk assessment will build on the results of any risk assessments carried out previously for the project. The starting point shall be to revisit this earlier work and review to see if there are any other hazards or risks that should be addressed as part of the design. The risk assessment shall consider safety hazards and risks to road users, construction operatives, Traffic Officers and 3rd parties separately. Details of the hazards, risks and associated controls identified as part of this hazard identification and risk assessment activity shall be recorded in a hazard log. Requirements for this are described in Section 6 of this document. All projects shall also: Record the detail of any risk calculations made, including any underpinning assumptions

and any data sources Ensure that the risk assessment is performed by a competent person Outputs from this hazard identification and risk assessment activity must be included within any related applications for Departures from Standards (including Aspects not covered by Standards). In particular, they shall be used to satisfy the requirements of the Departures process to: Assess the benefits and adverse impacts (i.e. disbenefits) of a Departure Assess the hazards and risks associated with a design incorporating the Departure

(compared with a fully compliant design) Consider safety for all classes of road user, health and safety during Trunk Road Works

and effects on other persons 5.4 Deliverables For Type B projects the minimum requirement will be to document risk assessment activities within the Project Safety Report. In some cases, a specific Risk Assessment Report may also be needed but that will be a project specific consideration. Documentation of risk assessment activities will include: The main safety hazards and risks for different parties affected by the project The main assumptions underpinning the risk assessment Summary of the main decisions made about how the project design controls safety risk

and the basis for these decision Summary of the main residual risks associated with the project and justification for the

tolerability of these risks Key parameters/safety risk controls to be monitored into the future


IAN 139/11 of 266 Mar 11

Where a separate risk assessment report is deemed necessary it will provide further detail of: The risk assessment itself (i.e. detailed calculations) Data sources Assumptions and limitations The results obtained (i.e. discussion of the results and any sensitivities)


IAN 139/11 of 266 Mar 11

6 HAZARD LOG 6.1 Objective The objective of the Hazard Log is to provide a means of recording all hazard related information and tracking all hazards that are identified in a project through to their successful resolution. Resolution in this instance may be regarded as demonstrating that necessary mitigation has been identified and subsequently applied to the hazard. 6.2 Requirements The hazard log is a live document that shall be regularly reviewed and updated throughout the project life cycle. It shall be the ‘single source’ of hazard and risk information for the project that is owned and used by the whole project team. The hazard log shall be set up as a controlled computer-based file in an application that can be readily shared with all project team members. For Managed Motorways projects a hazard log will be provided, pre-populated with hazards that are known to affect such schemes. It will be a project specific responsibility to complete the entry of required information into the hazard log, based on completion of the safety management activities outlined in this Work Instruction. Information from the hazard log shall then inform the project design. It shall also feed into the verification and validation exercise, as described in Section 7. Projects will also produce a Hazard Log Report, This will:

Provide documentary evidence that the relevant hazards have been identified and categorised

present the main hazards, mitigations, tasks and requirements identified from the hazard log

state progress towards achieving the scheme safety objective set out recommendations for any further actions that could enhance achievement of

the scheme safety objective

6.3 Deliverable A copy of the hazard log for the ‘as-built’ project shall be provided to the HA Project Manager when the project becomes operational. A Hazard Log Report template is provided in the Appendices to this IAN


IAN 139/11 of 266 Mar 11

7 VERIFICATION AND VALIDATION 7.1 Objective The objective of the project verification activities is to show that the project meets its safety requirements. The objective of the project validation activities is to determine whether the project satisfies the requirements of its intended use, which in this context is interpreted it to mean: Confirming whether the safety objectives are being achieved after operation has

commenced Confirming, also after operation has commenced, whether the assumptions made in

carrying out risk assessments are correct 7.2 Requirements 7.2.1 Verification Verification will be carried out by making sure that the project is delivered in accordance with the Safety Plan and by demonstrating that all the hazards in the hazard log have been mitigated to an appropriate level. The project executor shall review the actual project activities against the Safety Plan. If this identifies that any activities from the safety plan have not been completed, or have been completed but not in accordance with the plan, then this situation shall be reported back to the HA Project Manager and addressed as soon as practicable. In addition, any implications of non-compliance to date shall be identified and addressed through revisions to the safety plan or project design (as required). 7.2.2 Validation Validation activities aimed at determining whether the safety benefits anticipated by the project are being achieved in practice will be undertaken after an appropriate period of operation. For most projects, this will be covered through POPE (Post Opening Project Evaluation) activities. Validation activities aimed at confirming whether assumptions made within the risk assessments are correct will also be carried out after a suitable period of operation. The process for doing this will need to be designed to suit the particular requirements of individual projects. The findings from any validation activity shall be reported within the Safety Report. They shall also feed back into the safety objectives, safety plan, design and/or construction process, as appropriate. 7.3 Deliverables The deliverable will be a ‘verification and validation’ section within the Project Safety Report, summarising the details of any verification or validation exercise undertaken and the associated findings.


IAN 139/11 of 266 Mar 11

8 SAFETY REPORT 8.1 Objective The objective of the Safety Report is to summarise the evidence demonstrating whether or not the project safety objectives have been met. 8.2 Requirements The Safety Report will evolve over the life of the project to include: Executive summary – providing an ‘at a glance’ summary of what impact (if any) the

project had on safety risk for the different parties affected by it Background to the project The project safety baseline and objectives Summary of the project risk assessment activities Summary of the verification and validation activities undertaken and the associated

findings For Type B projects, the Project Safety Report shall be supported by: Risk assessment report (where this is deemed necessary) Hazard Log and Hazard Log Report These documents shall be referenced in the Safety Report. The Safety Report shall clearly identify those aspects of the project’s safety system that will become the responsibility of different parties once the project commences operation. For example, operation, technology and infrastructure. This is to ensure that those parties taking ownership of the project at operation have a clear understanding of the safety issues for which they are taking responsibility. 8.3 Deliverables The deliverable will be the project Safety Report. A copy of this must be passed to the HA Project Manager on completion of the project. A Safety Report template is provided in the Appendices to this IAN.


IAN 139/11 of 266 Mar 11

9 UPDATING SAFETY DOCUMENTATION DURING OPERATION 9.1 Purpose The objective of this activity is to ensure that the project safety documentation is kept up to date and remains an accurate reflection of how the project is currently being operated. Updating the safety documentation shall ensure an auditable trail of any safety-related changes that are made during operation. 9.2 Requirements For Type B projects, the project safety documentation will be the Safety Report, plus its supporting documents. The need for updates to any of these documents shall be considered in the event of any material changes to the way safety risk is managed once the project is in operation. In particular, if any new hazards are identified after the project becomes operational, or if the mode of operation changes in a way that affects any known hazards or risks, then the risk assessment and Hazard Log will be updated to reflect these changes and any corresponding changes to risk controls that will be introduced. Where different aspects of the operational project are the responsibility of separate parties (e.g. operation, technology, infrastructure) then the implications of any proposed change to one aspect of the project shall be discussed and agreed with other parties whose area of responsibility may also be affected by the change – before the change is introduced. This is to ensure that any safety related inter-dependencies are appropriately managed once the project has commenced operation. 9.3 Deliverables Deliverables will be updated version(s) of the project safety documentation, as required.


IAN 139/11 of 266 Mar 11

10 SAFETY ACCEPTANCE AND APPROVALS All project safety deliverables must be formally accepted and approved by the relevant parts of the HA. The first step in this process is to submit project safety deliverables to the PSCRG. For Type B safety management, safety deliverables can be endorsed directly by the PSCRG. However, if there are any aspects of the deliverable that the PSCRG feel are particularly contentious or complex, they can refer the deliverable to the NSCRG, along with a recommendation for how they feel the matter should be resolved. The NSCRG will then determine whether or not they agree with this recommendation and provide their response back to the project team. Once a project safety deliverable has been agreed through the process described above, it shall be submitted for formal acceptance and approvals as per the process shown in figure 10-1:

MP Project Manager




MP Project Senior

Responsible Owner

Project Consultant




IAN 139/11 of 266 Mar 11





The TMD Project Senior User accepts that, in relation to the project operating regime, the scope and content of the document are correct and fit for purpose given the current stage of the project



These responsibilities are reflected in the generic approvals sheet shown in Figure 10-2, which must be completed for all project safety deliverables, as a record of their progress through the safety acceptance and approvals process defined above.


IAN 139/11 of 266 Mar 11




Name ____________

Date _____________

Signature _____________

Project Consultant

(Project Director)

I confirm that:



Name ____________

Date _____________

Signature _____________






Name ____________

Date _____________

Signature _____________



Name ____________

Date _____________

Signature _____________



Name ____________

Date _____________

Signature _____________

Network Services





Name ____________

Date _____________


Major Projects





This approvals process shall also apply to any changes introduced to project safety documentation after operation has commenced. This is to ensure appropriate consideration and approval for the safety implications of any changes across all aspects of the project. In this situation, the ‘MP Project Manager’ and ‘Major Projects Senior Responsible Owner’ shall be substituted by the HA Project Manager and Senior Responsible Owner responsible for delivery the particular change.


IAN 139/11 of 266 Mar 11


[3] Managed Motorway Schemes, National Safety Control Review Group and Project Safety Control Review Groups, Remit for Organisation and Governance


IAN 139/11 of 266 Mar 11


Term Explanation Agency The Highways Agency Area Safety Action Plan HA document defining:

Area specific accident data Comparison with national trends Area progress toward safety targets

Hazard A source of potential harm Project Executor Person/organisation responsible for ‘executing’ the project Project Manager Person representing the Highways Agency’s interests on the project and

to whom the Project Executor reports Risk The combination of the likelihood and the consequence of a specified

hazard being realized. It is a measure of harm or loss associated with an activity

Risk Assessment The overall process of identifying, analysing and evaluating risk Safety Baseline Level of safety against which the project safety objectives are set and

measured Safety Management Activities Activities that comprise the project safety management system Safety Objective What the project is trying to achieve in terms of safety Safety Plan Plan describing the activities to be undertaken to achieve a safety

objective Safety Report A document describing the approach to safety management on the

project Strategic Safety Action Plan HA document describing the Agency’s action plan for reduction accidents

and casualties on the strategic road network Validation Safety management activity that aims to confirm any significant design

assumptions or uncertainties Verification Safety management activity that checks that a project is being

progressed in accordance with the Safety Plan


IAN 139/11 of 266 Mar 11


Abbreviation Definition HA Highways Agency CDM Construction (Design and Management) Regulations, 2007 HSMS Health and Safety Management System MM Managed Motorways PAR Project Appraisal Report POPE Post Opening Project Evaluation SMS Safety Management System TAR Technical Appraisal Report

Interim Advice Note 139/11 Guidance for Work Instructions 003: Managed Motorways Safety Risk Mangement for Projects with Type B Features Safety Risk Working Instructions

IAN 139/11 of 266 Mar 11


Safety Risk Management for Projects with Type B Features SUMMARY This Guidance is part of the Agency’s

HSMS. It provides guidance on how to meet the requirements for safety risk management for MM projects with Type B features

APPROVING PROCESS AND DATES H&S Programme Board – Awaiting Approval Performance, Delivery and Investment Group (PDIG) – Awaiting Approval HA Board – Awaiting Approval



APPLIES TO MM projects classified as Type B/have Type B requirements




IAN 139/11 of 266 Mar 11

Contents 1 Introduction 89 2 Summary of Safety Management Activities 90 3 Safety Baseline and Safety Objectives 91 3.1 Objective 91 3.2 Requirements 91 3.3 Deliverable 92 4 Safety Plan 93 4.1 Objective 93 4.2 Requirements 93 4.3 Deliverable 93 5 Risk Assessment Activities 94 5.1 Objective 94 5.2 Requirements 94 5.3 Deliverable 94 6 Hazard Log 95 6.1 Objective 95 6.2 Requirements 95 6.3 Deliverable 95 7 Verification And Validation 96 7.1 Objective 96 7.2 Requirements 96 7.3 Deliverable 96 8 Safety Report 97 8.1 Objective 97 8.2 Requirements 97 8.3 Deliverable 97 9 Updating Safety Documentation During Operation 98 9.1 Objective 98 9.2 Requirements 98 9.3 Deliverable 98 9.4 Timing 99

10. Safety acceptance and proposals 99


IAN 139/11 of 266 Mar 11

1 INTRODUCTION

Work Instruction 003 describes the requirements for a Type B approach to safety risk management. This document provides supplementary background information and explanation of the requirements stated in Work Instruction 003. It also provides guidance on: Where current processes should meet the requirements of Work Instruction 003 How to meet the requirements of Work Instruction 003 if they are not met by any current

processes Compliance with this Guidance document is not mandatory. However, if followed, compliance will ensure that the requirements of Work Instruction 003 are met. In this document, the phrase “No further guidance is provided – all required information is within the Work Instruction itself.” means that the information provided in the Working Instruction is self explanatory.


IAN 139/11 of 266 Mar 11

2 SUMMARY OF SAFETY MANAGEMENT ACTIVITIES The safety risk management process for projects can be viewed as comprising two stages. The first determines whether the current level of safety risk somewhere on the network warrants a project to reduce it. The second makes sure that any projects that affect the network (safety related or not) are delivered in a way that appropriately manages any associated safety risk. Work Instruction 003 addresses this second stage of safety risk management – to make sure that, once the decision has been made to proceed with a project, that the safety risks associated with this are properly managed. The process for determining whether a safety project is warranted is covered elsewhere by existing appraisal processes. Information produced as part of these other processes will feed into the safety risk management process described here, but the decisions covered by these other processes about the ‘business case’ for doing safety projects are assumed to be outside of the process described here. As such, the process described in Work Instruction 003 and this Guidance document begins at the start of the project development phase or stage - once the decision has been taken to do a project and the project scope and preferred option has been defined. Key activities within the safety risk management process for projects covered by this document are then: Articulating what the project will try to achieve in terms of safety (Describing the Safety

Baseline & Objectives) Setting out how the project safety objectives will be achieved (Safety Plan) Making sure that the project design and build includes appropriate risk controls (Risk

Assessment Activities and Hazard Log) Making sure that the project actually does what it said it would, how it said it then

measuring the final safety performance to enable a comparison with the original project safety objectives (Verification & Validation)

Documenting the approach to managing safety risk on the project (Safety Report) Within this, Work Instruction 003 is concerned with safety risk to road users, road workers (where this group is broken down further to construction operatives and Traffic Officers) and 3rd parties during construction, day-to-day operation, planned maintenance, emergency situations and demolition/decommissioning. Much of this happens for Type B projects already through the application of: The Project Appraisal Report (PAR) and Technical Appraisal Report (TAR) and Appraisal

Summary Tables (ASTs) DMRB, MCHW, IANs and other technical guidance documents The Departures process CDM Consultants’ own internal project processes (e.g. Providers Works Documents) The Post Opening Project Evaluation (POPE) process The Road Safety Audit (RSA) process The Project Control Framework (PCF) Wherever any safety risk assessment, or safety documentation is produced to meet the requirements of these or any other HA or internal consultant’s processes, all that Work Instruction 003 requires is a review of this material to make sure that it meets the stated requirements of Work Instruction 003. If it does, then no additional work is required, other than to insert a reference to the existing documentation/deliverable(s) within the Safety Report. If it does not, then some additional work is required to make sure that the requirements of Work Instruction 003 are met.


IAN 139/11 of 266 Mar 11

3 SAFETY BASELINE AND SAFETY OBJECTIVES

3.1 Objective No guidance provided. 3.2 Requirements The safety baseline and objectives define: What the project is aiming to achieve in safety terms (safety objective), and Relative to what (safety baseline) For Major Projects, the process of describing the safety baseline and objectives may involve other stakeholders, such as the DfT, to make sure that their aspirations for the project: Are properly understood by all those involved from the outset of the project Reflect the Agency’s view of what is achievable for the project For Managed Motorways projects, a safety baseline and safety objectives for road users will have been established through existing project appraisal processes e.g. PAR, TAR. Where a quantitative safety objective is specified, this will need to be supported by appropriately robust data. Where this is not available, a more qualitative safety baseline and safety objective may be acceptable. 3.2.1 Project Safety Baseline For most projects, the safety baseline will be the current operational situation at the site where the project will take place. Where the project is providing something new that has no current equivalent, the safety baseline will be the average situation for a similar section of road or activity. This is primarily going to be the case where the project involves introducing some new type of provision for which the current situation is not a reasonable comparator (see example 2 below).

Example – Establishing project safety baseline Example 1 - Project to address the current safety record of an existing NMU crossing point on an APTR. The proposal is to replace the existing crossing with an innovative new type of crossing point that has been used for a number of years in Europe and has been successfully trialled and approved for use in the UK. The appropriate safety baseline would be the current risk level associated with the existing provision at the site. The project is a safety project, justified on the grounds of the current poor safety record at the site. The safety performance of the new crossing should therefore be compared with the safety record of the current crossing, where this should be stated in quantitative terms. Example 2 - Project to create a new junction on an existing motorway. The project is needed to provide access to a new development adjacent to the HA network. The new junction will require some departures; hence it is Type B. The project is not driven by the need to improve safety so the safety performance of the existing link is not an appropriate benchmark for the safety performance of the new stretch of road, with a junction. The appropriate baseline is therefore the average situation for the same type of road with the type of junction that is being proposed.

3.2.2 Project Safety Objectives The Highways Agency has established safety targets for casualty reduction that all projects must aim to contribute to. The Agency must also ensure that it meets its legal obligations for managing safety risk, as set out in various legislation, including the Health and Safety At Work etc. Act 1974 and the Highways Act 1980.


IAN 139/11 of 266 Mar 11

The safety objectives simply guide how much of an effect the work that is included within the project to address safety targets and legal obligations is expected to have on safety, relative to the safety baseline. A common safety objective has been agreed for all MM Early Delivery Schemes. Achievement of this safety objective will then be assessed through monitoring of ‘before and after’ safety data, through the POPE process. The definition of an overall safety objective for MM projects does not remove the need for individual hazards to be controlled by the application of existing standards and the Departures process. Within this, projects should also apply the following guidance: Safety risks associated with individual hazards may be allowed to increase from the

baseline situation, provided the residual risk level remains acceptable and the population subject to the increase in risk is gaining some proportionate level of overall benefit from the project as a whole

Where individual risk controls result in a safety benefit to one population, efforts must be made to ensure that no other population is disproportionately adversely affected in safety terms

There should be no increase in safety risk to any population that does not gain any overall benefit from the project

3.3 Deliverable No further guidance is provided – all required information is within the Work Instruction itself.


IAN 139/11 of 266 Mar 11

4 SAFETY PLAN

4.1 Objective No further guidance is provided – all required information is within the Work Instruction itself. . 4.2 Requirements Technical procedures to be listed within the Safety Plan will include: Main parts of DMRB, MCHW, IANs and other technical guidance that will be used on the

project in order to manage safety and achieve the project safety objectives Any technical approval procedures that will apply to the project, including the Departures

process and a list of the main safety-related Departures that the project will require CDM documentation Much of this will be documented already for most Type B projects, either to meet existing technical approval procedures, the requirements of CDM, or as part of other project documents (e.g. Providers’ Works Documents). Where this is the case, all that is required in the Safety Plan is a list of references to these other existing documents. Where information required for the Safety Plan is not currently captured in any existing project documents, it should be described within the Safety Plan. The Safety Plan then becomes a single point of reference for all information describing how the project will manage safety and deliver its safety objectives through design and during construction, post-opening normal and emergency operation, maintenance and demolition. 4.3 Deliverable The PCF product page for the MM Safety Plan is available at: http://portal/portal/server.pt?open=space&name=CommunityPage&id=2&cached=true&in_hi_userid=17086&control=SetCommunity&PageID=0&CommunityID=914&WG_link=http://portalweb/minisite/hawww/www/MP/PCF_Mockup_2/Product_Groups/New_Groups/../../Products/Safety_Plan.html .


IAN 139/11 of 266 Mar 11

5 RISK ASSESSMENT ACTIVITIES

5.1 Objective No further guidance is provided – all required information is within the Work Instruction itself. . 5.2 Requirements For a Type B project, some safety risks will be addressed through the application of existing technical procedures, some will require the updating of existing risk assessments and some will require new risk assessments to be produced. Where a similar project has been carried out previously, risk assessment activities for any follow on project could simply be to review and update analyses (such as a Preliminary Hazard Analysis (PHA), System Hazard Analysis (SHA) and Operating and Support Hazard Analysis (OSHA)) produced for the earlier project. In the majority of instances, Managed Motorways projects are expected to fall into this category. For more details as to the kinds of details these analyses contain, refer to Work Instruction 004 and the associated guidance. Where new risk assessments are required, refer to Appendix A of the general Appendices to this Guidance for a description of possible risk assessment methodologies. 5.3 Deliverable It is important to have a documented record of what a project did to manage safety risk and why, so that in the event of any incident in the future, there is a clear record of any decisions made and the basis for these. The project should also record details of any residual risks, and provide clear guidance on how these should be managed/monitored into the future.


IAN 139/11 of 266 Mar 11

6 HAZARD LOG

6.1 Objective No further guidance is provided – all required information is within the Work Instruction itself. . 6.2 Requirements Various computer programs/applications are suitable for recording the hazard log. For Managed Motorways a hazard log application has been developed by Highways Agency NetServ which can be used for both Type B and Type C projects. The NetServ hazard log is a multi-user intranet application. The application consists of a database (Microsoft SQL Server 2005 Express) and a web server (Apache Tomcat) component. Both components are installed onto a target machine using a single installer executable file and configured automatically. Once installed, hazard log access is provided by the application can be accessed through a web browser. For more information or to download the hazard log contact NetServ on the following email address:

[email protected]

The hazard log should include all safety hazards associated with the project, from both the construction and operational phases. 6.3 Deliverable The PCF product page for the MM Hazard Log and Hazard Log Report is available at: http://portal/portal/server.pt?open=space&name=CommunityPage&id=2&cached=true&in_hi_userid=17086&control=SetCommunity&PageID=0&CommunityID=914&WG_link=http://portalweb/minisite/hawww/www/MP/PCF_Mockup_2/Product_Groups/New_Groups/../../Products/Hazard_Log.html .


IAN 139/11 of 266 Mar 11

7 VERIFICATION AND VALIDATION

7.1 Objective No further guidance is provided – all required information is within the Work Instruction itself. . 7.2 Requirements 7.2.1 Verification The verification activity should check the following: That the safety activities stated in the project safety plan are being undertaken, in

accordance with the plan That the project safety organisation and sign-off procedure is as per the project safety

plan That the project is making efforts to address any safety challenges described in the

project safety plan, in accordance with the plan Any actions from the hazard log have been implemented/completed For Major Projects and Managed Motorways, this should generally be done through application of the PCF. It should also be done to some extent through MAC/consultants’ own internal quality audits. Alternatively, these points may be picked up by Service Quality Reviews 7.2.2 Validation Aspects of the project that may require validation include: Predicted usage/traffic flow data Predicted user behaviour Predicted maintenance/repair requirements (including methodology, frequency and

extent of maintenance/repair work) Predicted safety benefits Predicted cost of safety benefits For Type B projects, this may require some level of research, data collection or modelling. 7.3 Deliverable The ‘verification and validation’ section of the Safety Report can be written mostly on an exceptions basis i.e. only report in detail about things that were found to be wrong or that had changed. Otherwise, all that is required for this part of the Safety Report is a simple statement to say that the verification and validation was done and did not find any problems or changes.


IAN 139/11 of 266 Mar 11

8 SAFETY REPORT

8.1 Objective No further guidance is provided – all required information is within the Work Instruction itself.. 8.2 Requirements The main requirement is for a succinct document that summarises what was done for safety on the project – how it was considered, key decisions made and justification for these – so that if anything happens in the future e.g. an (incident or inquiry) there is a single document providing a record of the main points, plus details of where to find the relevant supporting detail. The Safety Report should not be a lengthy document – it should be the minimum size needed to record the main facts about how safety was dealt with on the project. For most projects, any assessment of the actual safety performance will be based on findings from the POPE process or from Stage 4 Road Safety Audit. If neither of these processes apply to the project, then a project-specific study will need to be set up. It is particularly important that the Safety Report supports clear identification of safety issues that will ultimately be managed by different parts of the managing organisation once operation commences. This is to ensure that different parts of the organisation have a clear understanding of the main safety risks associated with, and controlled by, those parts of the project for which they are taking responsibility. 8.3 Deliverable As with most of the deliverables required by Work Instruction 003, the Safety Report should be produced by the ‘project executor’ – that is the person/organisation responsible for ‘executing’ the project. This will generally be a Managing Agent or consultant. The Safety Report will then be issued to the HA project manager for the purposes of HA records. The safety report should provide an ‘at-a-glance’ summary of: The safety baseline for different parties affected by the project The actual safety performance, and How this compares with the original safety objective Where the actual safety performance is significantly different to the original safety objective, projects should provide a brief summary of why they think this is the case, plus their justification/reasoning for this. Where projects include an assessment of the actual safety performance, it will be important to feed back any findings so that future estimates of what can be achieved for safety on projects are as realistic as possible. In some situations it may not be practicable to provide an assessment of the safety impact of the project. Situations where this is likely to be the case include minor projects (where the safety effects of the project are subsumed into other changes on that section of network) and projects addressing low frequency risks (where there is a lengthy time period for observing any impact on safety risk). The practicability of measuring the effect of the project on actual safety performance will be agreed between the project executor and HA Project Manager. Where it is deemed to be not practicable, reasons for this will be recorded.


IAN 139/11 of 266 Mar 11

9 UPDATING SAFETY DOCUMENTATION DURING OPERATION

9.1 Objective No further guidance is provided – all required information is within the Work Instruction itself. 9.2 Requirements No further guidance is provided – all required information is within the Work Instruction itself. 9.3 Deliverable The PCF product page for the MM Safety Report is available at: http://portal/portal/server.pt?open=space&name=CommunityPage&id=2&cached=true&in_hi_userid=17086&control=SetCommunity&PageID=0&CommunityID=914&WG_link=http://portalweb/minisite/hawww/www/MP/PCF_Mockup_2/Product_Groups/New_Groups/../../Products/Safety_Report.html.


IAN 139/11 of 266 Mar 11

10 SAFETY ACCEPTANCE AND APPROVALS

No further guidance is provided – all required information is within the Work Instruction itself.

Interim Advice Note 139/11 Work Instructions 004: Managed Motorways Safety Risk Mangement for Projects with Type C Features Safety Risk Working Instructions

IAN 139/11 of 266 Mar 11

PART 7: WORK INSTRUCTION WI 004

Safety Management for Projects with Type C Features SUMMARY This document supports the Agency’s

HSMS. The document describes the safety management activities for MM projects that have been classified by Work Instruction 001 as requiring a Type C SMS




APPLIES TO MM projects classified as Type C/have Type C requirements




IAN 139/11 of 266 Mar 11

Contents 1. Introduction 103 1.1 Background 103 1.2 Objective 103 1.3 Scope 103 1.4 Implementation 103 1.5 Responsibility for Applying this Work Instruction 103 2. SUMMARY OF SAFETY MANAGEMENT ACTIVITIES 104 3. SAFETY ACCEPTANCE AND APPROVALS PROCESS 109 3.1 Objective 109 3.2 Process for External Approval 109 3.3 Internal Project Approval 109 3.4 Safety Approval Group 109 3.5 Deliverables 111 4. SAFETY STRATEGY AND PLAN 112 4.1 Objective 112 4.2 Document Evolution 112 4.3 Safety Strategy and Plan Requirements 112 4.4 Deliverables 113 4.5 Approval Requirements 113 5. RISK ASSESSMENT ACTIVITIES 115 5.1 Overview of Activities 115 5.2 Preliminary Hazard Analysis (PHA) 116 5.3 System Hazard Analysis (SHA) 119 5.4 Sub-System Hazard Analysis (SSHA) 120 5.5 Interface Hazard Analysis (IHA) 122 5.6 Operational and Support Hazard Analysis (OSHA) 122 6. HAZARD LOG 125 6.1 Objective 125 6.2 Hazard Log Requirements 125 6.3 Deliverables 126 6.4 Approval Requirements 126 7. VERIFICATION AND VALIDATION 127 7.1 Objective 127 7.2 Verification and Validation Requirements 127 7.3 Deliverables 128 7.4 Approval Requirements 128 8. SAFETY REPORT 129 8.1 Objective 129 8.2 Requirements 129 8.3 Deliverables 130 8.4 Approval Requirements 130 9. UPDATING SAFETY DOCUMENTATION DURING OPERATION 131 9.1 Objective 131 9.2 Requirements 131 9.3 Deliverables 132 9.4 Approval Requirements 132


IAN 139/11 of 266 Mar 11

10. Safety acceptance and approvals 133

APPENDIX A: REFERENCES 136 APPENDIX B: DEFINITION OF TERMS 137 APPENDIX C: ABBREVIATIONS 138


IAN 139/11 of 266 Mar 11

1 INTRODUCTION

1.1 Background This document is Work Instruction 004 - Safety Management for Projects with Type C Features. It forms part of a suite documents (Work Instructions 001-004 and associated Guidance) that set out the requirements for safety risk management for all HA projects as part of the Agency’s Management Arrangements for Health and Safety (MAHS). Projects with Type C Features are those that require the most rigorous safety management systems. 1.2 Objective The objective of this Work Instruction is to describe the required safety risk management activities for projects requiring a Type C Safety Management System (SMS). 1.3 Scope This Work Instruction applies to all projects affecting the HA road network where the application of Work Instruction 001 has shown that Type C safety management is required. 1.4 Implementation This Work Instruction is applicable to all projects where Type C SMS activities are appropriate. All projects shall follow the Construction (Design and Management) Regulations 2007 (CDM 2007) and will be able to demonstrate that they have done so. Adherence to this Work Instruction in all areas of project development should address CDM 2007 Designer responsibilities (as set out under Regulation 11). All projects shall also follow all other relevant existing HA project processes, such as the Departures and Road Safety Audit processes. It is not necessary to repeat any risk assessment activity carried out in following this Work Instruction in order to comply with CDM 2007, neither is it necessary to repeat work carried out under CDM 2007 to comply with this Work Instruction. Wherever an existing piece of safety work is available for a project, then it shall be assessed for its ongoing applicability. If deemed acceptable, those aspects that it covers need not be repeated as part of fulfilling this Work Instruction. This point will be of particular relevance to any existing risk assessments. 1.5 Responsibility for Applying this Work Instruction It is the responsibility of the Project Manager to make sure that this Work Instruction is fully applied, although its actual application may be delegated to other parties.


IAN 139/11 of 266 Mar 11

2 SUMMARY OF SAFETY MANAGEMENT ACTIVITIES Table 2-1 summarises Type C safety risk management activities. Each activity is described in more detail in Sections 2 to 10.


IAN 139/11 of 266 Mar 11

Safety Management Activity Brief Description of Activity Reason for Carrying Out the Activity Project Safety Baseline and Objectives

Defining the current level of safety and the level to which the project will work to achieve

A baseline is required in order to be able to measure achievement of the safety objective. By defining a clear safety objective assists the project in aiming for an appropriate level of safety, balancing road user, construction operative/traffic officer and third party safety with cost

Safety Strategy and Plan Defining an agreed approach for delivering the safety objectives of the project and defining all of the safety activities that will be carried out throughout the project lifecycle

Provides a means of communicating and educating stakeholders as to how the project will achieve its safety objective and how the safety programme will be delivered Supports the planning of safety activities and demonstrates that a defined safety management approach is being used. As such, it assists in the achievement of project safety objectives Obtaining approval of the Safety Strategy and Plan reduces the risk associated with overall project approval

Identifying potential hazards and the associated event sequences that can lead to collisions and estimating the risk that is attributable to each of these hazards. ‘Type C’ Hazard Analysis may include the following

Conducting a Preliminary Hazard Analysis (PHA) - A process for identifying the hazards that will affect the project, based on the interaction of the project and its environment. Also provides an initial estimate of the risk arising from these hazards

Supports the identification of the hazards that will affect the project enabling them to be risk assessed and subsequently mitigated

Conducting a System Hazard Analysis (SHA) - A process for identifying the hazards that can arise from the system design

Supports the identification of the hazards arising from the design enabling them to be risk assessed and subsequently mitigated

Conducting a Sub-system Hazard Analysis (SSHA) - A process for identifying the hazards that can arise from the detailed design of the system, by systematically examining the design of each sub-system

Supports the identification of the hazards arising from the detailed design enabling them to be risk assessed and subsequently mitigated

Conducting an Interface Hazard Analysis (IHA) - A process for identifying the hazards that can arise at both sub-system boundaries/interfaces and also organisational interfaces

Supports the identification of hazards that can arise at sub-system boundaries/interfaces and also at organisational interfaces, enabling them to be risk assessed and subsequently mitigated

Risk Assessment Activities

Conducting an Operational and Support Hazard Analysis (OSHA) - A process for identifying the hazards that can arise through the execution of the processes and procedures associated with the project. Most commonly relates to maintenance and operation

Supports identification of hazards arising from project interaction with people so that they can be risk assessed and appropriate mitigations prioritised and implemented

Hazard Log Developing a database to record all identified hazards, the associated risk from each hazard and progress with mitigation

Provides a single reference where all hazard related information is stored and also a means of tracking each hazard until sufficient mitigation has been applied


IAN 139/11 of 266 Mar 11

Safety Management Activity Brief Description of Activity Reason for Carrying Out the Activity Verification and Validation The processes to demonstrate that the project meets all of its

requirements, including those relevant to safety, determining whether any assumptions made in assessing risks are consistent with real data and determining whether the project fulfils its original intentions. Typically a Verification Plan and Validation Plan will be developed with a matching report produced on completion of the activities

Allows project to demonstrate that project requirements have been met. Validation checks that the project design satisfies its intended purpose. The Verification and Validation Plans provides assurance that all requirements can be verified/validated and the Verification and Validation Reports demonstrate that this work has been done

Safety Report Documenting the evidence that the project has developed appropriate safety objectives and that these objectives have been achieved

Provides documented evidence that the project safety objectives have been achieved. Thus it facilitates project approval. It also supports ongoing safety management of the project, particularly if any changes are made

Updating Safety Documentation During Operation

Updating all safety related documentation to reflect changes to the project that are made once it has commenced operation

This activity demonstrates that the project still meets all of the necessary safety requirements and that appropriate safety management of the project is continuing during operation

Table 2-1 Summary of Safety Management Activities


IAN 139/11 of 266 Mar 11

The activities listed in Table 2-1 make up the safety lifecycle for a project requiring a Type C SMS. This lifecycle is illustrated diagrammatically in Figure 2-1, which also illustrates the close interaction between the safety management activities that constitute the Safety Lifecycle and the Project Lifecycle activities. Figure 2-1 represents an idealised situation and some limited variations in its application are to be expected.

Update Project Safety Docum entation



Options Phase

DevelopmentPhase

Construction Phase

Project Lifecycle

Operation

Safety Strategy & Plan

Risk Assessment

Verification

Safety Report

Validation

Hazard Log


Safety Acceptance & Approvals Process

Update Project Safety Docum entation



Options Phase

DevelopmentPhase

Construction Phase

Project Lifecycle

Operation

Safety Strategy & Plan

Risk Assessment

Verification

Safety Report

Validation

Hazard Log


Safety Acceptance & Approvals Process

Figure 2-1 The Project Lifecycle and Work Instruction 004 SMS Activities


IAN 139/11 of 266 Mar 11

The main deliverables produced as a result of applying this Work Instruction are:

Safety Strategy and Plan Hazard Log and Hazard Log Report Safety Report

Through the course of applying this Work Instruction, projects may also identify discrete safety issues that require discussion and approval in order to allow the project to progress. The acceptance and approvals process for all project safety issues and deliverables arising from the application of this Work Instruction is defined in Section 10 of this Work Instruction. As the project progresses to construction and operation any changes made to the design must be analysed. The impact of these changes on each safety output shall be assessed and any updates required made. See Section 9 for details on safety documentation updates throughout the safety lifecycle and Section 8 for details on re-issuing the project Safety Report.


IAN 139/11 of 266 Mar 11


3.1 Objective The purpose of considering safety objectives is to assist the project in delivering an acceptable level of road safety that meets long term Agency safety targets, without jeopardising project viability through excessive cost. The level of safety shall balance road user, road worker and third party safety against cost, as well as taking into account global Agency Safety Targets, such as those specified for 2010. The purpose of setting a safety baseline is to enable any change in risk levels that a project brings to be measured. The safety baseline defines the level against which project safety objectives may be set and measured. Without a safety baseline it is not possible to measure whether or not any safety objectives have been achieved. 3.2 Selecting a Safety Baseline Baseline selection will generally take place before there is a detailed project design available and before details of project operation and maintenance regimes are developed. The baseline should therefore be accompanied by a list of ‘assumed project design features’ as these may affect what is achievable in terms of safety benefit. The following shall be considered in selecting a safety baseline: The current road conditions in the location where the project will be deployed, in terms of

features present and a measure of the existing safety/risk level Features that would be provided as standard when a section of infrastructure is

upgraded. It may be appropriate to consider such features as part of the baseline Where completely new road infrastructure is provided (i.e. a route for vehicles is provided

that did not previously exist), the routes that would have been used previously Whether the project is a Pilot or a Trial as this type of project may require a different

safety baseline and/or objectives to those applied to other projects Different baselines may be required for road users as opposed to road workers. The need for different baselines will be a project specific consideration. The safety baseline and its justification shall be documented in a ‘Safety Baseline and Objectives Report’ (see Section 3.3 for details on setting safety objectives). This report will be completed once the project safety objectives are established. 3.3 Identifying a Safety Objective As a safety baseline is being determined, safety objectives will be set. Separate safety objectives will be set for road users and for road workers. Additional consideration should also be given to third parties who may be affected. It may be the case that a separate safety objective is set for them although such a step will not normally be necessary. Safety objectives may be qualitative or quantitative in nature. In determining the safety objectives for a project the following shall also be considered: The effects that the project may have on both road user and construction operative and

traffic officer safety The Agency national safety objectives and what they mean in terms of the year on year

improvements that the Agency is committed to making The safety impact of the project features to be implemented. Assumptions will need to be

made about whether parts of the project will increase or decrease safety risk


IAN 139/11 of 266 Mar 11

Timescales of the project, specifically how long it will take for the project to become operational and hence what progress should be made in respect of targeted year on year improvements

For Road Workers/Traffic Officers:

– Managing risks so that they are reduced So Far As Is Reasonably Practicable (SFAIRP) is a legal requirement of the Health and Safety at Work Act and so must be used as the safety objective for construction operatives and Traffic Officers. This principle must also be used for safety risks to road users and 3rd parties resulting from the activities of construction operatives and Traffic Officers. The following also need to be taken into account

– HA Policy on construction operative and traffic officer Safety. The Agency has a strategy for improving safety by further reducing the risks to road workers whilst maintaining the safety of road users. This is contained within the “Road Worker Safety Action Plan”

– The specification of the project/system to be implemented – The applicability of HA and industry standards

For Road Users: – For Managed Motorway projects, the safety baseline and safety objectives for road

users will be identified through existing HA processes i.e. the Project Appraisal Report (PAR) and/or Technical Appraisal Report (TAR). Achievement of the safety objectives will then be assessed through the Post Opening Project Evaluation (POPE) process.

– Where projects are using all three elements of a Managed Motorway, namely Triple Package, Controlled Motorway and Dynamic Hard Shoulder, a 15% safety benefit will be specified.

For Third Parties:

– Affected third parties may be groups such as members of the public who live in the vicinity of the proposed project. In order that the project achieves an appropriate level of safety for all groups including third parties, thought must be given to the impact that the project will have during both the construction and operational phases on any identified third parties. A specific safety objective for third parties is not normally required but as a minimum, it shall be shown that those hazards that may affect third parties have been adequately mitigated

Additional Considerations for all groups:

– The Highways Agency’s National Targets. The Agency has both government and internal targets for improvement in road safety, to be measured through reductions in the number of people Killed or Seriously Injured (KSI) in road collisions, reducing the number of KSIs with respect to children and reducing the number of slight injuries. Factors to be considered include:

– The series of ministerially agreed and published safety targets from the

Government’s Public Service Agreement (PSA) for improving road safety – Specific Agency targets as described in the document “A Safety Action Plan for

the Core Trunk Road Network” – The Agency’s Strategic and Area Safety Action Plans

– Project specific/local issues. The objective has to take into account local issues such as any route specific safety targets that may exist, particular local concerns or key stakeholder concerns


IAN 139/11 of 266 Mar 11

3.4 Deliverables The deliverable from this phase of the safety lifecycle will be the Safety Baseline and Objectives Report. The outline content for such a report is summarised in Table 3-1.

Section Heading Section Detail/Breakdown 1. Introduction 1.1 Project overview (a brief background to the project and a description of

the design features) 1.2 Document objective(s) 1.3 Document scope

2. Safety Baseline Options

2.1 Review of safety baseline options for consideration 2.2 Safety baseline selection

3. Safety Objective Options

3.1 Influencing factors (e.g. Department of Transport/Highways Agency safety targets)

3.2 Review of safety objectives options (road workers/road users) available for consideration

3.3 Safety objective selection 4. Proposed Baseline and

Objectives Summary of the proposed project baseline and safety objectives, including a description as to how and why they have been chosen

Table 3-1 Outline content for a Safety Baseline and Objectives Report

3.5 Approval Requirements The Safety Baseline and Objectives Report may be subject to the approval process outlined in Section 10.


IAN 139/11 of 266 Mar 11

4 SAFETY STRATEGY AND PLAN

4.1 Objective The objective of the Safety Strategy and Plan is to: Define how the project safety objectives will be achieved Describe the SMS and corresponding safety activities that will be undertaken in order to

achieve the project safety objectives Describe the safety activities that have been carried out to date Define the safety management processes that will control the safety activities Record any changes in the safety approach that may become necessary as the project

progresses The Safety Strategy and Plan serves as a means of communicating the project’s approach to safety to stakeholders. 4.2 Document Evolution The Safety Strategy and Plan will evolve as the project progresses. In its first issue, the report will provide a list of the expected safety activities to be undertaken. It is to be expected that at this stage in project development such activities will not be described in detail. However, as much detail as is available shall be provided. As the project progress and more information becomes available, the Safety Strategy and Plan will be further updated and a re-issue may become necessary. It is therefore expected that there will be more than one release of the Safety Strategy and plan. The number required will be a project specific consideration. 4.3 Safety Strategy and Plan Requirements The Safety Strategy and Plan is a tool to communicate how the project will achieve its safety objectives and how the safety programme will be delivered. It needs to describe clearly the activities that will be undertaken in order to meet the project safety objectives as well as the processes that will control these activities. It will include the following: A summary of the results of applying Work Instruction 001 A clear definition of the project safety baseline and objectives A description of the safety analysis activities that will be undertaken in order to

demonstrate that the safety objective has been achieved. This information shall be updated accordingly dependent on the phase of release

A description of the project organisation, covering the main lines of responsibility within the project and how these interface to the Agency. Descriptions shall also be given of the structure of the Project Safety Team, overall project safety organisation, and any other key safety roles that will exist

An overview of the approach to approval. The overview will include details of the responsibilities within the safety approval process i.e. who is responsible for the development, verification, approval and acceptance of the Safety Report. The Safety Strategy and Plan shall clearly show the relationships between the different parties involved in the approval process, and any relevant intermediate parties

An overview of the procedures that will be applied to control the project. This overview will include details of the way in which any sub-consultants will be managed (if applicable), the document control and any tracking procedures that will be put in place and change control procedures

Details and descriptions of any safety audits and assessments that will be required


IAN 139/11 of 266 Mar 11

A description of the main safety documentation that will be produced by the project An analysis of the project’s competency requirements with respect to safety. This may

be in the form of descriptions of the roles and responsibilities of the project safety team. The main role interactions that should take place are also to be described. Any training needs arising shall also be documented

A statement as to who has both current ownership of and who will have final responsibility for the project. A key point to address will be the transfer of project ownership as it is not expected that those responsible for developing a project will be responsible for its operation

4.4 Deliverables The deliverable from this phase of the safety lifecycle will be the Safety Strategy and Plan. This document will be updated and re-issued at key points during the project lifecycle. The outline content for such a report is summarised in Table 4-1

Section Heading Section Detail/Breakdown 1. Introduction 1.1 Project overview (a brief background to the project and a description of the

design features) 1.2 Document Objective and Context 1.3 Document Scope (determining the scope of the Strategy)

2. Selection of the Project Safety Management System

This section describes the results of the application of Work Instruction 001 0 including the type of SMS that will therefore be applied

3. Project Safety Lifecycle Activities

This section describes all of the safety management activities that will be carried out and is broken-down into the following subsections: 3.1 A description of the project safety acceptance and approvals process

including a statement describing who is responsible for the final approval and verification of the project and with whom the development of the Safety Report lies

3.2 Safety Baseline and Objectives (a section describing the derivation of the safety baseline and corresponding safety objectives)

3.3 Hazard Identification, Analysis and Risk Assessment (details of the activities that will be carried out and a summary of the risk assessment methodologies being used)

3.4 Hazard Log Production (summarising the type of hazard log to be used and how it will be maintained)

3.5 Safety Report Production (including details of the report structure, how it will be maintained and the versions that will be issued)

4. Additional Safety Activities

A summary of the activities to be carried out in later stages of work that are not covered by the current version of the Safety Strategy and Plan

5. Overview of Safety Deliverables

A list of the safety deliverables that the project will produce

6. Programme Management and Control

This section should indicate the timeline for the safety programme activities and change control/action tracking/document control procedures that will be followed

7. Project Team and Safety Roles

This section should be broken down into the following key areas, each giving an organisational chart depicting roles, responsibilities and key role interactions: 7.1 Safety Approval (a description of who is responsible for the project safety

approval, the approval process through which the project must follow) 7.2 Project Organisation (a description of the senior complete project

organisation) 7.3 Project Safety Team and Project Safety Organisation (a description of the

key safety team members and details of the competency requirements including role responsibilities and role interactions)

7.4 Key safety roles (any additional key safety roles)

Table 4-1 Outline Content for a Safety Strategy and Plan

A Safety Plan template is provided in the Appendices to this IAN. This template is appropriate to use for the Strategy and Plan document for Managed Motorways projects.


IAN 139/11 of 266 Mar 11

4.5 Approval Requirements The Safety Strategy and Plan shall be subject to the approvals process set out in Section 10. In addition, the project may chose to submit the Safety Strategy and Plan for approval by specific key stakeholders. The decision to do this will be taken by the PSCRG.


IAN 139/11 of 266 Mar 11


5.1 Overview of Activities For a Type C project comprehensive risk assessment activities are required. Such risk assessment activities are underpinned by a series of hazard analyses. 5.1.1 Hazard Analysis Hazard Analysis involves identifying potential hazards and the associated collision sequences for a project. It also involves initial assessment of the risks associated with these hazards. The principal activities include a Preliminary Hazard Analysis (PHA), a System Hazard Analysis (SHA), and an Operational and Support Hazard Analysis (OSHA), each of which is explained in more detail later. Each analysis involves the systematic examination of the project or project elements and its/their environment, with a view to identifying potential hazards, their causes and appropriate mitigations. Initially, Sub-System Hazard Analysis (SSHA) and Interface Hazard Analysis (IHA) will also be included in the set of hazard analysis activities to be carried out. However, it is acceptable to omit these activities if, having completed PHA, SHA and OSHA, it can be shown that they are not necessary. These activities will not be necessary when the safety analysis activities completed have examined: The project design in sufficient depth so that there is confidence no new hazards will be

revealed through more detailed examination All necessary interfaces in sufficient depth, in respect of equipment to be deployed and of

organisations involved Where available, any pre-existing hazard analyses shall be taken into account in conducting the analyses described in this section. Where such analyses exist and are still applicable to the project in question, those aspects that are covered by these analyses need not be repeated. Hazard analyses that would be expected to be of relevance include: Analyses carried out as part of a previous project that involved deployment of

similar/identical functionality Analyses carried out as part of the fulfilment of CDM requirements Analyses carried out as part of a departure application In respect of departures, adherence to this Work Instruction does not affect the need to follow the appropriate Agency process for each departure. However, it may be the case that risk assessments and hazard analyses carried out may be appropriate for both a departure application and as partial fulfilment of the requirements of this Work Instruction, in which case a repeat analysis is not required. 5.1.3 Risk Assessment For each hazard identified during the activities described above a risk assessment is carried out to establish whether appropriate mitigation is already in place, and if not, to identify additional mitigations.


IAN 139/11 of 266 Mar 11

The basic steps in a risk assessment are as follows: Identify hazards associated with activities or situations Identify who is at risk Estimate the associated risk, based on hazard frequency and consequence calculations

(risk per hazard = hazard frequency x hazard consequence) Identify the control measures to be used to reduce the risk Record the assessment Ensure that appropriate control measures will be implemented on project operation Figure 5-1 shows the order in which hazard analysis activities are carried out and the interaction between safety analysis and design. The activities will be iterative in nature, with design work leading to hazard analysis which may in turn lead to additional design needing to be carried out. Each hazard analysis activity is described in more detail in the sections that follow.

Preliminary Hazard Analysis (PHA)

Initiate Hazard Log

Interface Hazard Analysis (IHA)

Sub-system Hazard Analysis (SSHA)

System Hazard Analysis (SHA)

Operational and Support Hazard Analysis (OSHA)

Preliminary Design

Outline Design

Detailed Design, Outline Procedures

‘As Built’ System with Procedures

Operational System

Preliminary Hazard Analysis (PHA)

Initiate Hazard Log

Interface Hazard Analysis (IHA)

Sub-system Hazard Analysis (SSHA)

System Hazard Analysis (SHA)

Operational and Support Hazard Analysis (OSHA)

Preliminary Design

Outline Design

Detailed Design, Outline Procedures

‘As Built’ System with Procedures

Operational System

Figure 5-1 Project SMS Hazard Analysis Activities and Design

5.2 Preliminary Hazard Analysis (PHA) 5.2.1 Objective The objective of the PHA is to identify all reasonably foreseeable hazards that can arise from the project interacting with its environment. In advance of the PHA knowledge is needed of the main functions that the project will deliver, the main operational changes that it will deliver (including project maintenance) and the environment in which they will operate. Detailed design information is not needed at this stage. The PHA is ideally carried out once the project concept has been established and before detailed design work begins.


IAN 139/11 of 266 Mar 11

5.2.2 The PHA Process - The process for conducting a PHA is outlined below.

1. Define the project. The first stage of the PHA involves describing what is meant by the

project. The project description is based on the known design and operational features and should represent the final project as closely as possible, given that at this stage the design is only expected to exist in outline form. Hazard identification is based on this description

2. Identify applicable hazards from existing work. Hazards already identified during

safety assessments carried out on related projects can be incorporated into the PHA 3. Conduct workshops to review existing hazards and identify other applicable

hazards. Identification of new hazards will be achieved through examination of the project functions and operations in a workshop environment. Workshop attendees will include a facilitator and a scribe to record results. Other attendees will be drawn from:

– The HA Project Manager – Maintainers – Health and safety representatives – Operators – Safety experts – Technology specialists – Specific designers of pertinent areas – Suppliers In the workshops each function and operational aspect of the project shall be examined systematically to identify: – The collisions that could arise from these functions and operations – The hazards, which if they occurred, would give rise to these collisions occurring too.

All hazards will be linked to a collision In addition, collisions and hazards already identified from previous projects shall be reviewed to check that they are still applicable to the current project and to modify them as required. Modifications to existing hazards may include changes to the risk score and the removal/addition of mitigations. Factors to take into account when reviewing existing hazards and collisions will include differences in the road environment that apply to the current project, any mitigations that may no longer be applicable, new mitigations that may be available and data that may be available to refine the risk score. Each hazard will be identified as either sufficiently mitigated or in need of further mitigation. The identification of further mitigations is not a formal part of the PHA process, but any that are identified should be recorded. Finally, any actions required to better understand the hazards will be noted for addressing during a subsequent hazard analysis activity

4. Initial risk assessment of each hazard. Once all of the preliminary design hazards have been determined a ‘risk score’ is to be assigned to each of them. This activity involves assigning a frequency and consequence to each hazard. Each project will need to establish its own approach to scoring risks. Information on potential risk assessment methodologies is provided in the guidance document associated with this Work Instruction


IAN 139/11 of 266 Mar 11

5. Rationalisation and Organisation of the Hazards into the Hazard Log. Each of the identified hazards, collisions and causes will be entered into a ‘project Hazard Log’ (see Section 6 for further details of what this is). Hazards will be linked to the relevant collision and the risk score associated with each hazard recorded. Each hazard entry will have:

– A full description – The consequences of the hazard, noting the collisions which can result if the hazard

occurs – A risk assessment (a score assigned to each hazard) including an explanation for the

score given (where possible this should be based on data rather than expert judgement, but it is to be expected that data will not be available for all cases)

– The assumptions underlying the risk assessments – Known mitigation measures for the hazard – A list of future actions to be undertaken including outstanding questions or further

investigations to be carried out, actions which will be managed through subsequent risk assessment activities

A version of the Hazard Log corresponding to the completion of the PHA shall be retained for future audit requirements

6. Documentation of PHA results. The main activities undertaken in the PHA and the main results arising will be documented in the PHA Report. This report will provide an audit trail to show how the PHA was carried out and what it produced

5.2.4 Deliverables The main deliverable from this phase of the safety lifecycle will be the PHA Report. In addition, following the PHA a populated version of the Hazard Log will be available for inspection. The outline content for the PHA report is summarised in Table 5-1.

Section Heading Section Detail/Breakdown 1. Introduction 1.1 Project overview

1.2 Previous applicable projects 2. Objective and Scope of PHA The objective and scope of the PHA 3. PHA Methodology The method used to conduct the PHA

3.1 Activities Carried Out 3.2 Risk assessment methodology

4. Identification of Higher Risk Hazards Lists the high risk hazards and where available gives an explanation as to why the hazard is high risk and what may be done to address it

5. Next steps in safety analysis process 5.1 Future risk assessment activities 5.2 Other outstanding issues to be analysed

6. Conclusion Main conclusions arising including stating whether the PHA objective has been achieved

Table 5-1 Outline Content of a PHA Report

5.2.5 Approval Requirements The PHS Report may be subject to the approvals process set out in Section 10. In addition, the project may chose to submit the PHA Report for approval by specific key stakeholders. The decision to do this will be taken by the PSCRG.


IAN 139/11 of 266 Mar 11

5.3 System Hazard Analysis (SHA) 5.3.1 Objective The objective of the SHA is to identify the hazards that can arise from the project design through systematic examination of the design and its potential failure modes. 5.3.2 The SHA Process By the time that the SHA is undertaken, significantly more design information will be available. Typically detailed design will have started but will not be complete, as the SHA may influence design requirements. The process for conducting an SHA is outlined below. 1. Further develop the project description used in the PHA by adding in additional

design details. This description will act as a basis for conducting the SHA so it is important that it is as accurate a reflection as possible of the design intentions at this point in time

2. Identify any new hazards from existing work that may now be applicable to the

design. Additional hazards that have already been identified on other Highways Agency projects may now be applicable depending on the new design features to be implemented. As part of this activity, review any existing analysis work for its applicability to the SHA

3. Conduct a set of SHA workshops to review existing hazards and identify all other

applicable hazards. These workshops will be similar in nature to those carried out as part of the PHA and will analyse the design that the project will deliver. The inputs to the process will then be reviewed to complete the identification and review of any additional hazards. Examples of attendees to the workshops include:

– The HA Project Manager – Maintainers – Health and safety representatives – Operators – Safety experts – Technology specialists – Specific designers of pertinent areas (especially relevant for the SHA) – Suppliers

In the workshops each design element of the project should be examined systematically to identify the potential collisions and associated hazards that apply to them In addition, collisions and hazards from previous projects now identified as relevant shall be reviewed and any project specific features taken into account. Each hazard will be identified as either sufficiently mitigated or in need of further mitigation. Where this is the case, either further mitigations will be identified and recorded or an action recorded to identify further mitigations. Any actions required to better understand hazards will be noted for later attention

4. Carry out assessment of the risk associated with new hazards and refine any from the original set of hazards

5. Conduct ongoing analysis of issues arising from the workshops. Not all issues will

be resolved in the course of the workshops and specific risk assessments and other studies are expected to be needed. These activities will commence as soon as the workshops are complete although they do not need to form part of the SHA Report. Individual study reports may be produced and all material will be documented in the Hazard Log


IAN 139/11 of 266 Mar 11

6. Capture of all information arising from the SHA in the Hazard Log. This log will be the main repository of all information that arises in the course of conducting the safety analysis work so the output from each analysis activity must be added. For the SHA, the new information will take the form of new hazards, updates to existing hazards, additional mitigations and revisions to risk assessments. Any issues that require further investigation will be documented in the Hazard Log

7. Documentation of SHA results. The main activities undertaken in the SHA and the

main results arising will be documented in the SHA Report. This Report will provide an audit trail to show how the SHA was carried out and what it produced. It is acceptable to document some analysis that contributes to the SHA in separate Reports, where combining them would be impractical

5.3.3 Deliverables The deliverable from this phase of the safety lifecycle will be the SHA Report. The outline content for the SHA report is summarised in Table 5-2.


1.2 Previous applicable projects 2. Objective and Scope of SHA The aim and scope of the SHA 3. SHA Methodology The method used to conduct the SHA

3.1 Activities Carried Out 3.2 Summary of risk assessment methodology

4. Identification of Higher Risk Hazards Lists the high risk hazards and where available gives an explanation as to why the hazard is high risk, what has been done to address it and any further actions that are planned

5. Next steps in safety analysis process 5.1 Future risk assessment activities 5.2 Other issues to analyse

6. Conclusion Main conclusions arising including stating whether the SHA objective has been achieved

Table 5-2 Outline Content for an SHA Report 5.3.5 Approval Requirements The SHA Report may be subject to the approvals process set out in Section 10. In addition, the project may chose to submit the SHE Report for approval by specific key stakeholders. The decision to do this will be taken by the PSCRG. 5.4 Sub-System Hazard Analysis (SSHA) 5.4.1 Objective The objective of the SSHA is to complete the safety analysis of the design, identifying any additional hazards that can arise from the detailed project design. The SSHA will continue until the design is complete as all aspects of design will need to be analysed for their impact on safety. Such an analysis will not be necessary when: The technical design is not complicated and has been sufficiently analysed in the SHA The technical design has been applied to a sufficiently similar project and does not need

detailed re-examination Where an SSHA is assessed as not being necessary, the decision will need to be documented and then included in the Safety Report.


IAN 139/11 of 266 Mar 11

5.4.2 The SSHA Process By the time that the SSHA is undertaken, detailed design will be advanced but will not be complete. The process for conducting an SSHA is outlined below. 1. Define the sub-system design components. The first stage of the SSHA is to clearly

define the project sub-system components that are to be analysed. The design will need to be sufficiently advanced to allow this to be possible

2. Review any existing analysis work for its applicability to the SSHA 3. Conduct SSHA workshops and/or analysis processes. Once the set of sub-system

components have been agreed, analysis can take place through two approaches, which may be combined. These are:

– Holding of workshops. The attendance will be similar to those held as part of the

SHA. The workshops will be used to analyse detailed design components and sub-systems

– Detailed safety analysis. Detailed design components may be analysed using a desk based method such as Failure Modes and Effects Analysis (FMEA)

– It will be a project specific decision as to how the SSHA will be carried out. The approach will be justified in the SSHA Report

4. Carry out assessment of the risk associated with new hazards and refine any from

the original set of hazards 5. Capture of all information arising from the SSHA in the Hazard Log. This log will be

the main repository of all information that arises in the course of conducting the safety analysis work so the output from each analysis activity must be added. For the SSHA, the new information will take the form of new hazards, updates to existing hazards, additional mitigations and revisions to risk assessments. Any issues that require further investigation will also be documented in the Hazard Log

6. Documentation of SSHA results. The SSHA may be made up of a series of separate

studies. Where each of these is documented separately, a specific SSHA report is not necessary. If each activity has not been documented then an SSHA Report shall be produced. It will record the results from all undocumented activities and make reference to SSHA activities that are already documented. This report will provide an audit trail to show how the SSHA was carried out and what it produced

5.4.3 Deliverables The deliverable from this phase of the safety lifecycle will be the SSHA Report and any other detailed analysis reports that are necessary. As the documentation of the SSHA can take different form it is not practical to identify the outline content of an SSHA Report. Where a workshop approach only is used, the report will be similar in content to the PHA and SHA reports. 5.4.4 Approval Requirements The SSHA report may be subject to the approvals process set out in Section 10. In addition, the project may chose to submit the SSHA Report for approval by specific key stakeholders. The decision to do this will be taken by the PSCRG.


IAN 139/11 of 266 Mar 11

5.5 Interface Hazard Analysis (IHA) 5.5.1 Objective The purpose of the IHA is to complete the analysis of project related interfaces, whether technical (i.e. system or sub-system interfaces) or organisational. The need for an IHA shall be reviewed as the hazard analysis work progresses as it is expected that in many cases, all necessary interfaces will be examined sufficiently through the PHA, SHA and OSHA. 5.5.2 The IHA Process The process for conducting an IHA is outlined below. 1. Define the interfaces to be examined and the flows across these interfaces. The

IHA will only be needed if interfaces can be identified that have not yet been analysed 2. Analyse the flows between interfaces. The method of analysis will be to consider each

type of information that can flow across an interface and the failure modes that apply to this information transfer. The analysis will be carried out either through additional workshops or as a desk-based exercise. Where a desk-based exercise is selected, the results must be reviewed sufficiently widely to demonstrate that appropriate expertise has been used in completing the activity. Where a workshop is used, similar attendance to that used for the SHA workshops is required

3. Carry out assessment of the risk associated with new hazards and refine any from the original set of hazards. Risk scores will be assigned to all new hazards

4. Capture of all information arising from the IHA in the Hazard Log. For the IHA, the new information will take the form of new hazards, updates to existing hazards, additional mitigations and revisions to risk assessments. Any issues that require further investigation will be documented in the Hazard Log

5. Documentation of IHA results in IHA Report. The main activities undertaken in the IHA and the main results arising will be documented in the IHA Report. This report will provide an audit trail to show how the IHA was carried out and what it produced

5.5.3 Deliverables The deliverable from this phase of the safety lifecycle will be the IHA Report. The IHA Report, if needed, will be similar in format to the PHA and SSHA Reports. 5.5.5 Approval Requirements The IHA Report may be subject to the approvals process set out in Section 10. In addition, the project may chose to submit the IHA Report for approval by specific key stakeholders. The decision to do this will be taken by the PSCRG. 5.6 Operational and Support Hazard Analysis (OSHA) 5.6.1 Objective The purpose of the OSHA is to identify and analyse those hazards that are associated with the project processes and procedures carried out by people. Practically this means mainly the analysis of operations and maintenance procedures. Procedures associated with construction are not assessed as part of the OSHA as these are addressed through CDM regulations. If such aspects of construction are not assessed through CDM regulations then they must be subject to the OSHA analysis process described in this Work Instruction. The OSHA differs from the previously described hazard analysis activities as it is primarily concerned with the procedural interactions that people have with the project systems rather than the functions of the project.


IAN 139/11 of 266 Mar 11

5.6.2 The OSHA Process The process for conducting an OSHA is outlined below. 1. Carry out preparation for hazard analysis workshop. Process flow charts modelling

maintenance and operational processes shall be developed. If procedures have not been developed for a particular activity, then outline procedures will need to be developed for the workshop, based on best available information

2. Review any existing analysis work for its applicability to the OSHA 3. Conduct Workshops. Workshop attendees should consist of key stakeholders and

members of the project. Between them they will have:

– Maintenance or operations expertise, or knowledge of existing procedures – Knowledge of the safety activities that have already been carried out for the project – Knowledge of user behaviour (this will depend on the project) – Experience of the system equipment that may be introduced – Knowledge of the project design

The OSHA workshop should focus on: – Identifying hazards associated with the procedures that are examined – Changing steps in any of the current processes to account for these hazards – Creating new steps in existing processes and procedures as required – Creating new processes or procedures, in the form of flow charts for those that do not

currently exist, taking into account the known hazards that can affect these procedures

The steps in the flow diagrams will be examined by using guide words (a predefined list of words which are used to highlight the typical kinds of failure that can affect an individual step in a process)

4. Carry out assessment of the risk associated with new hazards and refine any from the original set of hazards. Risk scores will be assigned to all new hazards

5. Capture of all information arising from the OSHA in the Hazard Log. For the OSHA,

the new information will take the form of new hazards, updates to existing hazards, additional mitigations and revisions to risk assessments. Any issues that require further investigation will also be documented in the Hazard Log

6. Documentation of OSHA results in OSHA Report. The main activities undertaken in

the OSHA and the main results arising will be documented in the OSHA Report. This report will provide an audit trail to show how the OSHA was carried out and what it produced. The OSHA is expected to produce a series of follow up actions that will need completion before an agreed set of procedures is available for a project. The OSHA Report will document these actions but their resolution will be documented in the Hazard Log and in separate reports if necessary


IAN 139/11 of 266 Mar 11

5.6.3 Deliverables The deliverable from this phase of the safety lifecycle will be the OSHA Report. The outline content for an OSHA report is summarised in Table 5-3.


1.2 OSHA Objectives 1.3 OSHA Scope

2. OSHA Methodology The method used to conduct the OSHA 2.1 Activities Carried Out 2.2 Approach to analysing the results

3. Main Findings Identifies the main issues that have arisen in conducting the OSHA, including identifying where the main risks have arisen in respect of the procedures examined

4. Issues for Further Analysis 4.1 Future risk assessment activities 4.2 Other issues to analyse

6. Conclusion Main conclusions arising including stating whether the OSHA objective has been achieved

Table 5-3 Outline Content for an OSHA Report

5.6.4 Approval Requirements The OSHA Report may be subject to the approvals process set out in Section 10. In addition, the project may chose to submit the OSHA Report for approval by specific key stakeholders. The decision to do this will be taken by the PSCRG. 5.6.5 Additional Activities The OSHA will have identified specific maintenance and operational safety requirements that must be achieved to meet the project safety objectives. These requirements must be reflected in maintenance and operations plans for the project. The details of the documents that will be produced for maintenance and operations are outside the scope of this Work Instruction, but the requirements emerging from the OSHA must be reflected in any relevant documents that are produced in order to maintain a clear audit trail.


IAN 139/11 of 266 Mar 11

6 HAZARD LOG

6.1 Objective The objective of the Hazard Log is to provide a means of recording all hazard related information and tracking all hazards that are identified in a project through to their successful resolution. Resolution in this instance may be regarded as demonstrating that necessary mitigation has been identified and subsequently applied to the hazard. 6.2 Hazard Log Requirements The Hazard Log will be set up as a database and will be updated throughout the lifecycle of the project. For Managed Motorways projects a hazard log will be provided, pre-populated with hazards that are known to affect such schemes. It will be a project specific responsibility to complete the entry of required information into the hazard log, based on completion of the safety management activities outlined in this Work Instruction. For each hazard the following shall be included in the log: A full description of the hazard The frequency at which the hazard will occur (frequency) How likely it is that the hazard will lead to a collision (likelihood) The consequences of the collision(s) that arise(s) from the hazard, including a link to the

collision(s) Who the hazard could affect (road users, road workers or 3rd parties) A risk assessment (frequency x likelihood x consequence) with appropriate supporting

arguments and data The assumptions underlying the risk assessments The mitigation measures for the hazard including those that could potentially be applied

as well as those that definitely will be applied A list of the next actions to be undertaken including outstanding questions or

investigations to be carried out, in order that the hazard can be deemed to be sufficiently mitigated

A list of actions that have been resolved Access to the Hazard Log will be controlled. Each project will decide who to give read access to and who to give write access to. The procedure to be used for Hazard Log management shall be described in the Safety Plan. The Hazard Log management procedure will need to address the whole project lifecycle including operation. Specific issues that the management procedure will need to address include: Security requirements for the Hazard Log. They will need to be considered to prevent

unauthorised access. Such requirements will be especially important if the log is configured for access over the internet

Backup procedures. Secure backups of the hazard log will need to be taken at regular intervals and stored appropriately

Projects will also produce a Hazard Log Report, This will:

Provide documentary evidence that the relevant hazards have been identified and categorised

present the main hazards, mitigations, tasks and requirements identified from the hazard log

state progress towards achieving the scheme safety objective set out recommendations for any further actions that could enhance achievement of

the scheme safety objective


IAN 139/11 of 266 Mar 11

6.3 Deliverables The Hazard Log may not be delivered in documentary form. However, the Hazard Log database shall be made available for delivery to the Agency upon commencement of project operation. A Hazard Log Report template is provided in the Appendices to this IAN 6.4 Approval Requirements The Hazard Log does not require specific approval. It provides evidence that contributes to the Safety Report, which does require approval. However, the Hazard Log Report must be subject to the approvals process set out in Section 10 of this Work Instruction. In addition, the project may chose to submit the Hazard Log Report for approval by specific key stakeholders. The decision to do this will be taken by the PSCRG.


IAN 139/11 of 266 Mar 11


As elements of the project are completed, they will be verified to ensure that they meet their requirements, including those relevant to safety. On completion of verification, validation is needed to show that the delivered project satisfies the requirements of its intended usage. Verification and validation activities will normally be applied to all project requirements (both safety and non-safety). The safety verification and validation activities that this Work Instruction requires will frequently be a sub-set of more general verification and validation. For instance, site acceptance testing will verify many project requirements, some of which will be safety related. To meet the requirements of this Work Instruction it is only necessary to verify and validate safety requirements and objectives. However, specific safety verification and validation activities are expected to be limited, as more general verification and validation activities will cover the majority of requirements. 7.1 Objective 7.1.1 Verification The objective of the verification activities is to show that the project meets its safety requirements. 7.1.2 Validation The objective of the validation activities is to determine whether the project satisfies the requirements of its intended use. From a safety perspective this can be interpreted as follows: Confirming that the safety objectives are being achieved after operation has commenced Confirming, also after operation has commenced, whether the assumptions made in

carrying out risk assessments are correct 7.2 Verification and Validation Requirements A Verification Plan will be needed to outline the steps that the project will take to confirm that it will meet all safety requirements. A Validation Plan will outline the steps that the project will take to confirm that the project has delivered the required safety benefit. These plans may be combined into one document. The Plan/s will need to: Identify all of the project requirements including the safety requirements relevant to the

Plan topic Identify all of the testing and checking activities to be carried out Identify all of the reviewing activities that relate to safety requirements Identify any analysis activities that will be undertaken through the development lifecycle

to verify safety requirements Identify how assumptions that will need validating by operation will be checked A Verification/Validation Report shall describe all of the verification and validation activities that have taken place in accordance with the plan. Verification and Validation progress can be managed within the Hazard Log (Section 6). Each safety requirement will have its own entry, detailing the action required to meet the safety requirement, and eventually confirming that the verification is complete. Validation activities that have taken place can also be recorded in this way.


IAN 139/11 of 266 Mar 11

7.3 Deliverables The deliverables from this phase of the safety lifecycle will be: Verification Plan(s). This document will provide a list of all of the safety requirements

with an explanation as to how verification will be carried out for each area relevant to the project. Depending on the complexity of the project, one or more Plans may be needed

Verification Report(s). This document will describe how verification has been carried out and the results arising. Depending on the complexity of the project, one or more Plans may be needed

Validation Plan(s). This document will provide a list of all of the project requirements that require validation with an explanation as to how validation will be carried out. Depending on the complexity of the project, one or more Plans may be needed

Validation Report(s). This document will describe how validation has been carried out and the results arising. Depending on the complexity of the project, one or more Plans may be needed

The plans may be combined into one document as may the reports. 7.4 Approval Requirements The Verification and Validation Plans and Reports may be subject to the approvals process set out in Section 10. In addition, the project may chose to submit the Verification and Validation Plans and Reports for approval by specific key stakeholders. The decision to do this will be taken by the PSCRG.


IAN 139/11 of 266 Mar 11

8 SAFETY REPORT

8.1 Objective The objective of the Safety Report is to summarise the evidence demonstrating that the project safety objectives have been met by summarising all of the safety work that has been done in association with the project and in doing so facilitating the safety approval of the project. 8.2 Requirements A project Safety Report will provide a clear, comprehensive, auditable and defensible argument that the project achieves its safety objectives. The report will also show how this level of safety will be maintained throughout the life of the project. With respect to managed motorways, the Safety Reports that are created will need to assess the degree to which all necessary principles have been applied in respect of safety objectives, as described in documentation such as the PAR. A project will be required to demonstrate that the overall effects of any changes in approach have not had a cumulative effect on safety performance that cannot be justified. The Safety Report will therefore need to comment on this safety objective, the degree to which it is achieved and justify any discrepancy. Over the course of a project, several versions of the Safety Report will be issued, each progressively providing more evidence in respect of achieving safety objectives as the project system is designed, constructed, installed, configured, tested, commissioned and operated. The exact versions to be produced will depend on the nature of each project and its needs. All versions of the Safety Report will follow a similar structure. The safety Report structure can be described using GSN (Goal Structured Notation). The Safety Report shall clearly identify those aspects of the project’s safety system that will become the responsibility of different parties once the project commences operation. For example, operation, technology and infrastructure. This is to ensure that those parties taking ownership of the project at operation have a clear understanding of the safety issues for which they are taking responsibility.


IAN 139/11 of 266 Mar 11

8.3 Deliverables The main deliverable arising from this phase of the safety lifecycle is the Safety Report. The outline content for a Safety Report is summarised in Table 8-1.

Section Heading Section Detail/Breakdown 1. Introduction 1.1 Project Overview

1.2 Purpose, addressing the particular version of the Safety Report 1.3 Scope 1.4 Changes Since Last Issue. This will identify all changes that have

been made to the document since the last Safety Report version and where in the document these changes have been made

2. Safety Objective 2.1 Safety baseline, covering the nature of the safety baseline and demonstrating that it has been approved

2.2 Safety objective, describing the safety objectives to be used for road workers and road users

2.2 Safety Objective Demonstration, covering the methodology for demonstrating that the safety objective is achieved and showing that this methodology has been approved

2.3 Safety Objective Achievement, describing how the safety objective has been achieved or how it will be achieved. This information will include a list of unresolved issues

3. The Safety Management Process

The objective of this section is to demonstrate that a robust safety management process is being followed 3.1 Competence of resource. This section will demonstrate that the

project has been resourced with competent people and should include a description of the roles and responsibilities of individuals the project

3.2 Safety Management Process, defining the project safety management process including a description of the key elements and activities

3.3 Approval Process, demonstrating that a robust approval process for the Safety Report is in place

3.4 Safety challenges i.e. a section logging and demonstrating that all of the safety challenges have been addressed

3.5 Safety Performance, describing the Plans in place to monitor safety performance during operation

3.6 Maintaining the Safety Report i.e. a section describing how the Safety Report will updated and maintained

4. Management of Hazards 4.1 Use of the Hazard Log. This section will demonstrate that the management of hazards has been based around a Hazard Log

4.2 Identification of hazards. This section will demonstrate that all hazards that could reasonably be expected to affect the project have been identified and analysed by describing the different analysis techniques, the risk assessment methodology used, how mitigations have been identified and accounted for and the process by which hazards are reviewed

5. Management of Safety-Related Tasks

5.1 Future risk assessment activities 5.2 Other issues to analyse

6. Safety Requirements and Restrictions

This section will demonstrate that all safety requirements have been identified, are traceable to hazards and have been met. For any that are not met appropriate restrictions will be identified

7. Methods and Processes This section looks at whether appropriate methods and processes have been followed during project execution) 7.1 Compatibility of design with standards and legislation 7.2 Following good practice (during project execution)

8. Conclusion This section provides a statement in respect of achieving the safety objectives and includes a synopsis of any outstanding actions that remain incomplete

Table 8-1 Outline Content for a Safety Report

8.4 Approval Requirements All Safety Reports shall be subject to the approval process set out in Section 10.


IAN 139/11 of 266 Mar 11

9 UPDATING SAFETY DOCUMENTATION DURING OPERATION/ MAINTENANCE

9.1 Objective The objective of updating the safety documentation during project operation is to ensure that all safety documentation reflects the project as it is being operated and maintained and to ensure that traceable records of changes are maintained. Maintaining the safety documentation in this way means that it can be shown that the project safety objectives continue to be met. 9.2 Requirements The following items of safety documentation are expected to need updating throughout project operation: The Safety Plan The Hazard Log and Hazard Log Report The Safety Report The above list is not exhaustive. Other safety documentation may also require updating. However, of the above list, the Hazard Log is expected to require the most updating. The main causes of documentation updates, following commencement of operation, are listed below: Identification and implementation of new functionality. Either a change to existing or

the introduction of new functionality may be required. These changes will need to be subject to hazard analysis and reflected in the relevant safety documentation

Identification of new hazards and verification of the Hazard Log. It is possible that

new hazards may be identified that are not captured within the project Hazard Log. Details of any new hazard must be communicated immediately to those responsible for safety and added to the project Hazard Log. A formal mechanism for adding new hazards to the Hazard Log must be part of the Hazard Log Management Process described in Section 6.2. The identification of new hazards or hazard causes may also lead to the updating of the applicable hazard analysis study

The assumptions forming the basis of the risk calculations in the Hazard Log must also be verified during operation. This verification will be achieved through the use of data collected via monitoring activities. Any changes to assumptions or risk calculations need to be assessed for impact on the Safety Objectives and documented within the Hazard Log. A Hazard Log change record will need to be maintained

Organisational Changes. Any organisational changes that affect safety need to be

captured in the Safety Plan and Safety Report Transfer of Safety Responsibility. The Safety Strategy must clearly state who is

responsible for the ownership of the project safety work and describe any transfers in ownership that are known about. When such a transfer occurs or should any new transfers arise, the Safety Strategy and the Safety Plan shall be updated to reflect where responsibility will then reside

Where different aspects of the operational project are the responsibility of separate parties (e.g. operation, technology, infrastructure) then the implications of any proposed change to one aspect of the project shall be discussed and agreed with other parties whose area of responsibility may also be affected by the change – before


IAN 139/11 of 266 Mar 11

the change is introduced. This is to ensure that any safety related inter-dependencies are appropriately managed once the project has commenced operation. 9.3 Deliverables The deliverables arising from this part of the safety lifecycle will be updated versions of existing documents. 9.4 Approval Requirements Any changes made to the safety documentation will need to be approved and will be subject to the approval process outlined in Section 10.


IAN 139/11 of 266 Mar 11

10 SAFETY ACCEPTANCE AND APPROVALS All project safety deliverables must be formally accepted and approved by the relevant parts of the HA. The first step in this process is to submit project safety deliverables to the PSCRG. The PSCRG review each deliverable and then submit it to the NSCRG, along with a recommendation for acceptance or rejection. The NSCRG will then determine whether or not they agree with this recommendation and provide their response back to the project team. Once a project safety deliverable has been agreed through the process described above, it shall be submitted for formal acceptance and approvals as per the process shown in figure 10-1.

MP Project Manager




MP Project Senior

Responsible Owner

Project Consultant




IAN 139/11 of 266 Mar 11





The TM Project Senior User accepts that, in relation to the project operating regime, the scope and content of the document are correct and fit for purpose given the current stage of the project



These responsibilities are reflected in the generic approvals sheet shown in Figure 10-2, which must be completed for all project safety deliverables, as a record of their progress through the safety acceptance and approvals process defined above.


IAN 139/11 of 266 Mar 11




Name ____________

Date _____________

Signature _____________

Project Consultant

(Project Director)

I confirm that:



Name ____________

Date _____________

Signature _____________






Name ____________

Date _____________

Signature _____________



Name ____________

Date _____________

Signature _____________



Name ____________

Date _____________

Signature _____________

Network Services





Name ____________

Date _____________


Major Projects





This approvals process shall also apply to any changes introduced to project safety documentation after operation has commenced. This is to ensure appropriate consideration and approval for the safety implications of any changes across all aspects of the project. In this situation, the ‘MP Project Manager’ and ‘Major Projects Senior Responsible Owner’ shall be substituted by the HA Project Manager and Senior Responsible Owner responsible for delivery the particular change.


IAN 139/11 of 266 Mar 11


[1] Managed Motorway Schemes, National Safety Control Review Group and Project

Safety Control Review Groups, Remit for Organisation and Governance


IAN 139/11 of 266 Mar 11


Term Explanation Agency The Highways Agency Hazard Analysis The process by which potential hazards and collision sequences relevant

to a project are identified Interface Hazard Analysis A type of hazard analysis that focuses on both equipment and

organisational interfaces Operation and Support Hazard Analysis

A type of hazard analysis that focuses on the processes and procedures associated with the project

Preliminary Hazard Analysis A type of hazard analysis that focuses on hazards that will affect the project, based on the interaction of the project and its environment

Project An activity undertaken which involves: Construction on the trunk road network Development of new procedures or modification of existing ones A change to an existing routine activity

Project Feature A high level property of the project that can be expected to affect safety management requirements

RACI Matrix A matrix that can be developed in order to help break down roles and responsibilities in relation to a process or activity

Safety Strategy and Plan A document describing the approach to safety and individual safety activities to be taken in order for a project to achieve the safety objectives

Safety Lifecycle The series of phases from initiation through to decommissioning of a system, covering design and development of safety features

Sub-System Hazard Analysis A type of hazard analysis that focuses on hazards that can arise from the detailed design of the project system, by systematically examining the design of each sub-system

System Any collection of equipment, people and procedures that work together to achieve a common goal. This may include: The carriageway and associated infrastructure (lighting, barriers,

markings, drainage, etc.) The telematics equipment People involved in operations and maintenance, and the procedures

by which they work System Hazard Analysis A type of hazard analysis that focuses on hazards that can arise from the

project system design Type A Project Feature A project feature requiring a basic safety management be applied Type B Project Feature A project feature requiring a moderate level of safety management to be

applied Type C Project Feature A project feature requiring rigorous safety management to be applied Validation Activities carried out to determine whether the project satisfies the

requirements of its intended use Verification Activities carried out to show that the project meets its safety

requirements


IAN 139/11 of 266 Mar 11


Abbreviation Definition CDM Construction Design and Management FMEA Failure Modes and Effects Analysis GSN Goal Structured Notation HA Highways Agency HSMS Health and Safety Management System IHA Interface Hazard Analysis KSI Killed or Seriously Injured MP Major Projects NDD Network Delivery and Development NetServ Network Services Directorate OSHA Operational Support Hazard Analysis PAR Project Appraisal Report PHA Preliminary Hazard Analysis POPE Post Opening Project Evaluation SHA Systems Hazard Analysis SMS Safety Management System SSHA Sub-systems Hazard Analysis TAR Technical Appraisal Report

Interim Advice Note 139/11 Guidance for Work Instructions 004: Managed Motorways Safety Risk Mangement for Projects with Type C Features Safety Risk Working Instructions

IAN 139/11 of 266 Mar 11


Safety Risk Management for Projects with Type C Features SUMMARY This Guidance is part of the Agency’s

HSMS. It provides guidance on how to meet the requirements for safety risk management for MM projects with Type C features




APPLIES TO MM projects classified as Type C/having Type C requirements

VERSION 1 STATUS (Final/Draft) FINAL THIS DOCUMENT REPLACES None – new document DISTRIBUTION Intranet REVIEW DUE DATE 2010



IAN 139/11 of 266 Mar 11

Contents 1. Guidance On Work Instructons 004: Saftey Risk Management For Projects With

“Type C” Features 142

2 Introduction 143 2.1 Background 143 2.2 Objective 143 2.3 Scope 143 2.4 Implementation 143 2.5 Responsibility for Applying this Work Instruction 144 3 Summary of Safety Management Activities 145 4 Safety Baseline and Safety Objectives 146 4.1 Objective 146 4.2 Selecting a Safety Baseline 146 4.3 Identifying a Safety Objective 148 4.4 Deliverables 149 4.5 Approval Requirements 150 5 Safety Strategy and Plan 151 5.1 Objective 151 5.2 Document Evolution 151 5.3 Safety Strategy and Plan Requirements 151 5.4 Deliverables 156 5.5 Approval Requirements 159 6 Risk Assessment Activities 160 6.1 Overview of Activities 160 6.2 Preliminary Hazard Analysis (PHA) 161 6.3 Deliverables 163 6.4 System Hazard Analysis (SHA) 165 6.5 Sub-System Hazard Analysis (SSHA) 166 6.6 Interface Hazard Analysis (IHA) 167 6.7 Operational and Support Hazard Analysis (OSHA) 168 7 The Hazard Log 177 7.1 Objective 177 7.2 Hazard Log Requirements 177 7.3 Deliverables 179 7.4 Approval Requirements 179 8 Verification and Validation 180 8.1 Objective 180 8.2 Verification and Validation Requirements 180 8.3 Deliverables 181 8.4 Approval Requirements 181 8.5 Additional Guidance 182


IAN 139/11 of 266 Mar 11

9 Production of a Safety Report 183 9.1 Objective 183 9.2 Requirements 183 9.3 Deliverables 187 9.4 Approval Requirements 190 10 Updating Safety Documentation During Operation 191 10.1 Objective 191 10.2 Requirements 191 10.3 Deliverables 191 10.4 Approval Requirements 191

11 Safety Acceptance And Approval Process 192


IAN 139/11 of 266 Mar 11

1. GUIDANCE ON WORK INSTRUCTION 004: SAFETY RISK MANAGEMENT FOR PROJECTS WITH ‘TYPE C’ FEATURES

This document provides guidance on the application of Work Instruction 004 - Safety Risk Management for Projects with Type C Features. It describes how to apply Work Instruction 004. In this document, the phrase “No further guidance is provided – all required information is within the Work Instruction itself.” means that the information provided in the Working Instruction is self explanatory.


IAN 139/11 of 266 Mar 11

2 INTRODUCTION 2.1 Background Work Instruction 004 describes how to apply an appropriate safety management system to a project with Type C characteristics. These projects are those with the most rigourous safety management requirements. It may be the case therefore that a project will need additional external support in fulfilling the requirements for the safety management of Type C projects and in applying Work Instruction 004. 2.2 Objective No further guidance is provided – all required information is within the Work Instruction itself. 2.3 Scope No further guidance is provided – all required information is within the Work Instruction itself. 2.4 Implementation Work Instruction 004 is applicable to all projects where Type C Safety Management System (SMS) activities are appropriate. Work Instruction 004 applies to all HA staff and directly supervised contractors and consultants who work for, or with, the HA that are required to perform identical or similar duties to HA staff on a Type C project. It also applies to the activities of the Agency’s Supply Chain consultants and contractors who work on a Type C project. In implementing Work Instruction 004 it may be possible to make use of existing safety related work/documentation. Any existing piece of work deemed to be appropriate for re-use in the application of this Work Instruction must be thoroughly reassessed before use. The work should not simply be copied over and incorporated within the new project. Following Construction Design and Management (CDM) Regulations 2007 CDM Regulations are intended to focus attention on planning and management throughout construction activities, from design concept onwards. Their main aims, from a safety perspective are to identify hazards early on, so they can be eliminated or reduced at the design or planning stage, and to manage the remaining risks properly. The project safety risk management procedures described in the Work Instructions and those procedures carried out as part of CDM are two separate processes. However, some of the activities carried out as part of these processes will be the same. When considering the requirements of CDM all activities performed during the application of the Work Instructions should be reviewed to see if some are also applicable to CDM. Where this is the case, the activity need not be repeated for CDM.


IAN 139/11 of 266 Mar 11

Impact on Resources If the application of Work Instruction 001 results in a Type C project classification, satisfying the SMS requirements will have a bigger impact on the overall project cost and an increased level of resources will be required to support the relevant SMS activities. This effect is due to the following: Rigour of SMS activities – Type C projects require the most rigorous SMS (and therefore

associated safety activities) to be applied. Type C projects will involve a greater number of resources and the activities will take up a greater amount of time. It may also be the case that a Type C project will need additional external support in fulfilling the SMS requirements

Number of applications - It will usually be the case that Type C projects require the

greatest number of Departure from Standard applications owing to the complexity of the projects and the increased likelihood of changes being introduced to the project which will require reassessment

2.5 Responsibility for Applying this Work Instruction No further guidance is provided – all required information is within the Work Instruction itself.


IAN 139/11 of 266 Mar 11

3 SUMMARY OF SAFETY MANAGEMENT ACTIVITIES

The interaction between the project (design) lifecycle and safety lifecycles will often mean that iterations around some parts of Figure 2-1 in Work Instruction 004 are needed. These iterations will chiefly apply to cases where safety analysis identifies new requirements to be implemented by design. Whatever design solution is then proposed will need to be subject to further safety analysis to make sure that no new uncontrolled hazards are introduced.


IAN 139/11 of 266 Mar 11


4.1 Objective As described in Work Instruction 004, the safety baseline for a project is the level of safety against which achievement of the safety objective is measured. It is a measure of the current level of safety before the project has been implemented. The safety baseline therefore needs to be expressed in a way that reflects the nature of safety objective i.e. a quantitative safety objective will require a quantitative safety baseline, whereas a more qualitatively expressed objective would warrant a qualitative safety baseline. A qualitative safety baseline may be expressed as a description of the safety performance associated with a particular set of features of the infrastructure that are assumed to be present before the project is implemented. This does not always mean that all of the features are actually present at the time of setting the baseline but may include additional features that will be installed to reflect the current Agency standards and aspirations for the motorway. A quantitative safety baseline may be expressed as the number of those currently killed or seriously injured on a particular stretch of road. For Managed Motorways, a quantitative target of a 15% safety improvement is expected to be documented in the PAR, as outlined in Work Instruction 004. The table below defines some of the terms commonly used in setting safety baselines and objectives for projects:

Term Definition Road User Drivers, passengers, motorcyclists, cyclists, pedestrians and accompanied

animals that make use of the highway. Emergency services and vehicle recovery operatives are also included in this category

Road worker/Workforce Anybody whose job function has to be carried out on part of the highway. This term includes construction operatives and Traffic Officers

Third Parties Third parties should be considered as those members of the public who live in the vicinity of the proposed project scheme

Qualitative Safety Objective

A safety objective which is expressed in terms of a description of characteristics rather than an exact numerical measurement

Quantitative Safety Objective

A safety objective which is expressed using numerical values

Agency Safety Targets PSA (Public Service Agreement) targets aimed at improving road safety by a given target year

Table 4-1 Definition of commonly used terms 4.2 Selecting a Safety Baseline The steps to follow when setting a safety baseline are as follows: Assess current Road Conditions at the location affected by the project. The safety

baseline should reflect the current state of the location without any intervention from the project

Assess whether any of the project features would be provided as standard on an upgrade to the affected infrastructure. For example, HA aspirations state that whenever work on the central reserve is carried out, it should be upgraded to a rigid concrete safety barrier. If work on the central reserve was to be carried out as part of a project which did not explicitly set out to upgrade the central reserve, an upgraded concrete central reserve should be included in the safety baseline. If the upgraded reserve was not included in the safety baseline then the safety benefit added by the project alone could be unrepresentative as the benefits gained from implementing a central reserve will have also been incorporated


IAN 139/11 of 266 Mar 11

Determine whether the project involves the implementation of new road infrastructure. Where the project is providing infrastructure and it is completely new (e.g. a new road), then one possible approach that can be used to define the safety baseline would be to determine the route that would have been taken prior to the new infrastructure being added and consider the safety level presented in that case. For example, in considering a safety baseline for a road such as the M6 Toll Road, safety levels on the M6 (Normal) or A38 would be calculated. Alternatively the project could look at the level of safety provided by a similar project, if one exists, and derive a baseline from that

Determine whether the project is a Pilot or Trial. As described in Work Instruction 004 a Pilot or Trial project may require a different safety baseline to those applied to other projects. If only a very small section of the infrastructure is being affected by the trial it may be inappropriate to set the current level of safety as the baseline

Determination of the safety baseline will be a project specific activity. However, the following example shows how the steps above are used to provide a safety baseline for one scenario:

Example – Derivation of a Road User safety baseline for a project to convert parts of a motorway from the Dual 3-Lane Motorway (D3M) design to a Compact Motorway Design (CMD) Project background: The proposed project involves introducing an additional lane into the existing motorway boundaries. Each of the four lanes will therefore be slightly narrower than the standard lanes. For breakdowns and in order for emergency services to access incidents, a ‘hard strip’ plus hardened verge will replace the hard shoulder. Over each lane Advanced Motorway Indicators (AMIs) will provide signalling for variable speed restrictions. Emergency Refuge Areas (ERAs) will be provided to accommodate vehicles that have broken down.

Assess current Road Conditions at the location affected by the project: The current road conditions are standard Dual 3-Lane Motorway. MIDAS is not currently provided.

Assess whether any of the project features would be provided as standard on an upgrade to the affected infrastructure: In this example MIDAS loops are considered as a standard feature because they are added to ALL

motorway projects whenever new work in undertaken regardless of their use. For this reason they should not be considered as part of the safety benefit added by the project

Determine whether the project involves the implementation of new road infrastructure: Since this project does not involve the creation of a new road infrastructure, this step is not applicable in

deriving the baseline for this project Determine whether the project is a Pilot or Trial In this case the project is neither a Pilot nor Trial and so the safety baseline does not need to address this

The following options were considered for the safety baseline: Option 1: Typical Dual three Lane Motorway (D3M) without MIDAS and MS3s Option 2: Typical D3M motorway with MIDAS and MS3s Option 3: Prior to the implementation of MIDAS and MS3s and Controlled Motorway on four narrow lane

sections Option 4: Current communications infrastructure sections (only part of which includes MIDAS and MS3s) Option 5: MIDAS and MS3s on 3 lanes, prior to the implementation of Controlled Motorway on four

narrow lane sections N.B. ‘MS3’ refers to “Motorway Sign Mark 3”


IAN 139/11 of 266 Mar 11

Example – Derivation of a Road User safety baseline for a project to convert parts of a motorway from the Dual 3-Lane Motorway (D3M) design to a Compact Motorway Design (CMD) Options 1 and 2 relating to a ‘typical’ D3M motorway were not selected for the baseline because they do not reflect current road conditions. It was considered preferable to use the actual motorway sections of the motorway in question, which may have different characteristics to ‘typical’ motorways. Option 3 was not selected as it does not represent the current conditions of the road. It represents Motorway Improvements in sections prior to implementation of MIDAS and MS3s which neither represents the current configuration, nor is it representative of current HA standards and aspirations for the motorway. Option 4 was not selected because it would be difficult to set an appropriate safety objective using this as the baseline, because of the large number of different levels of communications infrastructure over all the motorway sections. It is considered too difficult to estimate what additional level of safety benefit would be achieved by implementing MIDAS and MS3s as part of the project. It was proposed that Option 5 should be used as the safety baseline because it best represents current conditions and takes into account any features that are introduced as standard. Option 5 should still be used as the safety baseline for Road Users even though MIDAS and MS3s are currently not present on the motorway sections (note that worker risk was considered elsewhere). It was chosen because it represents the current HA standard and aspirations for motorways which include adding MIDAS loops wherever possible. It was accepted that the disadvantage of Option 5 as a baseline is that it will not be possible to take actual measurements of the safety performance of motorway sections with MIDAS and MS3s, as this will never exist as a stage in the programme of work. Therefore, when taking measurements for the baseline it will be necessary to estimate what the safety performance would have been had MIDAS and MS3s been installed.

Table 4-2 An Example: How to Select a Safety Baseline for a Project

4.3 Identifying a Safety Objective To address the considerations listed in Work Instruction 004, the steps to follow when setting a safety objective are as follows: Consider whether you are setting an objective for a Road User or for the Road Worker,

as the type of objective will differ depending on which category you are setting the objective for

Consider the safety impact of the features to be implemented Consider the improvement in the level of safety that is required after project completion Consider the Agency’s national safety targets and take these into account when setting

the safety objective, for example the PSA targets for 2010. It is useful to think about how the project can contribute to achieving these targets

Consider the timescale of the project. For example, if the project will take a long time to construct it would be unwise to set safety objectives which aim to improve safety straight away, as these are unlikely to be met. Any objectives must factor in the time that will be needed to achieve the objective

If the project is a Pilot or Trial, consider whether this affects safety objective selection and if so how. It may be possible with a Pilot or Trial to have a less rigorous safety objective. This is because with some new interventions, where no previous experience of their implementation has been gained predicting the level of safety in operation can be difficult. It can be possible to justify a lower safety objective in order to allow the Pilot or Trial to proceed and in order for more accurate measures of the safety benefit to be obtained by carrying out the Pilot/Trials itself. In progressing to any wider roll out of such an intervention the safety objective would need to be revisited and adjusted accordingly

Under normal circumstances, these steps will not be needed owing to the HA selecting a safety objective to be applied to Managed Motorways projects. For Road Workers: No further guidance is provided – all required information is within the Work Instruction itself.


IAN 139/11 of 266 Mar 11

For Road Users: No further guidance is provided – all required information is within the Work Instruction itself. For Third Parties: It is not normally necessary to set separate safety objectives for third parties. However, it may be necessary to review those hazards that can affect third parties in order to understand how they are affected by a project and to show that where appropriate, necessary mitigations have been applied. Safety Baseline and Objectives and the relationship with the Project Risk Assessment Methodology The choice of the project safety baseline and the associated safety objectives will have an impact on the type of risk assessment methodology that is appropriate for the project. The risk assessment methodology needs to support the measuring of the achievement of the safety objective. Therefore a more qualitative baseline/objective will require a more qualitative approach to risk assessment. If insufficient data is available to substantiate risk assessment results, it is not possible to use a substantially quantitative risk assessment methodology and may not be sensible to set a quantitative safety objective. In some cases it may be possible to use a semi-quantitative approach. 4.4 Deliverables The following table provides an expanded version of Table 4-1 in Work Instruction 004 showing the typical content of a Safety Baseline and Objectives Report:

Section Reference Safety Baseline and Objectives Report Content Guidance 1. Introduction This section provides a brief overview of the project and the need for a safety

baseline 1.1 Project Overview Project Overview: The project overview should provide a brief background to the

project, a description of the project’s design features and the reasons why the project is being considered for implementation. The overview may include the following subsections Project Background: this includes details such as the location of the project (i.e. where the project is to be implemented and the road/tunnel systems it applies to), the position of this particular project within the context of any wider project or programme, the main phases in which the work will be undertaken (e.g. the order in which different stretches of road will be affected and different operational methods/technology will be introduced, as well as a description of the planned project phases and a list of the project team members who will be responsible for delivering each of the planned phases) Design Features: this refers to the design features and design principles which the work will adopt. This will include a description of the equipment used (carriageway and associated infrastructure lighting, barriers, markings, drainage, etc.], technology based equipment), the personnel involved in operations and maintenance, and the procedures by which they work The need for the project under consideration: e.g. alleviating congestion and the associated problems (such as widely varying journey times, the effects and costs to businesses based in the area, issues of safety)

1.2 Document Objective(s)

This section should outline the objectives and context of the document produced. It should provide a succinct summary of what the document hopes to achieve

1.3 Document Scope This section should include information outlining the scope of the document. Consider what areas the project will apply to and how the document will evolve throughout project lifecycle. It might also be useful to state any specific areas that the document will not include but may have been thought of as relevant

2. Safety Baseline Options

Description of the different baseline options chosen and the reasons behind the choice made

2.1 Review of safety Baseline options for Consideration

Each of the options for the safety baseline that have been considered should be described


IAN 139/11 of 266 Mar 11

Section Reference Safety Baseline and Objectives Report Content Guidance 2.2 Safety Baseline

Selection The selection criteria used to assess the different options should be explained, along with how they were applied to each of the options. The option chosen should be stated, with the clear rationale behind this choice

3. Safety Objective Options

Description of the project safety objective options

3.1 Influencing factors This section should consider the DfT and HA targets that will influence the safety objective. A review of these targets should be described, and any conclusions drawn in relation to this project should be summarised. Reference should be made to both Road User and the Road Workers safety objectives

3.2 Project Specific Risk Objectives

This section should review any project specific risks that need to be taken into account.

3.3 Safety Objective Selection

This section will discuss the main issues considered in setting an appropriate objective for the project. The Objectives considered for the project should be listed, with the pros and cons of each. The proposed overall objective should be stated, along with a rationale for this choice. Discussions may revolve around Road Worker and Road User risk

4. Proposed Baseline and Objectives

Summarise the conclusions of the preceding chapters, defining the proposed project baseline and the project safety objectives along with a description as to how and why they have been chosen

Table 4-3 Guidance on Contents for a Safety Baseline and Objectives Report

4.5 Approval Requirements No further guidance is provided – all required information is within the Work Instruction itself.


IAN 139/11 of 266 Mar 11

5 SAFETY STRATEGY AND PLAN

5.1 Objective No further guidance is provided – all required information is within the Work Instruction itself. 5.2 Document Evolution The project is responsible for all versions of the Safety Strategy and Plan until commencement of operation, when it then becomes the responsibility of the operator/ maintainer. The operator/ maintainer should be involved with safety management activities at as early a stage as possible so that the transfer of responsibility is smooth and the operator/ maintainer understands clearly what is needed to support ongoing safety management. The Safety Strategy and Plan is a continually evolving document and should be re-issued following key changes. Typically in a project, the following main releases would be expected: Preliminary Design Safety Strategy and Plan. This version summarise all of the safety

activities that will be undertaken Detailed Design Safety Strategy and Plan. By this stage, the design of the project will

be largely complete. The Safety Strategy and Plan will now provide detail on the safety activities that are still to be undertaken prior to operation/ maintenance and will also document any changes from the initial set of safety activities undertaken (for example, whether a Sub-System Hazard Analysis is necessary)

The exact number of releases of this document that are required is a project specific consideration. 5.3 Safety Strategy and Plan Requirements Summary of the Results of applying Work Instruction 001 No further guidance is provided – all required information is within the Work Instruction itself. Definition of the project safety baseline and objectives A description and short justification of the Project Safety Baseline and Objectives (as determined in the last section of Work Instruction 004) should be included in the Safety Strategy and Plan. Description of the safety analysis activities No further guidance is provided – all required information is within the Work Instruction itself.


IAN 139/11 of 266 Mar 11

A description of the project organisation and safety organisation Project Organisation The Safety Strategy and Plan provides details on the areas listed below: A description of the overall project organisation. This should cover the main lines of

responsibility and how those lines interface to the Highways Agency A description of the roles within the senior organisation such as the Project Director and

Project Manager A description of all of the key roles within the project and who is carrying out these roles

(it is useful to illustrate this as an organisational chart) e.g. descriptions of:

– The Project Manager – The Project Manager’s team

(Technology/Infrastructure/Safety/Communication/Stakeholder management) – The Project Director – The Managing Consultant – The Integration Manager – The Work Stream Managers

(Operations/Technology/Infrastructure/Site/Communications/Stakeholder Management/Maintenance/Safety)

Safety Organisation A description of the following should be given: The Project Team as a whole (who it is being managed by and reference should be made

to any separate contracts that may be involved in developing parts of the project) The Project Safety Team as a whole and who it is being managed by Any additional safety roles (these may change from project to project and during the

project life as the need for different specialist safety roles becomes apparent) A typical structure is shown below:

Project Manager

Safety Steering Group

Delivery Consultant

Delivery Team

Project Safety Team

Project Manager

Safety Steering Group

Delivery Consultant

Delivery Team

Project Safety Team

Figure 5-1 A Typical Safety Organisation for a Type C Project


IAN 139/11 of 266 Mar 11

The different groups and individuals shown in Figure 5-2 are explained below. The Project Leader. The Project Leader is a member of the Safety Steering Group

and/or Safety Approval Group and is responsible for the development of the project The Safety Steering Group. The Safety Steering Group will be the NSCRG as

described in the document ‘Managed Motorway Schemes, National Safety Control Review Group and Project Safety Control Review Groups, Remit for Organisation and Governance’.

The Project Safety Team. The Project Safety Team will be the PSCRG, as described in the document ‘Managed Motorway Schemes, National Safety Control Review Group and Project Safety Control Review Groups, Remit for Organisation and Governance’. The Project Safety Team will have overall responsibility for demonstrating that the project safety objective is achieved

Project Delivery/Project Delivery Consultant. The Project Delivery Team/Consultant is responsible for delivering all aspects of the project

The Delivery Team. The HA Team interacts directly with the Project Delivery Team/Consultant, ensuring that the Agency objectives are met

Approach to approval No further guidance is provided – all required information is within the Work Instruction itself.


IAN 139/11 of 266 Mar 11

Procedures to control the project Management of Sub-consultants The Safety Strategy and Plan should document how any sub-consultants involved in the project will be managed. This information could include details of the following: How the sub-consultants are selected and registered How the sub-consultants brief will be formulated. How sub-consultants will be monitored and controlled How the performance of sub-consultants will be evaluated (including a description of the

criteria they must fulfil) Details of the formal procedure to be followed for recording approval of sub-consultant

work Document Control, Tracking Procedures and Change Control Management The Safety Strategy and Plan will define the document control, tracking procedures and change control management methods that will be implemented by the project. Putting such processes in place: Ensures that everyone uses the most current and up to date processes and procedures Ensures all stakeholders have an opportunity to participate in the control of any

subsequent changes Ensures all recipients are made aware of any changes that occur Ensures there is an audit trail which connects a change to an item with the reason for its

change, and which records the participation and authorisation of those people concerned with the change

Effective Change Control An effective change control procedure should: Identify an ‘owner’ for the item that it being changed. The ‘owner’ is then responsible for

the change control of the item Support proper version control Allow for formal acceptance and approval of the change Allows all those affected by the proposed changes to be informed and consulted Provide an audit trail of the development of the changes Action Tracking An action tracking system should be chosen for a project and documented in the Safety Strategy and Plan. Such a system may be used for all kinds of actions but it is important that some process is in place for actions that relate to safety management. Safety actions will need tracking both before and after project operation commences. One of the main purposes of tracking actions once the project is operational is to support monitoring activities when the occurrence of an incident may lead to some additional safety analysis or risk assessment being needed.


IAN 139/11 of 266 Mar 11

The Action Tracking System for a project is usually based around the production of action plans, which will be centrally tracked until resolved. The process should be: Simple, but captures sufficient information to allow:

– Tracking of actions – Sorting and searching of the actions

Available to all members of the project so that they can review and update their own actions

Effective in helping project members complete actions, rather than distracting them with a cumbersome process

Typically such a system will operate via the Hazard Log allowing actions to be associated with particular hazards and tracked to closure in a similar way to the hazards themselves

Security Each project will need to put in place sufficient security arrangements so that project related data is kept sufficiently secure. The details of such security arrangements are outside the scope of this document but advice is available from elsewhere within the Agency. Details and descriptions of Safety Audits The Safety Strategy and Plan should include the details of any project safety audit activities which may include project internal audits and Road Safety Audits. Project Internal Audits – Monitoring Adherence to the Safety Strategy and Plan The main objective of all the internal safety audits is to examine adherence to the Safety Strategy and Plan. The project is expected to carry out such audits periodically. It is a responsibility of the safety team to develop an audit remit to check specifically for this adherence and to develop an associated audit programme. Road Safety Audits In parallel to the activities described in the Safety Strategy and Plan and the internal audit activities, the four stage Road Safety Audit process will be undertaken, as it is mandatory for all highways schemes. Details to be documented in the Safety Strategy and Plan include: The project audit requirements The project audit programmes Results from any audits that have already been carried out (this will be updated as the

project progresses and the Safety Strategy and Plan is re-released) A description of the main safety documentation The PCF product page for the MM Safety Plan is available at: http://portal/portal/server.pt?open=space&name=CommunityPage&id=2&cached=true&in_hi_userid=17086&control=SetCommunity&PageID=0&CommunityID=914&WG_link=http://portalweb/minisite/hawww/www/MP/PCF_Mockup_2/Product_Groups/New_Groups/../../Products/Safety_Plan.html An analysis of the project’s competency requirements All people involved in safety management activities should have the appropriate training, technical knowledge, experience and qualifications for the work they have to perform. The training, experience and qualifications of all persons involved in the safety management activities should be assessed in relation to the particular application. A useful reference providing guidelines on assessing and recording competencies of staff working on all aspects of safety-related applications is the ‘Comprehensive Competency


IAN 139/11 of 266 Mar 11

Guidance’, produced by the Institute of Engineering and Technology (IET) in collaboration with the British Computer Society (BCS) and the Health & Safety Executive (HSE). These guidelines cover the whole supply chain, including provision of contract services and the main engineering functions. The training, experience and qualifications of all persons involved in safety activities should be documented. A useful tool for determining and assigning roles and responsibilities and hence in assisting in establishing competency requirements is the RACI (Responsible, Accountable, Consulted, Informed) Matrix. See the Appendices section of the Guidance for further details on RACI. Ownership The Safety Strategy and Plan is ‘owned’ by the project until operation commences. When operation begins, Safety Strategy and Plan ownership would be expected to transfer to the operator, NDD (Network Delivery and Development). Prior to commencement of operation NDD should be aware of and should accept the content of this strategy. In practice handover will involve a period of transition while NDD becomes sufficiently familiar with the requirements of the Safety Strategy and Plan. There are a number of ways in which this could be achieved but it is recommended NDD has a place on the PSCRG in order that its views can be taken into account throughout approval activities. 5.4 Deliverables The deliverable from this phase of the safety life cycle is the Safety Strategy and Plan. The following table provides an expanded version of Table 5-1 in Work Instruction 004 as to the typical content of a Safety Strategy and Plan:


IAN 139/11 of 266 Mar 11

Section Reference Content Guidance 1. Introduction 1.1 Project Overview Project Overview: The project overview should provide a brief background to the project, a description of the project’s design features

and the reasons as to why the project is being considered for implementation. The project Overview may include the following subsections: Project Background: details such as the location of the project i.e. where the project is to be implemented and the road/tunnel systems it applies to, the position of this particular project within the context of any wider project programme, the main phases in which the work will be undertaken e.g. the order in which different stretches of road will be affected, order of introducing different operational methods/technology and a description of the planned project phases along with the members of the project team that will be responsible for delivering each of the planned phases Design Features: the design features and design principles the work will adopt. This will include a description of the equipment (carriageway and associated infrastructure (lighting, barriers, markings, drainage, etc.), the technology based equipment), the people involved in operations and maintenance, and the procedures by which they work e.g. expanding the number of motorway lanes, introduction of emergency refuge areas, the new technology that will be implemented Need for the project being considered: e.g. alleviating congestion and the associated problems such as widely varying journey times, the effects and costs to businesses based in the area, issues of safety

1.2 Document Objective and Context

This section needs to include a clear definition of the objective of the safety strategy. Typically, this would be “the main objective of the Safety Strategy is to provide an agreed approach to ensure that the project delivers an adequate and appropriate level of safety”

1.3 Document Scope (Determining the scope of the Strategy)

The scope of the strategy is to be clearly defined. Reference can be made to the following: The phases of the project it is applicable to The extent to which insurance of maintenance and operational procedures will be provided

2. Selection of the Project Safety Management System

The background behind applying the Work Instruction should be documented. Include a description of the background behind the application of Safety Risk Management The project scope should be included here. It is important because it is central to identifying the SMS Type correctly Based on Table 2.1 in Work Instruction 004, this section should also demonstrate how the project features were categorised. A copy of Table 2.1 from WI 004 could be included indicating which Types were selected for each feature. Justification for Project Feature categorisation should also be included This section should also state the implications of Work Instruction 001 on the SMS. This could include a statement of the rule that was followed in selecting the subsequent SMS based on the project features

3. Project Safety Lifecycle Activities

This section should be broken down into descriptions of the individual safety activities that will be carried out by the project – the majority of these activities are described in detail in Work Instruction 004. It is useful to show this as a project life cycle diagram. In this diagram it may also be useful to show the timing of any safety audits to be carried out and the project construction phases. This will put the safety lifecycle into context. It should be clear from the description of each activity, whether or not the activity has been carried out, how it will be carried out and the main outcome of the activity

3.1. A description of the project safety acceptance and approvals process

This section will document the safety acceptance and approvals process. The following should be mentioned: Verification Agreement Acceptance Approval

3.2 Safety Baseline and Objectives

This section needs to describe how the safety baseline and corresponding safety objectives have been derived. It may be of benefit to produce a separate document justifying the choice of safety objective that should be set (the Safety Baseline and Objectives report)


IAN 139/11 of 266 Mar 11

Section Reference Content Guidance 3.3 Hazard Identification,

Analysis and Risk Assessment

The approach to risk assessment taken for a particular project is usually documented in a separate report. It is useful however, to provide a brief summary of the risk assessment approach and methodology in the safety strategy and plan

3.4 Hazard Log Production This section should include information on the type of Hazard Log used, how it will be maintained and the structure 3.5 Safety Report Production This section includes a description of what the Safety Report will include and its objective. Any limitations to the report should be

mentioned. It will also include detail on the Safety Report structure and the maintenance of the Safety Report 4. Additional safety Activities This section should include a description of any additional safety activities that might need to take place. These might include mandatory

Road Safety Audits, projects safety audits and maintenance and operational safety requirements 5. Overview of Safety

Deliverables This section should outline the principle safety deliverables produced by the project. These might include: Safety Strategy and Plan Safety Baseline and Objectives Report Hazard Log System Hazard Analysis Commencement of Operational and Support Hazard Analysis Design for Safety Reviews Design Safety Report

6. Programme Management and Control

This section should indicate the timeline of proposed events in a work programme. It should also include a description of how the management of sub-consultants will be undertaken, and also note any safety requirements documentation and tracking procedures

7. Project Team and Safety Roles

7.1 Safety Approval This section should include description of who is responsible for project safety approval and the approval process through which the project must follow. A reference should be given to the description of the safety approval approach that should be provided in the Safety Strategy. An organisational chart could show the names of responsible individuals, where these are known and applicable, as well as their position and their role interactions

7.2 Project Organisation A section describing specifically the project organisation, including the main lines of responsibility within the project team, and how those lines interface with one another

7.3 Project Safety Team and Project Safety Organisation

Although safety activities are undertaken within and across all work streams, a safety team is usually nominated to support the safety activities and lead much of the safety analysis work. This section should include a description of this team and the names of those carrying out the defined roles If the project team is split into principal work areas this should also be defined. This may also include a diagram of the project team organisational structure It will also provide an overview of the project’s safety organisation along with a more detailed description of the relevant roles and responsibilities This section should also provide additional information on safety competency requirements of the project and how these are addressed

7.4 Key Safety roles (Any additional key safety roles)

This section is an expansion of that above and provides details of the safety team roles. Examples of roles that may be applicable include the: Project Safety Team and safety Team Manager PSCRG

Table 5-1 Safety Strategy and Plan Content Guidance


IAN 139/11 of 266 Mar 11

5.5 Approval Requirements Circumstances when it may be necessary to submit the Safety Strategy and Plan for wider approval (i.e. NSCRG) include projects that have an especially large impact on safety, that are especially environmentally sensitive or that have a large impact on third parties.


IAN 139/11 of 266 Mar 11


6.1 Overview of Activities

6.1.1 Hazard Analysis What is a Hazard? A hazard is a condition that could lead to harm/is a source of potential harm to an individual. It can arise from either failure to perform a certain function or procedure, or it can arise from incorrect function or procedure specification. What is the Purpose of Hazard Analysis? Identifying potential hazards and the associated collision sequences for a project scheme is the first step in assessing and managing risk. Once a hazard is identified, it can be mitigated. Through identifying hazards from an early stage and throughout the project, the design of the project can be modified to either remove hazards completely or reduce risks as soon as they are identified. Thus the process should start as soon as a high-level description of the system is available. The General Process for Identifying and Analysing Hazards The general process for all hazard analysis activities is as follows: Define the project scheme features to be analysed making sure they are recorded along

with any relevant technical/design information and drawings Identify any hazard that have already been identified from existing work that are

applicable to the project Review the previously identified hazards and determine their applicability to the project Identify any new hazards that may apply to the project by considering each of the project

features. Examples of where hazards and collisions could arise include:

– Systematic or random failures – The defined operating environment – Misuse and erroneous operation – Common cause/common mode failures – Interactions between systems/sub-systems – Procedural, managerial and human factors activities e.g. driver behaviour

Conduct a risk assessment on each of the identified hazards (the following sections provide more information on risk assessment, and the appendices to this guidance provides detail on types of risk assessment methodologies to be used)

Create a hazard log to document all of the hazards with the relevant risk scoring information

Write a report to document the hazard analysis results A typical way of carrying out the hazard analysis process is in a workshop environment with attendees chosen to represent the particular area of the project being examined and those with the relevant safety expertise. Work Instruction 004 describes in detail the principal types of hazard analysis activities that should take place in order to identify all of the hazards associated with a project and the process to be followed in order to perform them. The hazard analysis process is iterative. Inevitably, new safety requirements will be derived as the system evolves. The necessary parts of the process should be repeated as the project design progresses and new functions and procedures require analysis.


IAN 139/11 of 266 Mar 11

This iterative nature of the hazard analysis process highlights the importance of an effective action tracking and hazard management system. Having such a process in place will increase confidence in the safety management of the system. 6.1.2 Risk Assessment What is Risk? The risk associated with a hazard is a combination of two factors: the consequence of the resulting collision and the frequency at which such collisions occur. It is a measure of harm or loss associated with an activity. What is Risk Assessment? Risk assessment is the determination of a quantitative or qualitative value of risk related to a concrete situation and a recognised threat. The Need for Risk Assessment Risk assessment is important when designing any system with safety implications. It ensures that all of the relevant hazards have been identified and their relative severity determined in order to prioritise hazards for corrective action. The Risk Assessment Process Risk assessment is an iterative process. As a scheme develops, hazards should be re-examined to ensure that the risk assessments remain valid. Furthermore, additional hazards will undoubtedly be identified that need to be addressed. Figure 6-1 in Work Instruction 004 describes the different hazard analysis activities that should be performed throughout the project lifecycle in order to address ongoing hazard identification and risk assessment. Different approaches to risk assessment are available. Projects can choose which methodology to use, but a methodology that has previously been applied in conjunction with a Type C SMS is the semi-quantitative approach as described Appendix A of the guidance documentation. The risk assessment methodology chosen by the project must be appropriate for the type of safety baseline and objective that have been set. For example, if a quantitative baseline and objective have been set the project must ensure that there is sufficient, reliable data available to support a quantitative a risk assessment approach. 6.2 Preliminary Hazard Analysis (PHA) 6.2.1 Objective The PHA is the first formal analysis of hazards that a project undertakes. It should identify all the main hazards that the project is likely to encounter. Data Requirements in Advance of PHA As the PHA is initiated in the early stages of project development (i.e. during the planning stage) the data available about the project may be incomplete. The PHA should therefore be structured such that as the continual revision and updating of the design occurs, the analysis can be updated and modified. The following data are useful input information for PHA: Design sketches and drawings Any data describing the project elements Diagrams (e.g. flow diagrams) describing any proposed sequences of

activities/functions/operations A list of hazards that have been identified during the safety assessments carried out on

related projects


IAN 139/11 of 266 Mar 11

Applicable historical data from related projects 6.2.2 The PHA Process When a project is similar to a previous project the PHA will mainly consist of reviewing the analysis carried out for existing hazards. The list below is an expanded version of the steps that are outlined in Work Instruction 004 in respect of undertaking a PHA. 1. Determine the Project Model The project model will provide a list of project characteristics that can then be used as the basis for PHA discussions. Any further design information (written or diagrammatic) that is known at this stage should be used in addition to this list of features. The type of information that a project model would contain is given below in Table 6 2. Identify applicable hazards from existing work No further guidance is provided – all required information is within the Work Instruction itself 3. Conduct workshops to review existing hazards and identify other applicable hazards No further guidance is provided – all required information is within the Work Instruction itself 4. Initial risk assessment of each hazard As stated in Work Instruction 004, once the project model has been produced the risk assessment is carried out 5. Rationalisation and Organisation of the Hazards in the Hazard Log No further guidance is provided – all required information is within the Work Instruction itself 6. Documentation of the PHA results No further guidance is provided – all required information is within the Work Instruction itself A selection of the assumed features that may form the basis of the PHA for an example project

Design characteristics: Additional running lane Hard Shoulder Lay-bys Lane spacing Lighting CCTV cameras Gantry spacing

Gantry design Speed limits Safety barriers MIDAS spacing Central reserve details Cable cabinets Compliance Emergency Roadside Telephones

Operational characteristics: Maintenance and maintainer safety HA Staffing

Each characteristic is then expanded to provide detailed information. For example, the ERA spacing feature would include how far apart they are to be spaced (e.g. at 1km intervals) and their position in relation to the road itself. Speed limits would include a detailed description of the speed limit throughout the whole project location (e.g. 70pmh for 2 km, 50mph for 4km etc). These features and details are then used to supply the subsequent steps of the PHA with the required project detail. Each feature will be systematically examined in the discussion at the workshop to investigate the hazards that are applicable to the project (see step 3 in this document)

Table 6-1 – An example of the project characteristics that are used to create the project model


IAN 139/11 of 266 Mar 11

6.3 Deliverables Table 6-2 below provides more guidance to Table 6-1 in Work Instruction 004, to describe the content for a typical PHA Report. The areas greyed out are not included in Table 6-1 in Work Instruction 004, but might be a useful addition and should be considered for inclusion in the report.

Section Reference PHA Report Content Guidance 1. Introduction This section gives an introduction to the need for the PHA, its objectives and scope,

and how the outputs will be used 1.1 Project

Overview Project Overview: The project overview should provide a brief background to the project, a description of the project’s design features and the reasons why the project is being considered for implementation. The overview may include the following subsections: Project Background: this includes details such as the location of the project (i.e.

where the project is to be implemented and the road/tunnel systems it applies to), the position of this particular project within the context of any wider project programme, the main phases in which the work will be undertaken (e.g. the order in which different stretches of road will be affected and different operational methods/technology will be introduced, as well as a description of the planned project phases and a list of the project team members who will be responsible for delivering each of the planned phases)

Known Design Features: this refers to the design features and design principles which the work will adopt

Project Objectives: e.g. alleviating congestion and the associated problems (such as widely varying journey times, the effects and costs to businesses based in the area, issues of safety)

1.2 Previous applicable projects

Outputs from previous PHA’s can be used as input for the project but these must be reassessed. This section needs to reference any equivalent previous projects

1.3 Outputs from the PHA

An indication could be given of how the outputs will be used, e.g. how they will feed into the hazard log, the operational safety requirements report, the operational plan, operational procedures, maintenance requirements, maintenance plan, safety and maintenance procedures, etc

1.4 Structure of the PHA

The structure of the report could be outlined, including any techniques used to determine the structure, such as Goal Structured Notation. An overview of the safety argument could be given

2. Objective and scope of PHA

A brief statement is required on the objective of the PHA, e.g. “to conduct an initial examination of the project scheme and its environment to establish the hazards that could potentially arise from use of the proposed design, and to carry out an initial risk assessment of these hazards” The scope of the PHA should be defined, “e.g. the PHA covers all of the preliminary design features (both physical and operational) of the project at the time the PHA was conducted”. This should be accompanied by a list of all of the pertinent design features, with a brief description of each


IAN 139/11 of 266 Mar 11

Section Reference PHA Report Content Guidance 3. PHA

Methodology

3.1 Activities Carried Out

This section should include a brief overview of the PHA activities. These are likely to include the following: Initial identification of hazards An outline should be provided of the hazard review conducted once an initial set

of features has been agreed for the project scheme, the outputs of this, and how these were used

Rationalisation and organisation of the hazards into a hazard log This should explain how all the hazards identified by the initial identification

process were entered into the hazard log, and any grouping system used Initial analysis and risk assessment This should provide details of the analysis conducted for each hazard, including

initial cause and consequence analysis, initial risk estimation, identification of possible mitigation measures and an initial comparison with what is present currently on the motorway

PHA workshops Any workshops conducted to complete the identification and assessment of the identified hazards should be explained, with a list of workshop attendees provided and details of the approach adopted by the workshops

3.2 Risk Assessment Methodology

This section should provide a summary of the approach to risk assessment

3.3 Definitions A list of the definitions applicable to the PHA report should be provided, e.g. definitions of terms such as “hazard”, “risk” and “incident”. The definition supplied here will apply to any subsequent hazard analyses

3.4 The Hazard Log The hazard log should be briefly introduced, with detail on the type of system being used by the project in question. Further information should be provided on: The structure and content of the log- e.g. the hierarchy of Collisions, Hazards,

Causes and Sub-Causes within the Log The usage of the Log

3.5 Current Status of Analysis

An overview may also be given of the current status of analysis, e.g. the current state of the hazard log and scheme design development

3.6 Task Plans This section is relevant if a set of task plans will be developed and traced through the hazard log to mitigate particular hazards. A list of the known plans and their status should be provided

4. Identification of Higher Risk Hazards

This section should list those hazards with the highest risk scores. The highest-scoring hazards of both types should be recorded separately. Such hazards have the largest influence on the overall risk level of the project, and their mitigation has the greatest potential for reducing risk. The key issues arising for the project scheme from these hazards should also be explored

5. Next Steps in safety analysis process

This section describes the future activities of the safety programme for the project scheme, in order to show how the outputs of the PHA will flow into these other activities

5.1 Future Hazard Analysis Activities

The analyses to be conducted after the PHA should be listed, e.g. System Hazard Analysis, Sub-System Hazard Analysis, Interface Hazard Analysis, and Operational and Support Hazard Analysis

5.2 Other issues to analyse

This section should include a description of any further issues that should be analysed.

6. Conclusions This should summarise the findings so far, and explain the rationale for why, at this stage, the PHA provides confidence that the risk that will be presented by this project scheme is well understood

Table 6-2 Guidance on the Content of a PHA Report

Other possible formats for the report are possible and may be considered. The format should be tailored to reflect the nature of the project being analysed. 6.3.1 Approval Requirements Circumstances when it may be necessary to submit the PHA for wider approval (i.e. NSCRG) may include projects that have an especially large impact on safety, that are especially environmentally sensitive or that have a large impact on third parties.


IAN 139/11 of 266 Mar 11

6.4 System Hazard Analysis (SHA) 6.4.1 Objective The System Hazard Analysis examines the project in more detail than the PHA. 6.4.2 The SHA Process Data Requirements in Advance of SHA The SHA is initiated when outline design activities are complete and detailed design activities are in progress. The outcome of the PHA is essential input for the SHA. Other inputs will include: The latest design sketches and drawings Diagrams (e.g. flow diagrams) describing any proposed sequences of

activities/functions/operations Any additional applicable historical data from related projects that is available The list below is an expanded version of the steps that are outlined in Work Instruction 004 in respect of undertaking an SHA. 1. Further develop the model used in PHA It is expected that as the project life cycle progresses, more design information will become available. This new information should be used in the SHA project model. 2. Identify new hazards from existing work Although Work Instruction 004 states that Hazards from existing work may be used, it is important to be aware that existing hazards may present different risks on different projects. 3. Conduct SHA workshops No further guidance is provided – all required information is within the Work Instruction itself. 4. Assess Risk associated with new Hazards No further guidance is provided – all required information is within the Work Instruction itself. 5. Conduct ongoing analysis arising from the workshops No further guidance is provided – all required information is within the Work Instruction itself. 6. Capture all information in the Hazard Log No further guidance is provided – all required information is within the Work Instruction itself. 7. Document the SHA results No further guidance is provided – all required information is within the Work Instruction itself.

6.4.3 Deliverables The outcome of the SHA and the process followed will be documented in an SHA report. The format of the report is expected to be similar to that of the PHA (see Section 6.2) although other formats for the report are possible. 6.4.4 Approval Requirements Circumstances when it may be necessary to submit the SHA for wider approval (i.e. NSCRG may include projects that have an especially large impact on safety, that are especially environmentally sensitive or that have a large impact on third parties.


IAN 139/11 of 266 Mar 11

6.5 Sub-System Hazard Analysis (SSHA) 6.5.1 Objective No further guidance is provided – all required information is within the Work Instruction itself. 6.5.2 The SSHA Process Data Requirements in Advance of SSHA The SSHA, if needed, is initiated when the project is well advanced in its detailed design stages. The PHA will have already identified the initial safety requirements and hazards associated with the project, and the SHA will have examined the project systems in more detail. SSHA cannot be completed until design is complete. The outcomes of the PHA and SHA are essential input for the SSHA. Other inputs will include: The latest design sketches and drawings (these will have been updated since those used

in the PHA and SHA) Data describing the project subsystem components in detail Diagrams (e.g. flow diagrams) describing any proposed sequences of

activities/functions/operations Additional applicable historical data from related projects (especially with respect to the

project subsystems) The list below is an expanded version of the steps that are outlined in Work Instruction 004 in respect of undertaking an SSHA. 1. Define the sub-system design components No further guidance is provided – all required information is within the Work Instruction itself. 2. Review any existing analysis work for its applicability to the SSHA No further guidance is provided – all required information is within the Work Instruction itself. 3. Conduct SSHA Workshops and/or analysis Analysis of the subsystems can follow two approaches, which may be combined. These are: Workshop based review of subsystems Desk based safety Analysis At this level of design analysis, it is unlikely that new hazards will arise, rather it can be expected that new hazard causes may be revealed. A workshop approach is not always therefore required given that a more mechanistic approach is acceptable for this level of analysis. One type of desk based approach which can be used to analyse detailed design components is Failure Modes and Effects Analysis (FMEA)

1. FMEA – A Process for Examining Detailed Components 2. FMEA is a systematic way of identifying the consequences of the potential failures of

the designed sub-system components. Through identifying potential failures and their effects, the FMEA can identify additional mitigations

3. FMEA involves the collection and recording of the following: – The names of the sub-system components for analysis – The function of the components – The potential failure modes of the components – The potential causes of a failure – The probability that the potential cause of a failure mode will occur, where a

quantified failure rate is required – The consequences of a failure


IAN 139/11 of 266 Mar 11

– The means by which a failure will be detected – Recommended actions

4. Carry out assessment of risk No further guidance is provided – all required information is within the Work Instruction itself. 5. Capture all information in the Hazard Log No further guidance is provided – all required information is within the Work Instruction itself. 6. Documentation of the SSHA results No further guidance is provided – all required information is within the Work Instruction itself.

6.5.3 Deliverables No further guidance is provided – all required information is within the Work Instruction itself. 6.5.4 Approval Requirements Circumstances when it may be necessary to submit the SSHA for wider approval (i.e. NSCRG) include may include projects that have an especially large impact on safety, that are especially environmentally sensitive or that have a large impact on third parties. 6.6 Interface Hazard Analysis (IHA) 6.6.1 Objective The IHA only needs to be performed if: The project interfaces have not been sufficiently analysed in the PHA, SHA and OSHA

(the IHA should not duplicate the work carried out in the other hazard analysis activities). Interfaces can be checked by systematically working through all that exist within the project, both organisational and technical, and establishing whether they have already been analysed without conducting an IHA

Specifically the IHA examines sub-system and system interfaces for: Possible combinations of dependent and independent failures (both system and

organisational) that can cause hazards to the project scheme users or personnel Ways in which any proposed design changes to the interfaces may create new hazards Organisation interfaces involved in project operation and maintenance 6.6.2 The IHA Process The IHA takes place after the PHA and SHA have been completed. It may take place before or after the OSHA. During these other analyses it is possible that all the project related interfaces will be examined. Only when this is not the case is it necessary to perform an IHA. The following is useful input information for an IHA: The outcome from the PHA, SHA (SSHA if applicable) and if available, the OSHA The latest design sketches and drawings Any data describing the project elements Diagrams (e.g. flow diagrams) describing any proposed sequences of

activities/functions/operations Organisational charts of proposals for safety and project organisation Any applicable historical data from related projects


IAN 139/11 of 266 Mar 11

The list below is an expanded version of the steps that are outlined in Work Instruction 004 in respect of carrying out an IHA. 1. Define the interfaces No further guidance is provided – all required information is within the Work Instruction itself. 2. Analyse the flow between interfaces No further guidance is provided – all required information is within the Work Instruction itself. 3. Carry out assessment of the risk associated with new hazards No further guidance is provided – all required information is within the Work Instruction itself. 4. Capture all information in the Hazard Log No further guidance is provided – all required information is within the Work Instruction itself. 5. Documentation of IHA Results No further guidance is provided – all required information is within the Work Instruction itself.

6.6.3 Deliverables No further guidance is provided – all required information is within the Work Instruction itself. 6.6.4 Approval Requirements Circumstances when it may be necessary to submit the IHA for wider approval (i.e. NSCRG) include may include projects that have an especially large impact on safety, that are especially environmentally sensitive or that have a large impact on third parties. 6.7 Operational and Support Hazard Analysis (OSHA) 6.7.1 Objective The OSHA should lead to all procedures used in relation to the project being appropriately analysed. Data Requirements in Advance of the OSHA The following data should be available prior to conducting the OSHA: Engineering descriptions/diagrams of the proposed system Engineering descriptions/diagrams of the support equipment Draft procedures and operating manuals PHA, SHA, SSHA reports Personnel capabilities/competencies Proposed resource requirements Any relevant human factors engineering data and reports Details of any historical data containing information about collisions or mistakes that have

occurred due to human error (this data may be available from projects that are similar and are currently in operation)


IAN 139/11 of 266 Mar 11

6.7.2 The OSHA Process4 An OSHA examines the procedurally controlled aspects of the project system. Broadly, these include: System production and deployment (installation) procedures System testing (commissioning) procedures Equipment storage prior to installation Operation of the system Maintenance Training It may not always be appropriate for the OSHA to cover all of these areas, or to cover them in the same depth. It is to be expected that maintenance and operations will be the areas requiring the most detailed examination. Any such reasoning for excluding an issue from the OSHA should be made explicit in the report. An OSHA is based on the descriptions of the project system operational regimes and maintenance processes that are available at the time it is conducted. Considering Operations The operational processes which should be considered include the operational regimes and incident management processes that are to be used for the operation of the project system. Considering Maintenance This part of the OSHA can be conducted by considering a selection of the equipment which will be used in the project system. The selected equipment should provide coverage of all the issues relating to the project equipment and infrastructure. The rationale for selecting specific items could include: Equipment uniqueness, i.e. equipment with unique maintenance requirements Equipment access, i.e. equipment with restricted access (the restriction in this case may

be temporal, e.g. access to equipment may be restructured to prevent maintenance being carried out when the highway is in operation)

Maintenance location, i.e. equipment for which consideration must be given to the location of maintenance personnel, e.g. on the hard shoulder

Each item of equipment should be examined with respect to how it will be maintained, with the organisations involved in this maintenance considered, along with the associated interfaces and any required information flows between these organisations. A guideword approach can be used for the information flow (more information on application of guidewords is given later in this document). For the selected equipment items, a generic flowchart for the operational management of access and the actions of those with maintenance duties should be produced. Recommendations arising from the OSHA The OSHA is likely to produce a large number of recommendations, so it may be advisable to prioritise these using hazards and urgency ratings in order to make their implementation more manageable. The hazard rating could have a scale ranging from ‘low risk hazard’ to ‘high risk hazard’, and the urgency rating could have a scale ranging from ‘latest’ (e.g. the recommendation doesn’t need to be implemented until the project is decommissioned) to

4 Defence Standard 00-56, and Military Standard 882 provide detailed guidance on conducting an

OSHA


IAN 139/11 of 266 Mar 11

‘earliest’ (e.g. the recommendation must be carried out immediately). Recommendations can then be prioritised based on the combination of these two factors. In addition to grouping based on prioritisation, recommendations may also be grouped in a manner that facilitates the development of Task Plans and their subsequent implementation. These should be recorded and tracked in the hazard log. It is likely that questions will arise during the OSHA which cannot be answered immediately, and it may be the case that resolving these will produce more recommendations. These questions should be recorded and each assigned to a project member to investigate the answer and then, if necessary, formulate a recommendations. This process should be recorded and tracked in the Hazard Log. OSHA – The Impact on National Procedures for Type C The OSHA provides the opportunity to identify the following: Activities, which occur under hazardous conditions, their time periods, and the actions,

required to minimise risk during these activities/time periods Changes needed in functional or design requirements for system hardware/software,

facilities, tooling, or support/test equipment to eliminate or control hazards or reduce associated risks

Requirements for safety devices and equipment, including personnel safety equipment Warnings, cautions and special emergency procedures (e.g. egress or recovery) Requirements for packaging, handling, storage, transportation, maintenance and disposal

of hazardous materials Requirements for safety training and personnel certification Potentially hazardous system states under operator control The implementation of a Type C project may affect at least some, if not all of the above which could affect the Agency’s National Procedures. Before the project can be put into operation any effect on National Procedures will need to be identified and appropriate amendments made. The list below is an expanded version of the steps that are outlined in Work Instruction 004 in respect of undertaking an OSHA. 1. Carry out preparation for hazard analysis workshops No further guidance is provided – all required information is within the Work Instruction itself. 2. Review any existing analysis for applicability to the OSHA No further guidance is provided – all required information is within the Work Instruction itself. 3. Conduct Workshops Optional Methodology for Conducting an OSHA – The HAZOP Approach An OSHA may be conducted using a HAZOP (HAZard and OPerability study) approach. This approach uses a workshop to systematically examine each project procedure. To support the analysis it is recommended flowcharts describing the procedures to be examined are developed.


IAN 139/11 of 266 Mar 11

OSHA Guidewords Each step in the process flowcharts should be examined and it is useful to use guidewords in this process. Guidewords are a predefined list of words which aid the thought process by steering the workshop in a particular direction. They are words that describe a deviation from the design intent. A list of guidewords that may be used in an OSHA is given in the table below. At the start of the HAZOP process, the team should agree that the guidewords set are sufficient for the intended purpose, and on the interpretation of each guideword with respect to the project. If a guideword is not considered relevant to a step, it should not be included in the OSHA records. A guideword may also lead to several recommendations or questions, and this should be represented in the records. 4. Carry out an assessment of risk No further guidance is provided – all required information is within the Work Instruction itself. 5. Capture all the information in the Hazard Log No further guidance is provided – all required information is within the Work Instruction itself. 6. Documentation of OSHA results in the OSHA Report. No further guidance is provided – all required information is within the Work Instruction itself.

Guideword Meaning

No No part of the intended procedure step is carried out

Late Procedure step happens later than expected

Less Quantitative Decrease

More Quantitative Increase Part Of Qualitative Decrease As Well As Qualitative Increase Reverse Logical Opposite of the Intent Other Than Complete Substitution

A list of some commonly used guidewords and their meaning used in the OSHA


IAN 139/11 of 266 Mar 11

6.7.3 Deliverables The outcome of the OSHA and the process followed should be documented in an OSHA report. Table 6-3 provides detailed guidance for a typical report content. The boxes in grey are areas that are worth considering but may not be needed in some reports.

Section Reference OSHA Report Content Guidance 1. Introduction This section gives an introduction to the need for the OSHA, its objectives and scope, and

how the outputs will be used 1.1 Project

Overview Project Overview: The project overview should provide a brief background to the project, a description of the project’s design features and the reasons why the project is being considered for implementation. The overview may include the following subsections: Project Background: this includes details such as the location of the project (i.e. where the

project is to be implemented and the road/tunnel systems it applies to), the position of this particular project within the context of any wider project programme, the main phases in which the work will be undertaken (e.g. the order in which different stretches of road will be affected and different operational methods/technology will be introduced, as well as a description of the planned project phases and a list of the project team members who will be responsible for delivering each of the planned phases)

Design Features: this refers to the design features and design principles which the work will adopt. This will include a description of the equipment used (carriageway and associated infrastructure lighting, barriers, markings, drainage, etc.], technology based equipment), the personnel involved in operations and maintenance, and the procedures by which they work

The need for the project: e.g. alleviating congestion and the associated problems (such as widely varying journey times, the effects and costs to businesses based in the area, issues of safety)

1.2 OSHA Objectives

A brief statement is required on the objectives of the OSHA, e.g. “to confirm that, within the scope of the OSHA, all equipment associated with the project has been reviewed to check that the required operation and maintenance procedures exist and the relevant aspects of all procedures that will be used by this project have been analysed”

1.3 OSHA Scope Scope needs to define the particular project design features to be analysed, and the associated operational related issues studied by the OSHA

1.4 Outputs from the OSHA

An indication should be given of how the outputs will be implemented e.g. how they will feed into the hazard log, the operational safety requirements report, the operational plan, operational procedures, maintenance requirements, maintenance plan, safety and maintenance procedures, etc

1.5 Structure of the OSHA

The structure of the report should be outlined, including any techniques used to determine the structure, such as Goal Structured Notation. An overview of the safety argument should be given

1.6. Overview of the Safety Lifecycle

The principal safety activities that will be undertaken throughout the project lifecycle should be shown. A figure is a helpful way of achieving this. An indication of which activities have been carried out thus far, and how the OSHA outputs will feed into other work An indication should also be given of the other types of hazard analyses that are being undertaken for the project, e.g. PHA, SHA, etc., and where the OSHA fits into this. There should be an indication of the scope of the OSHA in relation to the other hazard analyses, i.e. the two areas it is principally concerned with are operation and maintenance

2. OSHA Methodology

This section gives an outline of the methodology used in the OSHA

2.1 Activities carried out

The main points regarding the methodology should be summarised, e.g.: When the OSHA was conducted How the workshop team was chosen, the names and roles of those included, and which

workshop meetings each attended The method used to represent the process, e.g. the analysis could be based on a series

of process flowcharts, each of which models either the maintenance or the operation process

How the results of the OSHA were recorded How the maintenance processes were considered, including which items of project

equipment were selected for detailed study of their maintenance, the criteria by which these were chosen, and how maintenance was reviewed. There should also be a note on how different organisation involved in maintenance and associated interfaces were considered, and how any required information flows between these organisations were examined

How the operational processes were considered, including a list of all the operational regimes and management processes that were examined in the OSHA


IAN 139/11 of 266 Mar 11

Section Reference OSHA Report Content Guidance 2.2 Approach to

analysing the results

If the recommendations rising from the OSHA were prioritised, such as by using a combination of hazard and urgency ratings, the methodology for this should be explained

3. Main Findings This section summarises the key findings from the OSHA and provides a high-level breakdown of the recommendations into categories such as priorities for action

3.1 Summary of Key Findings

This should produce a high-level summary of the key findings, such as the number of recommendations produced, a broad overview of the topics these mainly relate to, the main areas for further work and the number of questions raised during the analysis

3.2 Priorities of Recommendations

The results of the prioritisation of recommendations should be given, e.g. the number of recommendations within each priority bracket. Some brief discussion may be added to indicate which issues have resulted in high-priority recommendations, etc

3.3 Grouping of Recommendations

If there are numerous recommendations, it is likely that these will have to be grouped in order to develop the Task Plans to address the recommendations and their implementation. Any such categories should be listed, with an explanation of the rationale behind the groupings given, and any categories of priority highlighted. A table may be used to represent this information, with the name of the group, the name of the subgroup, a description of the grouping, and the number of recommendations assigned to that group

4. Issues for further analysis

This section outlines any parts of the analysis that need further work

4.1 Future risk assessment activities

This section should outline any future risk assessment activities that are to occur with a rough estimate of the timescale involved

4.2 Other Issues to analyse

Any other issues to analyse that have not been mentioned previously should be outlined

5. Conclusions This section should provide details of the work which will be conducted using the outputs of the OSHA, including the formulation of Task Plans for addressing the recommendations, and the way in which this will be carried out and progress tracked

Table 6-3 Guidance on the Content of an OSHA Report The output of the OSHA should result in a list of recommendations. These should be tracked in the hazard log and task plans developed in order to address them. Recording the Results If the OSHA has been conducted using the HAZOP approach described above it can be useful to record the results of the OSHA in a tabular format. This is a simple way of clearly demonstrating how the application of guidewords lead to the identification of fault conditions and associated hazards. It is also useful to record mitigations and additional comments. An example of this method of capturing the information is shown below in Table 6-3.


IAN 139/11 of 266 Mar 11

Item no.

Procedure Step Guideword Interpretation Cause of Hazard Consequence/ Implication

Hazard Mitigation Question/ Recommendations

1 Maintainer informs operator when equipment will be taken out of service

No Maintainer does not inform operator before taking equipment out of service

Maintainer unaware of need, forgets, or does not think it is important to inform the operator

When an incident occurs, the operator is unable to use signals and signs to protect it, as they are no longer available

Refer to ‘system failure’ items in hazard log

Operator is likely to realise that the COBS is under maintenance as there will have been fault alarms

Ensure appropriate procedures are in place for maintainers to gain access to the project highway

Table 6-3 Example of Recording Results for an OSHA Conducted as a HAZOP


IAN 139/11 of 266 Mar 11

6.7.4 Approval Requirements Circumstances when it may be necessary to submit the OSHA for wider approval (i.e. NSCRG) may include projects that have an especially large impact on safety, that are especially environmentally sensitive or that have a large impact on third parties. 6.7.5 Additional Activities No further guidance is provided – all required information is within the Work Instruction itself. 6.7.6 Additional Guidance Differences between PHA, SHA and SSHA The diagram below helps to distinguish the difference between the Preliminary, System and Sub-system Hazard Analysis activities:

HazardEvent Event

Accident

PHA

SHA

Environment

SSHA

System

Sub-systemHazardEvent

Change to System

HazardEvent Event

Accident

PHA

SHA

Environment

SSHA

System

Sub-systemHazardEvent

Change to System

Figure 6-1 Differences Between Hazard Analysis Activities

As shown in Figure 6-1 the PHA is a preliminary examination of the whole project. The PHA is the first type of hazard analysis activity that is carried out. It identifies as many of the hazards as possible that can affect the project, through consideration of the main functions and operations that the project will provide i.e. the general suite of hazards that occur when the Project operates in its proposed environment. Figure 6-1 also shows that the SHA examines internal aspects of a project. The SHA is a more detailed assessment of the project. It considers all of the events that could occur within the project that may lead to a hazard. As shown in Figure 6-1, the SSHA is a further level of detail down from the SHA. The SSHA examines detailed internal aspects of design. It includes analysis of the project sub-systems


IAN 139/11 of 266 Mar 11

and identifies each of the events that could occur within the sub-systems that may lead to a hazard.


IAN 139/11 of 266 Mar 11

7 THE HAZARD LOG

7.1 Objective As the project design develops the project develops hazard mitigations. These mitigations and their evolution are tracked in the Hazard Log. 7.2 Hazard Log Requirements The successful management of hazards involves the use of a Hazard Log for collecting, organising and maintaining the safety-related information that a project accumulates, possibly over many years. A Hazard Log should have the capability to store and manage the safety related information for a project in an organised and accessible way. The Hazard Log contributes significantly to the project safety report as it contains documentary evidence on the management of all hazards (what hazards are present and the mitigations taken to minimise them) thus providing traceability of the project design safety process. Work Instruction 004 describes the type of information associated with each hazard which is to be recorded within the Hazard Log. In addition, the list below describes some useful features which can be provided by a Hazard Log database tool: The ability to enter hazards into the tool and have the potential to link this other

information (e.g. collisions and causes) The ability to associate any amount of supporting information and documentation with a

hazard entry The ability to maintain a chronological list of the data entries including design resolutions

which may mitigate the risks associated with the identified hazards A facility to manage version control to track any changes that occur in the log The ability to enter tasks with direct links to the associated hazards, so that progress

towards mitigating each hazard can be tracked to completion The ability to record and trace actions to be undertaken in the future towards mitigating

hazards and assign owners to these actions. It is also useful to be able to record any further questions or investigations that need to be answered and/or carried out towards resolving hazards

The ability to enter the safety requirements associated with each hazard and to be able to assign them to any number of hazards or tasks

The ability to manage the process of planning the verification activities and collecting the verification evidence associated with each hazard to be able to assign them to any number of hazards or tasks

A versioning system, which ensures that a full history of all changes to the content of each hazard, task, safety requirement entry etc is recorded, along with the dates and authors of those responsible for making the change

The ability to assign safety requirements and tasks to particular ‘owners’ The ability to compile any aspect of the data to generate reports (see ‘Hazard Log

Reports’ later in this section) The Hazard Log should show clearly the hierarchy of incidents, hazards and hazard causes and how they are linked to each other. Hazard Log Programmes to Use Prior to choosing the most suitable software programme for a Project Hazard Log, it is recommended that the project clearly defines the “must have” and “nice to have” programme features. Once these features have been defined it will be possible to map the requirements


IAN 139/11 of 266 Mar 11

to those of proposed software programmes. An evaluation of individual software programmes can then be made. For Managed Motorways a hazard log application has been developed by Highways Agency NetServ which can be used for both Type B and Type C projects. The NetServ hazard log is a multi-user intranet application. The application consists of a database (Microsoft SQL Server 2005 Express) and a web server (Apache Tomcat) component. Both components are installed on a target machine using a single installer executable file and configured automatically. Once installed, hazard log access is provided by a web browser. For more information or to download the hazard log contact NetServ on the following email address:

[email protected]

Hazard Log Maintenance The Hazard Log should be established at an early stage in the project lifecycle and be maintained thereafter as a ‘live’ document to reflect any changes in the project design. The Hazard Log is the principal means of recording the progress on resolving the risks associated with the established hazards. It should also be maintained when the project is fully implemented and is operating. Any additional hazards encountered during operation are to be documented. In this way a full traceable record of the hazard management process and the way in which safety issues are being dealt with is maintained. In summary, the Hazard Log should be updated whenever: A new hazard or potential collision is identified A relevant incident occurs Further information relating to existing collisions, hazards or causes comes to light Any project safety documentation is created or re-issued, for example the Safety Report Hazard Log Accessibility The Hazard Log should be made accessible to all project members who require it. A possible way of doing this is to provide a web-based application that can be accessed over the internet. Authorised users can be provided with a username and password and will require no further specialist software to interface to the Hazard Log. This will also enable efficient navigation around the database content. Those who need access to the hazard log should be categorised into different types of users who are given different access rights. Users may be categorised as in Table 7-1 below.


IAN 139/11 of 266 Mar 11

Type of Hazard Log User Function of User Administrator Manager Editor Reader Read only – all hazards, risk assessment, task plans, attachments etc

X X X X

Hazard log maintenance and updating

X

Upkeep and configuration control of hazard log

X X

Editor of hazards and causes X X X Adding hazards X X Closing hazards X X Editing hazard notes X X X Editing attached documents X X X Editing tasks X X X Add or remove users/edit user rights

X

Table 7-1 Roles of Hazard Log Users

Hazard Log Security Adequate provision must be made for the security of the Hazard Log. A useful reference is ISO 17799, "Information Technology - Code of practice for information security management”. This is a standard which explains how to implement an information security management system (ISMS), the structure it should align to and the controls which should be adhered to. This should be taken into consideration when the Hazard Log for a project is being designed. Hazard Log Ownership and the Ownership of Hazards The Hazard Log is updated throughout the lifecycle of the project. During project design it is owned and maintained by the project safety team. On commencement of operation, responsibility of the Hazard Log is transferred along with ownership of the project to operations. Each action should have someone who is responsible for it. This person will give the deadline and monitor the process of the action. The process can be maintained in the hazard log. 7.3 Deliverables The Hazard Log will not normally be delivered in documentary form. However, at any stage of the project, the project must be able to provide a snapshot of the Hazard Log. Hazard Log Reports The PCF product page for the MM Hazard Log and Hazard Log Report is available at: http://portal/portal/server.pt?open=space&name=CommunityPage&id=2&cached=true&in_hi_userid=17086&control=SetCommunity&PageID=0&CommunityID=914&WG_link=http://portalweb/minisite/hawww/www/MP/PCF_Mockup_2/Product_Groups/New_Groups/../../Products/Hazard_Log.html 7.4 Approval Requirements No further guidance is provided – all required information is within the Work Instruction itself.


IAN 139/11 of 266 Mar 11


8.1 Objective The difference between verification and validation is that verification determines whether the project meets all of the safety requirements as defined in the project specifications, whereas validation determines whether the project satisfies its original intended purpose once operation has commenced. 8.2 Verification and Validation Requirements The main elements of a typical verification process are illustrated in the V-Lifecycle of Figure 8-1 below. Not all projects will include all the steps shown in this figure.

Implementation

Sub-system Design

Sub-system Test

Project Design

Project IntegrationTest

Requirements Specification

System IntegrationTest

Project High-level Requirements Analysis

Verify Requirements

Testing

Testing

Testing

Testing

High Level Requirements High Level Requirements

Low Level Requirements Low Level Requirements

Checks requirements match specification

Checks requirements are implemented

Implementation

Sub-system Design

Sub-system Test

Sub-system Design

Sub-system Test

Project Design


Project Design






Project High-level Requirements Analysis

Verify RequirementsProject High-level Requirements Analysis

Verify Requirements

Testing

Testing

Testing

Testing

High Level Requirements High Level Requirements

Low Level Requirements Low Level Requirements

Checks requirements match specification

Checks requirements are implemented

Figure 8-1 The V-Life Cycle

The left branch of the ‘V’ shows the successive development of safety requirements from the projects high-level requirements down to the low level requirements. The right branch of the ‘V’ shows the successive testing activities required in order to verify the design. Each of the process steps are described briefly below. Project High-level Requirements Analysis and Requirements Specification The V-life cycle begins with the definition of the high level requirements for the project. At this stage it will be possible to specify the demonstration and acceptance criteria for the high level safety requirement for the system. Project Design and Sub-system Design The objectives of these stages are to create an overall project design and subsequent sub-system designs that conform to the safety requirements that have been specified. The aim of the verification activities is to demonstrate that the design matches the specified requirements. Sub-system, Project Integration and System integration Test The objectives of these stages are to test the sub-systems, project as a whole and the entire system to check that the specified requirements have been implemented. The V lifecycles makes clear that the activities of verification are linked to those of design and development, i.e. what is designed must be checked with regards to the relevant requirements.


IAN 139/11 of 266 Mar 11

It is important to note that the verification and validation activities should not only consider the physical design aspects but should also consider procedural and operational aspects too. It is possible to envisage a further V-lifecycle which covers these aspects. 8.3 Deliverables Verification Plan It is possible to have several different plans, each covering the verification processes for the different areas for the project, although one plan covering all of these areas is the most common. For example separate plans may be required for a project where large amounts of verification activity are required in different areas such as: Technology Infrastructure Operations Each of the verification requirements outlined in the Verification Plan should be given some sort of reference number so that they can be traced easily through to completion (this will also correlate with the verification reference given within the Hazard Log). Verification Report Because the Verification Report follows on from the Verification Plan, separate Verification Reports may also be required The tables below show how a verification requirement described within the plan will progress through into the Verification Report.

Reference Safety Requirement Verification Method VR0001 Operators should use PTZ cameras to

confirm the location of an incident Monitoring procedure to be reviewed and approved

Table 8-1 Example of a Verification Plan Entry

Reference Safety Requirement Verification Method Results Status VR0001 Operators should use

PTZ cameras to confirm the location of an incident

Monitoring procedure to be reviewed and approved

Present in monitoring procedure. Procedure has been approved

Closed

Table 8-2 Example of a Verification Report Entry

It may also be useful to record the status of the following: Each of the verification activities The closure of completed tasks Tasks that remain open or have failed to pass the verification process Validation Plan No further guidance is provided – all required information is within the Work Instruction itself. Validation Report No further guidance is provided – all required information is within the Work Instruction itself. 8.4 Approval Requirements Circumstances when it may be necessary to submit the Verification and Validation Plans and Reports for wider approval (i.e NSCRG) may include projects that have an especially large


IAN 139/11 of 266 Mar 11

impact on safety, that are especially environmentally sensitive or that have a large impact on third parties. 8.5 Additional Guidance

Methods of Verification There are four types of verification that can be applied: Inspection - Typical techniques include desk checking, walkthroughs, software reviews,

technical reviews, and formal inspections Analysis - Mathematical verification of the test item, which can include estimation of

execution times and estimation of system resources Testing - Given input values are traced through the test item to assure that they generate

the expected output values, with the expected intermediate values along the way Demonstration - Given input values are entered, and the resulting output values are

compared against the expected output values Methods of Validation In general, for the validation of a scheme it is useful to consider the following questions: Is the system fit for purpose? E.g. has the traffic flow been reduced as intended? Have

the number of collisions been reduced? Has the safety objective been reached? Have the global safety objectives been satisfied? Validation is generally about monitoring the system during operation to see if the desired results have been attained.


IAN 139/11 of 266 Mar 11

9 PRODUCTION OF A SAFETY REPORT

9.1 Objective No further guidance is provided – all required information is within the Work Instruction itself. 9.2 Requirements

Safety Report Versions A number of versions of the Safety Report can be expected throughout a project. The production of several versions of the Safety Report is one way of reducing the risk to the overall project success. Rather than waiting until close to the end of the project and obtaining approval for everything then, approval is sought for successive elements. Typically, the versions below will be required for projects using a Type C SMS: Design. This version will be produced once the design is complete. The primary

purpose of the ‘Design’ version of the Safety Report is to show that the design is capable of achieving the project safety objectives. It includes summaries of the safety evidence that is available at the time as well as indicating where evidence that will be available in the future will be documented. It also highlights any design issues that have not yet been resolved

As-built. An updated version of the Safety Report is produced when construction and installation of the project is complete. This version of the Safety Report is produced in order to allow operation to commence. It shows that the project system has been designed, constructed, installed and commissioned correctly and that suitable procedures are in place for operation and maintenance. This version also highlights any issues that have not been fully resolved and that require monitoring while the project is in operation. For any open issues, the report needs to justify why operation can commence with them still unresolved. Safety Acceptance and Approval of the As-built Safety Report is required prior to commencement of operation

Interim. This version is produced after an initial period of operation and it is therefore generally a Network Delivery and Development responsibility to make sure it is provided. It provides an opportunity for initial validation of any assumptions made in the course of the safety work and to monitor the risk levels associated with the project and to compare them to the safety objectives

Final. This version is produced after significant operating experience has been gained. Typically this experience would be of the order of a year. Although this Safety Report is titled final, future versions of the Safety Report will be needed if:

– An additional hazard is identified that needs mitigation – Changes are made to the project to which the Safety Report relates

This version of the Safety Report concludes on the achievement of the project safety objectives and makes any necessary recommendations that are needed to maintain this level of safety

The exact number of Safety Report versions needed is again a project specific consideration. The diagram below shows how the four versions of the Safety Report described earlier in this section fit into both the project and safety lifecycles.

Interim Advice Note 139/11

Guidance for Work Instructions 004: Managed Motorways

Safety Risk Mangement for Projects with Type C Features Safety Risk Working Instructions

IAN 139/11 of 266 Mar 11

Define project scope & outline design

Construction

Operate & maintain

Define safety acceptance and approvals process

Define safety baseline & objectives

Develop safety strategy and plan

Verification

Operate & monitor

Validation

Decommission Update project safety documentation

Consider any changes in project design and new safety requirements; incorporate into

SMS activities

Project Lifecycle Safety Lifecycle

Design information& safety

requirements

Hazard identification & risk assessment

Hazard log production

Design Project safety report

As-built Safety Report


Safety Reports

Design Safety Report


Interim Safety Report


Preliminary Design Safety

Report


Report

Final Safety Report

Final Safety Report

Define project scope & outline design

Construction

Operate & maintain

Define safety acceptance and approvals process

Define safety baseline & objectives

Develop safety strategy and plan

Verification

Operate & monitor

Validation

Decommission Update project safety documentation

Consider any changes in project design and new safety requirements; incorporate into

SMS activities

Project Lifecycle Safety Lifecycle

Design information& safety

requirements

Hazard identification & risk assessment

Hazard log production

Design Project safety report



Safety Reports






Report


Report

Final Safety Report

Final Safety Report

Figure 9-1 How the safety report versions fit into the project life cycle




IAN 139/11 of 266 Mar 11

Safety Report Maintenance An important aspect of Safety Report management is the ongoing maintenance of the safety justification throughout the project lifecycle. Throughout the operational life of any system, changing regulatory requirements, additional safety evidence and a changing design can challenge the corresponding Safety Report. In order to maintain an accurate account of the safety of the system, all such challenges must be assessed for their impact on the original safety justification as documented in the safety report. To be able to maintain the safety report effectively a systematic and methodical approach by which to examine the impact of changes is required. The size and complexity of these changes being presented within Type C Safety Reports can be very large. To support any changes, it is particularly important that the Safety Report supports clear identification of safety issues that will ultimately be managed by different parts of the managing organisation once operation commences. This is to ensure that different parts of the organisation have a clear understanding of the main safety risks associated with, and controlled by, those parts of the project for which they are taking responsibility. Goal Structured Notation Using GSN in a Safety Report Goal Structured Notation (GSN) is a graphical argumentation notation. It is used to represent each element of a safety report and the relationships between each element. Use of GSN also enables a systematic approach to be taken when assessing the impact of changes to the Safety Report. The GSN for a Safety Report consists of four elements: Requirements – the overall safety objectives that must be addressed in order to

demonstrate project safety. In the GSN, these form high-level goals/claims Evidence/solutions – information from the examination and test of the system Strategy/Argument – how the evidence indicates compliance with the goals. In the GSN,

the strategy/argument is expressed through the structuring of goals supported by sub-goals

Contextual information – the background on which the argument is based. In the GSN, this can be represented as Context, Assumptions, Justification and Models

Typically, the following symbols are used to represent the different elements of a safety report:

Goal or sub-goal Evidence Strategy ContextGoal or sub-goal Evidence Strategy Context

Figure 9-2 Symbols Representing Elements of a Safety Report in GSN

A goal structured network is typically formulated towards the end of the safety lifecycle work on production of the first version of a Safety Report in order to demonstrate what activities have taken place and to make explicit the rationale behind the support of the Safety Report. It may however be useful to formulate the GSN at the earlier stages of the project safety lifecycle as it can be used to plan the safety work that will be undertaken, and ensure that the safety report will be supported by strong lines of evidence and a robust rationale from the start.




IAN 139/11 of 266 Mar 11

At the intermediate stages of the safety lifecycle, the network can be updated and circulated to keep stakeholders informed of progress and to inform any safety-related discussions. The symbols used in the network may be shaded to demonstrate whether or not each goal has been met at the time the particular version of the network was issued. An example of this is shown below in Figure 9-3:

Goal

Goal

Goal

Goal substantially met at time of issue

Goal partially met or required activity is on-going

Goat not yet met – depends on future activities

Goal

Goal

Goal



Goat not yet met – depends on future activities

Figure 9-3 Shade Coded Symbols as Part of the GSN

Developing a GSN Network When developing a GSN network, begin with the top-level goal. This should be a broad statement, e.g. “The project scheme is acceptably safe”. The second stage is to break this question down into the component strategies which show how the top-level goal will be/has been achieved. Typical examples would include “Demonstrate that safety objective has been agreed and is likely to be achieved”, “Demonstrate that project meets safety objectives”, “Demonstrate that appropriate methods and processes will be followed during the project” and “Demonstrate good management of hazards”. The third stage is to define the sub-goals which relate to these strategies. For example, for the strategy “Demonstrate good management of hazards”, a sub-goal could be “A hazard log is produced”. The sub-goals should be broken down until they reach a level where they can be directly related to evidence. “Evidence” refers to pieces of work, e.g. documents produced. For example, for the sub-goal “A Hazard Log is produced”, the evidence can be stated simply as “Hazard Log”. Other sub-goals may need to be broken down through further levels of sub-goals, and perhaps also strategies, before the evidence level is reached. The same piece of evidence may support more than one sub-goal, in which case this should be demonstrated by arrows. Alternatively, the symbol naming that piece of evidence may be repeated if this makes the layout simpler and avoids too many crossing arrows. For some sub-goals, it may not be appropriate to break it down to the evidence level, but rather end with a strategy. An example is the sub-goal of “Good practice is followed through project execution”, which may be difficult to break down into evidence when the project is still at the planning stage. In such cases, it may be appropriate to break this down into strategies, e.g. “Good practice followed during design and implementation” and “Project wide systems followed”.




IAN 139/11 of 266 Mar 11

It is thus clear that different branches of the network will differ in the number and nature of their levels. It is useful to provide a cross-reference to the relevant section of the Safety Report document for each goal, sub-goal and strategy. For a more detailed explanation of GSN, see Section C1 in the Appendix section of the guidance document. Safety Report versus Safety Case For all Agency projects the term Safety Report is used to refer to the document that is produced at the end of the safety lifecycle summarising the evidence showing that the safety objective has been achieved. In a number of other industry sectors the term Safety Case is used. Why is the term Safety Report being used for HA Projects? The term Safety Case has a legal definition in particular industries. It is generally a large document or will reference a substantial number of other documents that together provide a full record of the risk assessment and associated mitigations undertaken in association with a given project. In almost all cases, the degree of risk control that the Safety Case is addressing is significant. For some HA projects it may only be a brief document e.g. where a project relates to a change that requires a limited degree of risk control. It would be inappropriate to call such a document a Safety Case, owing to the widely recognised definition of what a Safety Case should contain. By adopting the term Safety Report flexibility is available in the content of the document and confusion with the existing term is avoided. In some cases e.g. for those projects that are providing a substantial level of risk control a project Safety Report may be equivalent to a Safety Case. 9.3 Deliverables Table 9-1 below provides more detailed guidance as to the content of a typical safety report.

Section Reference Safety Report Content Guidance 1. Introduction 1. Project

Overview Project Overview: The project overview should provide a brief background to the project, a description of the project’s design features and the reasons why the project is being considered for implementation. The overview may include the following subsections: Project Background: this includes details such as the location of the project (i.e. where

the project is to be implemented and the road/tunnel systems it applies to), the position of this particular project within the context of any wider project programme, the main phases in which the work will be undertaken (e.g. the order in which different stretches of road will be affected and different operational methods/technology will be introduced, as well as a description of the planned project phases and a list of the project team members who will be responsible for delivering each of the planned phases)

Design Features: this refers to the design features and design principles which the work will adopt. This will include a description of the equipment used (carriageway and associated infrastructure lighting, barriers, markings, drainage, etc.], technology based equipment), the personnel involved in operations and maintenance, and the procedures by which they work

The need for the project under consideration: e.g. alleviating congestion and the associated problems (such as widely varying journey times, the effects and costs to businesses based in the area, issues of safety)




IAN 139/11 of 266 Mar 11

Section Reference Safety Report Content Guidance 1.2 Purpose This section needs to include a clear definition of the purpose of the safety report. This

could be in the form of statement such as “the purpose of the Safety Report is to demonstrate that the project scheme is (or is not) capable of being acceptably safe provided that the necessary safety requirements are fulfilled”. A definition of terms such as “acceptably safe” should also be given. Further detail provided will depend on the type of Safety Report in question. For instance, for a Design Safety Report, it might be noted that the Report provides an indication of the structure which will be used by the subsequent Safety Reports that will be required as the scheme develops further, with summaries of the safety evidence that has been produced and placeholders for evidence that is expected to be available in the future. A brief indication of the limitations of the particular version of the Safety Report may also be given, e.g. the Design Safety Report is limited to identifying issues and hazards that are present in the proposed design and the safety requirements that need to be present to mitigate those hazards

1.3 Scope The scope of the Report should be clearly defined, including the spatial area (e.g. Junctions X to Y of Motorway Z), as well as the associated infrastructure, technology, personnel and work procedures

1.4 Changes since last issue

If this is not the first version of the Safety Report, a table may be produced briefly listing the changes made to each section, e.g. updates to the project design

1.6 Document Structure

This section will include information about the structure of the document. The structure of the report should be outlined, including any techniques used to determine the structure, such as Goal Structured Notation. An overview of the safety objectives should be given

2. Safety Objective

2.1 Safety Baseline 2.2 Safety

Objective Demonstration

2.3 Safety Objective Achievement

For each of the sub-sections, the following should be provided: A summary of the work carried out thus far for that sub-section and its conclusions

e.g. for the “Safety Objective Demonstration” sub-section, the safety objective should be described and the basis of this explained (e.g. the GALE Principle, the ALARP Principle, etc.)

A statement on whether or not the work for the sub-section has been approved (if relevant), e.g. “The adoption of the GALE principle as the Safety Objective for the project system was approved by the Highways Agency through the approval of the Safety Strategy”

References should be provided to the documents produced in relation to the relevant activities, which the reader can access for more information

The majority of this information will have been document in the Safety Baseline and Objectives Report

3. Safety Management Process

This section provides assurance that the safety management process is robust. If GSN has been used, presenting the relevant part of the diagram at the start of the section may be useful. For all steps, the documents produced in relation to the relevant activities should be referenced. The safety management process proposed should be available from the Safety Plan

3.1 Competent People Chosen

An overview of the safety organisation should be given, perhaps with a diagram. The key safety roles should be summarised, along with an outline of the experience of the people in each of these roles

3.2 Safety Management Process

It should be stated that the project has adopted a comprehensive and robust safety management process, based on current international best practice for managing project safety, with reference to the key standards used, e.g. IEC 61508. The key elements of the project safety management process should be outlined, including the main documents (e.g. Safety Strategy), activities (e.g. hazard assessment activities), relevant project committees, etc

3.3 Approval Process

The steps in the approval process for the safety report should be described, perhaps in diagrammatic form. The relevant roles and responsibilities should be outlined. This process will have been outlined in the Safety Plan

3.4 Safety Challenges

A table of these safety challenges should be provided, with a description of how they have been addressed. These may have documented in the Safety Plan

3.5 Safety Performance

The manner in which the monitoring requirements for the project have been gleaned should be made clear. For instance, it could be the case that, throughout the hazard analysis process, any assumptions that could affect the safety argument and need to be verified by operational experience have been recorded. The monitoring requirements could then be formulated in order to verify these assumptions. The monitoring plans should be briefly explained. The results of any monitoring that has taken place thus far should be summarised. It should also be stated how any detected variation from expected behaviour or performance has been/will be dealt with, in broad terms




IAN 139/11 of 266 Mar 11

Section Reference Safety Report Content Guidance 3.6 Maintenance of

the Safety Report

It should be briefly explained how the safety report will be maintained, e.g. through updates and the issuing of new versions

4. Management of the Hazards

This chapter should provide assurance that the hazards have been adequately managed

4.1 Use of the Hazard Log

The structure of the Hazard Log for management of hazards associated with the project should be described, including any features specific to the project

4.2 Identification of Hazards

This sub-section should provide evidence that hazard identification has been rigorous and extensive, including: Details of the different hazard identification techniques that have been used

throughout the project, such as workshops, HAZOP (Hazard and Operability) studies, desktop studies and review meetings

A summary of the risk assessment carried out for each hazard, e.g. a summary of the hazard classification system and the methodology used to assess risk for each hazard

The process used for identifying hazard mitigations Details of the review(s) of the hazard analysis Details of the hazard analysis activities should have been provided in the Safety Plan

5. Management of Safety Related Tasks

Detail should be provided of the task management mechanism, i.e. the hazard log. To avoid duplication with 4.1, this section should provide details on the process followed when a task is entered into the log, e.g. it moves through a number of stages, from initial entry of the task through to assignment of a task owner, entry of a task plan, approval of a task plan, monitoring of task progress, marking of a task as complete and, finally, formal verification and validation of task close-out. There should also be comments on how an individual can use the hazard log to see what tasks have been assigned to him/her. The current state of tasks in the hazard log should be made clear (e.g. the number of tasks and their status with regards to approval and completion)

5.1 Further risk assessment activities

This section documents any further risk assessment activities that are to be carried out later in the project lifecycle

5.2 Other issues to analyse

This section should highlight any other issues that are relevant to the project that need to be analysed, that have not been recorded in the document previously

6. Safety Requirements and Restrictions

The purpose of this section is to show that safety requirements and restrictions have been identified and that these are traceable to hazards. It should include definitions of ‘requirements’ and ‘restrictions’ and details of how these have been recorded, e.g. in the hazard log The process each safety requirement goes through should briefly summarised, e.g. methods for identifying safety requirements, their entry into the hazard log, the assignment of hazards to the requirement which is intended to mitigate them, designation of an owner for each requirement, designation of each requirement as either mandatory or optional, acceptance of the requirement by the work stream, entry of a verification plan for the requirement, review of the verification plan, recording of the verification process and review of the verification evidence This should provide details of the status of the requirements and restrictions identified so far, with respect to the acceptance of each, the approval of their verification plans, and the closure of verified safety requirements (if appropriate)

7. Methods and Processes

To show that appropriate methods and processes have been followed during project execution, this section shows that: The design is compatible with standards and regulations Good practice has been followed during project execution

7.1 Compatibility of design with standards and legislation

This should include a summary of which standards have been followed, and any departures from standard, in order to show that the project teams have complied with these standards wherever possible and sought to obtain departures from standard when necessary

7.2 Following good practice

This sub-section should show that good practice has been followed in those cases where standards are not applicable. Examples of project-wide good practice should be given, e.g. regular reporting to the Highways Agency, quality systems in place, etc

8. Conclusion This section should summarise why, at this stage of the project, the argument that the project is acceptably safe is supported. It may include a statement such as “The conclusion of this version of the safety report is that an appropriate safety argument has been constructed and that, subject to resolution of the outstanding issues, achievement of the overall goal has been demonstrated.” The outstanding issues should then be summarised. If the safety report in question is the final version, there will be no outstanding issues

Table 9-1 Example Content of a Safety Report




IAN 139/11 of 266 Mar 11

The PCF product page for the MM Safety Report is available at: http://portal/portal/server.pt?open=space&name=CommunityPage&id=2&cached=true&in_hi_userid=17086&control=SetCommunity&PageID=0&CommunityID=914&WG_link=http://portalweb/minisite/hawww/www/MP/PCF_Mockup_2/Product_Groups/New_Groups/../../Products/Safety_Report.html 9.4 Approval Requirements The Safety Report will require internal approval (by the PSCRG) followed by external approval (by NSCRG. Approval should occur for each version of the document. For example, approval of the Design Safety Report does not negate the need for approval of the Final Safety Report.




IAN 139/11 of 266 Mar 11

10 UPDATING SAFETY DOCUMENTATION DURING OPERATION

10.1 Objective No further guidance is provided – all required information is within the Work Instruction itself. 10.2 Requirements Other documents that may require updating include: The Hazard Analyses (e.g. PHA, SHA, SSHA, OSHA, IHA) The Verification and Validation Plans and Reports 10.3 Deliverables No further guidance is provided – all required information is within the Work Instruction itself. 10.4 Approval Requirements No further guidance is provided – all required information is within the Work Instruction itself.




IAN 139/11 of 266 Mar 11

11 SAFETY ACCEPTANCE AND APPROVAL PROCESS There are lots of deliverables from the application of WI 004. Only key ones need to go to NSCRG (Safety Plan, Hazard Log and Hazard Log Report and Safety Report). Others (Hazard Analysis Report, Verification Plan and Reports) can be approved by PSCRG. The following table provides a summary of the approval required for the deliverables produced during the application of WI 004.

Deliverable NSCRG Approval Required PSCRG Approval Required Safety Report

(prior to external approval) Safety Baseline and objectives Report

(prior to external approval)

PHA Report (NSCRG approval may only be

needed in exceptional circumstances)

SHA Report (NSCRG approval may only be


SSHA Report (NSCRG approval may only be


IHA Report (NSCRG approval may only be


OSHA Report (NSCRG approval may only be


Verification and Validation Plans and Reports

(NSCRG approval may only be


Table 11-1 – Summary of the approval process for the deliverables fom Work Instruction 004 application


Guidance for Work Instructions 001-004: Managed Motorways

Appendices Safety Risk Working Instructions

IAN 139/11 of 266 Mar 11

PART 9: APPENDICES TO GUIDANCE FOR WORK INSTRUCTIONS WI001, WI 003 & WI004

SUMMARY This document is the Appendix to the set of

Guidance Documents which support Work Instructions 001 – 004


AUTHOR/FURTHER INFORMATION NetServ/National Health and Safety Team LEAD DIRECTOR Board Director with responsibility for Health

and Safety APPLIES TO All Agency activities VERSION 1 STATUS (Final/Draft) FINAL THIS DOCUMENT REPLACES None – new document DISTRIBUTION Intranet REVIEW DUE DATE 2011





IAN 139/11 of 266 Mar 11

Contents APPENDIX A Risk Assessment Methodologies 195 A.1 Selecting a Risk Assessment Approach for each Type of SMS 195 A.2 Risk Assessment Techniques 195 A.3 Risk Assessment Methodology 1 – Semi-quantitative 196 A.4 Risk Assessment Methodology 2 – Quantitative 201 APPENDIX B Options Risk Assessment 205 B.1 Objective of Options Risk Assessment 205 B.2 Requirements 205 B.3 Deliverable 206 APPENDIX C Goal Structured Notation 207 C.1 An Introduction to GSN 207 C.2 How Does GSN Work? 207 C.3 Using GSN to Write a Safety Report – An Example 207 C.4 Summary of the Benefits of using GSN 210 APPENDIX D Development of a RACI Matrix 210 D.1 What is a RACI matrix? 210 D.2 How is a RACI matrix used? 211 D.3 Using a RACI matrix – An Example 211 D.4 The Need for a RACI matrix 212 APPENDIX E Derivation of Safety Integrity Levels 214 E.1 Definition of a Safety Integrity Level 214 E.2 Implications of SIL Selection 214 E.3 SILs and IEC 61508 214 E.4 Deriving a SIL 214 E.5 Factors to take into account when deriving a SIL 215 APPENDIX F COTS and SOUP 216 F.1 What are COTS and SOUP? 216 F.2 Safety management implications of COTS and SOUP 216 APPENDIX G Relevant Safety Standards 217

APPENDIX H: IAN 139/11 Managed Motorways Safety Risk Work Instructions in English DBFO schemes.




IAN 139/11 of 266 Mar 11

APPENDIX A. RISK ASSESSMENT METHODOLOGIES This section outlines some of the different risk assessment methodologies that can be used as a means of quantifying the risks associated with a particular project. In choosing or deriving a risk assessment methodology there are a number of requirements to take into account. Two of the most important are: The Type of SMS applicable to the project. A Type A SMS will not require the same level

of complexity in its risk assessment methodology as a Type C The Safety Objective selected. If the safety objective is expressed in quantitative terms

then the risk assessment methodology should allow risk to be expressed quantitatively A.1 Selecting a Risk Assessment Approach for each Type of SMS Guidance is given below as to the factors that are expected to be relevant to selecting a risk assessment approach for each Type of SMS. Type A. Risk assessment for Type A projects should generally be addressed through

the application of existing standards, good practice and established risk tools e.g. the Road Restraint Risk Assessment Process (RRRAP). Where a new risk assessment is required e.g. to support options selection, a qualitative or semi-quantitative approach should generally be sufficient. Quantitative risk assessment is unlikely to be either required or cost-effective for Type A projects

Type B. Where an appropriate analysis exists that is applicable to the project, it should be used as the basis for the project risk assessment and a similar approach followed for any additional risk assessment. Where a new analysis is needed, a semi-quantitative or quantitative approach is likely to be required

Type C. Consideration should be given to selecting the risk assessment approach that is outlined in section 0 of this appendix. This approach has been successfully deployed on a number of Type C projects and has been shown to work well. There is also a body of risk material which may then be drawn upon

A.2 Risk Assessment Techniques This section lists the majority of the most frequently used risk assessment techniques. The information given is intended to provide awareness that such techniques exist but not to teach their application. For this level of instruction please refer to other sources of information. Quantitative risk assessment. An assessment of risk through looking at the frequency

at which certain events occur in combination with the consequences that arise from those events. It involves an essentially numeric approach to evaluating risk which means that either data must be available to support numbers, or accurate estimation must be feasible

Semi-Quantitative risk assessment. Blends the approaches of quantitative risk assessment and qualitative risk assessment. Some degree of quantitative analysis will usually be carried out but will then be supplemented with more qualitative arguments. The final demonstration that a safety objective has been met will consist of the qualitative arguments supplemented by whatever quantitative information is available. The numerical assessment may need to cater for a range of possible scenarios. The qualitative arguments would then need to be used to establish which of these was most likely or which set represented the most likely outcome

Qualitative risk assessment. Risk is still assessed through considering event frequencies and the associated consequences, but a less numerical approach is used. Risk must still be quantified in some way, but coarser measures are used, and words may be assigned to the risk levels, such as major, medium or minor. In addition, arguments relating to areas such as assumptions used, likely outcomes and other less numerically based aspects are likely to be needed. Such approaches are of benefit when




IAN 139/11 of 266 Mar 11

there is limited data available to support quantification, when there is no requirement to know absolute risk levels only some measure of relative risks, or where an objective is also stated in a qualitative manner

HAZard and OPerability study (HAZOP). An activity that aims to identify hazards, their causes and consequences, through a methodical review of a system. A meeting is held with domain experts who between them can cover all aspects of the system. Each part of the system is reviewed in turn, considering both functional operation and interaction with human activity, and guidewords are used to stimulate identification of hazards. Example guidewords would the following: none, more of, less of, too early, too late

Fault Tree Analysis (FTA). A top down analysis approach, which begins with a high level event, such as a hazard or accident, and then breaks it down into lower level causes until the required level of detail is reached. Combinations of events are joined by logical ‘or’ or ‘and’ operators, helping to provide an understanding as to what the minimum set of events is that can lead to a hazard or accident

Event Tree Analysis (ETA). A bottom up analysis approach that begins with a base event and then explores the consequences of this event. It is particularly appropriate for determining the range of consequences that may arise from a hazard and the most likely of these consequences. Once the base event has occurred, each possible outcome is considered, and then these are further separated by considering the occurrence of additional events

Failure Modes and Effects Analysis (FMEA). This technique is also bottom up. Failure of a system element is considered and the consequences of this failure are examined until either a hazard occurs or it becomes clear that no hazard will occur. A system element in this context can be either equipment or a procedure step

A.3 Risk Assessment Methodology 1 – Semi-quantitative This risk assessment methodology has been used previously on Type C SMS projects. This methodology allows a semi-quantitative assessment of the risk from each identified hazard to be made. Types of Hazards The first step in the methodology is to decide whether each of the identified hazards are ‘events’ or ‘states’: An Event is a hazard which occurs momentarily, e.g. a vehicle carries out a high-risk lane

change. Usually it is not meaningful to talk of how long such a hazard exists for A State hazard is one which is present for a period of time e.g. vehicle stopped on hard

shoulder – the longer it is present, the greater the risk. Such hazards will have a measurable duration and can persist for long periods

It is important to distinguish between these two types of hazards as the risk scores are evaluated differently depending on the choice. Both types of hazard are assessed based upon the following properties: Event Hazards Event hazards are evaluated by adding together a score for each of the following three factors: The rate at which the hazard is expected to occur The probability that the hazard causes an incident The severity of the incident




IAN 139/11 of 266 Mar 11

State Hazards State hazards are evaluated by adding together a score for each of the following three factors: The likelihood that the hazardous state is present The rate at which incidents occur if the hazardous state is present The severity of the incident, which is the same as for event hazards The definitions and descriptions of the elements that make up both event and state hazards are summarised in Table A1 below.

Hazard Type Component Description

Events States Component 1 How often the hazard is likely to occur Frequency Likelihood

Component 2 A measure of whether or not an incident will be caused by the hazard

Probability Rate

Component 3 The severity of the incident consequences Severity Severity

Table A1 Components of Hazards

In order to determine what overall scores will be assigned for event and state hazards, the project must decide on the scale it will use to score each factor. A logarithmic scale of scoring is used in order to cover the necessary range of values and then present them in a manageable form. An increase of 1 in a score therefore represents a factor of 10 increase in the risk. The tables which follow are examples of the values that each of the event and state factors may be assigned.

Table A2 Example of Classification of Event Hazard Frequencies

Each project would complete columns 3 and 4 in the above table, based on the length of scheme being considered, with column 3 being the product of the nominal number of occurrences per year per mile and the scheme length, and column 4 being the inverse (i.e. 1 divided by the value of column 3, remembering to correct to get the right units e.g. per year, per day, per hour etc.). Having such numbers available has been found to be helpful when evaluating the frequencies of hazard occurrence.

Frequency Classification

Nominal Value: Occurrences/year mile

Occurrences/year/entire project

Frequency of occurrence

Index Value

Very frequent 1,000 6.0 316 5.5 Frequent 100 5.0 31.6 4.5 Probable 10 4.0 3.16 3.5 Occasional 1 3.0 0.316 2.5 Remote 0.1 2.0 0.0316 1.5 Improbable 0.01 1.0 0.00316 0.5 Incredible 0.001 0.0




IAN 139/11 of 266 Mar 11

Table A3 Example of Likelihood Classification of State Hazard

Table A3 requires completion for dealing with state hazards in the same way that Table A2 did for events. Column 2 is again the product of the length of scheme in question and column 3. Typical entries will include ‘x occurrences present at any one time’ and ‘present for x days per year’, where ‘x’ is calculated each time. To give an example, if a scheme has a length of 10 miles, then the value to enter for an ‘occasional’ hazard will be 10 x 0.0001 = 0.001 occurrences on the scheme at any one time (entry in column 4). To calculate how many days of the year this event is likely to be present, this result is multiplied by the number of days in the year, i.e. 0.001 x 365 = 0.365, or about 9 hours. The entry in column 2 would therefore read ‘Present for approximately 9 hours per year’. The figures in Table A4 are used for hazards of both types, event and state, to estimate the frequency/likelihood of an accident occurring once a hazard has occurred/is present.

Table A4 Example of Hazardous Events and States Probability and Rate Classifications

Table A5 shows the consequence values that are used as the final part of the risk evaluation of each hazard.

Likelihood Classification

Interpretation Nominal value per mile of motorway

Expected number of occurrences present on scheme

Index Value

Very frequent 1 6.0 0.316 5.5

Frequent 0.1 5.0 0.0316 4.5 Probable 0.01 4.0

0.00316 3.5 Occasional 0.001 3.0 0.000316 2.5 Remote 0.0001 2.0 0.0000316 1.5 Improbable 0.00001 1.0 0.0000031 0.5 Incredible 0.000001 0

Classification Interpretation Index value Certain It is certain that this hazard, if it occurs, will cause a collision 4 Probable It is probable that this hazard, if it occurs, will cause collision 3 Occasional This hazard, if it occurs, will occasionally cause a collision 2 Remote There is a remote chance that this hazard, if it occurs, will cause a

collision 1

Improbable It is improbable that this hazard, if it occurs, will cause a collision 0




IAN 139/11 of 266 Mar 11

Severity Classification

Interpretation Index Value

Person outside of vehicle

Stationary Vehicle

Motorcycle Car Large Vehicle (LHV, HGV, Bus)

Severe The proportion of collisions that are fatal is expected to be higher than average by at least a factor of 10

2.0 Involved Involved Involved Speed differential approx 60 mph

Speed differential approx 50 mph

Higher than average

The proportion of fatal collisions is expected to be higher than average by a factor between 3 and 10

1.5 No involvement

No involvement

No involvement



Average The distribution of collisions (i.e. ratio of damage-only to fatal) is expected to be similar to the motorway average

1.0 No involvement

No involvement

No involvement



Lower than average

The proportion of fatal collisions is expected to be lower than average by a factor between 3 and 10

0.5 No involvement

No involvement

No involvement



Minor The proportion of collisions that are fatal is expected to be lower than average by at least a factor of 10

0.0 No involvement

No involvement

No involvement

Speed differential < 20 mph

Speed differential < 10 mph

Table A5 Example of Hazardous Events and States Classifications




IAN 139/11 of 266 Mar 11

Once the three elements of a hazard have been assessed then they need to be added up. While risk is usually calculated by multiplying together its constituent elements, adding is appropriate in this instance because of the logarithmic scale that is being used.

Risk index for hazardous event = hazard frequency index + incident probability index + incident severity index Risk index for hazardous State = hazard likelihood index + incident rate index + incident severity index

Event hazards will have a prefix ‘E’ e.g. E08 State hazards will have a prefix ‘S’ e.g. S08 Given the score ranges given in tables A2 to A5, hazard scores will range from 0-12. Risk Scores and Ranking Despite the use of numbers, the risk score is at best semi-quantitative and does not provide an absolute measure of risk, even approximately. The methodology is designed to place each hazard into one of a number of bands, so that it can be seen clearly which hazards are considered to present the greatest risk. This approach also facilitates the calculation of risk changes that a project brings about, thus enabling an assessment to be made as to whether a project has achieved its safety objective. In order to complete such an assessment, each hazard must be reviewed and the impact that the project has on its score considered. By adding together the impact of all such risk changes, the overall change in risk that the project brings is calculated. This ‘before and after’ analysis requires that the change to a given hazard, as a result of implementing a project, is quantified to some degree. The smallest risk change so far provided in this risk assessment method is 0.5, which, given the logarithmic scale being used, represents a factor of 3. As the number of hazards that will experience a risk change of this size is likely to be few or none, some finer scale is needed to measure risk changes. An approach that provides a finer level of granularity in assessing risk change is shown in Table A6.

Change in risk score (logarithmic)

Absolute change in risk

0.5 216% increase in risk 0.4 150% increase in risk 0.3 100% increase in risk (i.e. doubling of risk) 0.2 60% increase in risk 0.1 25% increase in risk 0.0 No change in risk -0.1 20% decrease in risk -0.2 35% decrease in risk -0.3 50% decrease in risk (i.e. risk is halved) -0.4 60% decrease in risk -0.5 70% decrease in risk

Table A6 Measuring before and after risk changes

Using the changes in risk scores listed in Table A6 a hazard’s before and after scores can be assessed. It is normal to assess the initial hazard score as if the project were implemented, and then to consider the change to the hazard score that the scheme brings. Therefore a




IAN 139/11 of 266 Mar 11

hazard may be assessed as an E08 with the scheme implemented, and a change of -0.1 as a result of implementation, meaning that its before score was E08.1. By assessing each hazard in turn in the way described above, total before and after risk scores can be calculated and compared. A.4 Risk Assessment Methodology 2 – Quantitative This section describes a quantitative risk assessment methodology used previously to assess the acceptability of existing and new types of equipment on the HA network. It has also been used to assess the risks associated with alternative design options and with departure applications. It is likely to be most applicable to Type B projects. The risk assessment includes the following steps: Hazard identification Describe associated risks and who they affect Estimate risk (defined as the product of the consequences and the likelihood of the risk

being realised) Assess the tolerability of risk Assess the reasonableness of risk controls Record findings Hazard Identification Hazard identification includes the use of: Generic checklists Hazard logs from previous, similar projects Creative thinking techniques, e.g. brainstorming Within this, it may be helpful to structure hazard identification around the following matrix:

Construction Normal Operations

Planned Maintenance

Emergency Situation

Demolition

Road Users Construction Operatives

Traffic Officers 3rd Parties

There won’t necessarily be specific hazards associated with every user for every stage in the project life cycle (so there won’t always be a something within every cell of the matrix). However, basing the hazard identification on this matrix should ensure that no users/life cycle stages are systematically missed as part of the hazard identification process. In general, checklists and/or existing hazard logs should be applied first, then brainstorming, paying particular attention to any hazards that are introduced, changed or removed by the project. Note that hazard identification should focus on the significant risks associated with the project; it should not look to identify trivial, generic hazards that will be well known and addressed by established standards or design/construction practices.




IAN 139/11 of 266 Mar 11

Associated risks and who they affect For each hazard identified in the previous step, identify the associated risks and who they affect (i.e. road users, construction workers etc.). Depending on the purpose of the risk assessment, it may be necessary to split certain groups down further than this e.g. ‘road users’ to car drivers, LGV drivers, HGV drivers, motorcyclist, NMUs, vehicle recovery workers, emergency services; ‘construction operatives’ to TM operatives and roadworkers. Estimate risk Risk is estimated using the following equation: Risk = consequence x likelihood Depending on the purpose of the risk assessment, the final risk measure may be required to reflect collective or individual risk5. This will need to be taken into account when the consequence and likelihood measures are chosen for the risk assessment. Collective risk is expressed in terms of the rate of Fatalities and Weighted Injuries (FWIs), where a FWI is defined as:

(No. of fatalities) + (0.1 x No. of serious casualties) + (0.01 x No. of slight casualties) The ‘rate’ unit then depends on whether the risk is proportional to time, to the distance travelled on the network, or to the number of ‘transits’ of a particular network feature. Risk proportional to time – this typically applies where exposure to a risk is proportional to time spent travelling or working on the network. Risk proportional to distance travelled – this typically applies to risks associated with a particular route or feature that is continuous along a significant length of the network (where ‘significant’ is defined as lengths in excess of 1km). Risk proportional to number of transits – this typically applies to risks associated with a particular network feature or discrete ‘point’ on the network e.g. a junction, structure or discrete feature or object at the side of the road. Where risk is proportional to time, the units of risk will be the number of FWIs/yr. Where risk is proportional to the distance travelled, units of risk will be no. of FWIs/vehicle km. Where risk is proportional to the number of vehicle transits, units of risk will be no. of FWIs/vehicle transit. Individual risk is only usually calculated in order to compare the value obtained with risk tolerability criteria established by the HSE. These criteria are expressed in terms of the annual probability of death of an exposed person; therefore the units of individual risk calculated in any risk assessment will generally be in these same units.

5 Collective risk measures provide a measure of the safety risk affecting a particular population (e.g.

road users, road workers). Individual risk measures then provide a measure of the safety risk for a

particular individual – usually a hypothetical ‘most exposed’ individual from a particular population




IAN 139/11 of 266 Mar 11

For simple risks, values of consequences and likelihood within the risk equation can be estimated directly; the risk calculation can then be produced in a simple Excel spreadsheet. For more complex risks, it may be necessary to estimate risk using an event tree. For example:

4.48/yr5.12/yr3.2/yr

0.70.80.5

SlightSeriousFatal

4.48/yr5.12/yr3.2/yr

0.70.80.5

SlightSeriousFatal

0.48/yr0.6/yr1.32/yr

0.40.51.1

SlightSeriousFatal

0.48/yr0.6/yr1.32/yr

0.40.51.1

SlightSeriousFatal

12.48/yr4.80/yr1.92/yr

1.30.50.2

SlightSeriousFatal

12.48/yr4.80/yr1.92/yr

1.30.50.2

SlightSeriousFatal

Car leaves carriageway

YES

NO

Does it roll over?

Does it hit an object?

On its roof, badly damaged

On its roof, less damaged

Upright, badly damaged

Upright, less damaged

YES

YES

NO

NO

1.90/yr2.24/yr1.96/yr

0.50.80.7

SlightSeriousFatal

1.90/yr2.24/yr1.96/yr

0.50.80.7

SlightSeriousFatal

= 20/yr

p = 0.2

p = 0.8

p = 0.3

p = 0.7

p = 0.4

p = 0.6

= 1.2/yr

= 2.8/yr

= 6.4/yr

= 9.6/yr

Risk = 1.38 FWI/yr

Risk = 2.20 FWI/yr

Risk = 3.76 FWI/yr

Risk = 2.52 FWI/yr

Total Risk = 9.86 FWI/yr Ideally, estimates of consequences and likelihood within the risk assessment should be based on direct data. However, this may not always be available. In such cases, expert estimates should be used to inform the risk assessment. Sources of direct data include: HAPMS/HAMIS (for validated Stats19 data) HA Accident and Incident Reporting System (AIRS – for supply chain safety data) HA Information Reporting and Recording System (IRIS – for Traffic Officer and other HA

staff safety data) HA Operational Folder Road Casualties in Great Britain (published by DfT) HA project managers (for traffic data) Expert estimates should be obtained through a process of elicitation. This could involve either an individual expert, or a group of experts. The process will generally involve a discussion of the data to be determined. The expert estimates of the data will then be recorded along with the basis for this (including any assumptions or constraints/conditions that may affect the value for the data) and who the ‘experts’ were (to establish their competence to make the judgements they had made). A.4.1 Assess Tolerability Depending on the purpose of the risk assessment, there may be a need to assess the tolerability of a risk. Because the methodology is quantitative, it should be possible to compare the estimated risk values with absolute tolerability criteria.




IAN 139/11 of 266 Mar 11

Where this is required, the following maximum tolerable and maximum acceptable risk levels may be used: Population Maximum Tolerable Risk Limit Maximum Acceptable Risk Limit Construction operatives & Traffic Officers

Individual risk of death of 1 in 1,000 per annum

Individual risk of death of 1 in 1,000,00 per annum

Road users in situations where they are directly affected by the work activities of construction operatives & Traffic Officers

Individual risk of death of 1 in 10,000 per annum


Road Users (all other situations)

10 x (National average risk level for a particular system or activity), expressed in terms of risk of a FWI

(National average risk level for a particular system or activity)/10, expressed in terms of risk of a FWI

3rd Parties Individual risk of death of 1 in 10,000 per annum


Safety risks greater than the maximum tolerable risk limit should not be tolerated. Where the safety risks are demonstrably below the maximum acceptable risk limit then no additional safety risk controls should be implemented. The only exception is if there are obvious good practices that have not been implemented. A.4.2 Criteria to assess the reasonableness of risk controls

Risk controls may be considered reasonable wherever: Costs of preventing a fatality do not exceed the established Value of Preventing a Fatality

(VPF) figure Costs, time or resources to deliver the controls do not impact the ability to deliver other

safety measures that have a higher benefit-cost ratio The controls do not have an unreasonable impact on the performance of the network, as

measured against criteria other than safety e.g. Journey Time Reliability, carbon emissions

Record Findings The purpose of this step is to make sure that the application of the risk assessment process is auditable in the future – to record what was done, why and on what basis. Detail recorded for a risk assessment should include: The conclusions/findings of the risk assessment Detail of any calculations made under each of the steps in the process Any assumptions/decisions underpinning the assessment Any data sources Who did the risk assessment This last point is important as it could be needed in the future to demonstrate that the risk assessment was undertaken by a competent person.




IAN 139/11 of 266 Mar 11

APPENDIX B. OPTIONS RISK ASSESSMENT The PSRM Work Instructions are formally applied once a project has been selected for implementation and the means of implementation are also known i.e. a project option has been chosen. In some instances, to reach this stage, it will be necessary to select one implementation option from several that are available. One of the inputs to deciding which is most suitable will normally be the level of risk that each option presents. To obtain this information, it is necessary to carry out some level of options risk assessment. In these circumstances, while outside the lifecycle phases where the PSRM Work Instructions are formally applied, elements from them can be applied to produce the required options risk assessment. The need to apply elements of the Work Instructions during options risk assessment will vary from project to project, so the process is not mandatory. However, guidance is provided below as to how elements of the Work Instructions may be applied. B.1 Objective of Options Risk Assessment The objective of the options risk assessment is to provide sufficient information, in respect of each project options’ expected safety performance, to support the option selection process. This objective is the same for all projects, whatever Type of SMS turns out to be applicable to the project. B.2 Requirements Given that the objective of this risk assessment is to provide ‘sufficient information’ to support option selection, it is reasonable to ask what is sufficient information. Unfortunately a precise answer to this question cannot be given. Essentially more risk assessment is needed for those projects that involve greater levels of risk. The outline process to follow should be: Apply elements of Work Instruction 001 to each option to understand what kind of SMS

requirements are likely to be applicable i.e. A, B or C Once the SMS Type is known, refer to the relevant Work Instruction (002, 003 or 004) for

details on the appropriate risk assessment activities to be applied in options risk assessment

Assess the degree of formality with which the risk assessment activities need to be applied. It will be a project specific decision as to how formal the application needs to be, but generally, it will be less formal than when in the later stages of the project lifecycle. Sufficient information will be needed to answer the following questions:

– What level of safety risk could this option result in? Answering this question will

require that the hazards associated with each option are identified and assessed – including hazards associated with the construction stage as well as for operation and maintenance

– What level of safety benefit could this option provide? Answering this question will require that the hazards associated with each option are identified, they are assessed and then a measure of the change in risk that the project brings to each hazard is evaluated. This question could also usefully consider the safety benefit-cost ratios provided by different project options

– What are the expected safety management costs of this option? Answering this question will require an evaluation of the effort involved in each safety management activity

During options selection, it may not be necessary to obtain precise answers to these questions as the most appropriate outcome may become obvious. However, the degree of precision needed will be a project specific consideration. The greater the consequences




IAN 139/11 of 266 Mar 11

associated with an incorrect decision, the greater the level of risk assessment that will be needed. Where available, the options risk assessment activities should make use of existing risk assessment information and carry out only those risk assessment activities that are essential to support option selection. In some cases, especially for projects that require a Type A SMS, it may be that a qualitative review of existing hazards is sufficient to support options selection. B.3 Deliverable There is no specific deliverable arising from the options risk assessment. A separate report may be produced or the work may be documented in another report. For more information as to the type of material to be documented, please refer to the sections from Work Instructions 002 to 004 that address risk assessment activities.




IAN 139/11 of 266 Mar 11

APPENDIX C. GOAL STRUCTURED NOTATION

C.1 An Introduction to GSN As described in Work Instruction 004, the objective of a Project Safety Report is to summarise the evidence demonstrating that the project safety objectives have been met by providing a clear, comprehensive and defensible argument. The safety report needs to clearly show all relationships between the safety evidence and the safety objectives. For less complex safety arguments, as will be the case for a Type A Project (and perhaps for some Type B Projects) well-structured approaches to expressing safety arguments in a Safety Report can be made using free text. However, problems arise when safety arguments become more complex (as will be the case for Type C Projects and some Type B Projects). Due to the overall complexity of some projects, it is quite possible that the meaning of the text, and therefore the structure of the safety argument, may become ambiguous and unclear. Cross-references to various documents are often necessary; multiple cross-references in the text can be awkward and can disrupt the flow of the main argument. Goal Structured Notation (GSN) is a method of getting around this problem. It is a structured technique that has been developed to address the need to clearly express and present safety arguments and is a very useful tool for developing Project Safety Reports. C.2 How Does GSN Work? Goal Structured Notation (GSN) is a graphical approach. It breaks down a top level goal into various constituent elements. The aim is to break a goal down to sufficiently small elements so that an activity or piece of evidence can be produced to show that this element has been achieved. In the context of a Safety Report, this approach can be used to structure an argument to show that the project safety objective has been achieved and also to show that all the necessary evidence to support the demonstration of this achievement is in place. The structure of the Safety Report can then be based on this argument structure. Typically, the following symbols are used to represent the GSN elements:

Goal or sub-goal

Evidence Strategy Context

Figure C1 Symbols Representing Elements of GSN

C3. Using GSN to Write a Safety Report – An Example Figure C2 shows an example goal structure. When formulating a goal structure, begin with the top-level goal(s). In this structure, as in most, there exists one ‘top level’ goal – “This managed motorway project is acceptable safe”. The second stage is to break this goal down into sub-goals, either directly or, as in this case, indirectly through a strategy. The three argument strategies put forward as a means of addressing the top level goal in Figure C2 are “Demonstrate that the safety objective has been agreed and is likely to be achieved”, “Demonstrate that a robust safety management process is being followed” and “Demonstrate good management of hazards”. The third stage is to define the sub-goals which substantiate the strategies.




IAN 139/11 of 266 Mar 11

At some stage in a goal structure, a goal statement is put forward that need not be broken down and can be clearly supported by reference to some evidence. In this case, an example of this would be the goal “Baseline for safety objective defined and agreed” which is supported by direct reference to the evidence, see the “Safety Baseline and Objectives Report”. Evidence refers to pieces of work, e.g. documents produced. For example, for the sub-goal “A hazard log is produced”, the evidence can be stated simply as “Hazard log”. Other sub-goals may need to be broken down through further levels of sub-goals, and perhaps also strategies, before the evidence level is reached. The same piece of evidence may support more than one sub-goal. Alternatively, the symbol naming that piece of evidence may be repeated if this makes the layout simpler and avoids too many crossing arrows. Sometimes it may not be appropriate to break the GSN down to the evidence level, but rather end with a strategy. An example of this would be a sub-goal of “Good practice is followed through project execution”, which may be difficult to break down into evidence when the project is still at the planning stage. In such cases, it may be appropriate to break this down into strategies, e.g. “Good practice followed during design and implementation” and “Project wide systems followed”. It is thus clear that different branches of the network will differ in the number and nature of their levels. It is useful to provide a cross-reference to the relevant sections of the safety report for each GSN element as shown in the example in Figure C2. It can also be useful to include a document/database reference number for the evidence elements.




IAN 139/11 of 266 Mar 11

Figure C2 Example of a GSN




IAN 139/11 of 266 Mar 11

The GSN that is used to support a project will also evolve over time. The GSN symbols can be used to reflect the state of the project in terms of meeting the overall safety objective by indicating the state of completeness of each goal. A colouring scheme such as that shown below is useful in this context (this colouring scheme is also used in Figure C3):

Goal

Goal

Goal



Goal not yet met – depends on future activities

Figure C3 Colour Coded Symbols as Part of the GSN

C4. Summary of the Benefits of using GSN To summarise the benefits that using GSN brings include: Clarity in the presentation of a safety argument, in particular when it is used to structure

the project safety report Assistance in the development of a clear and concise safety argument Clarity in demonstrating that all elements of a safety argument have been addressed Improved communication of the safety argument and its achievement to stakeholders Improved ability to re-use safety arguments from previous projects and to compare safety

arguments with other projects

APPENDIX D DEVELOPMENT OF A RACI MATRIX

D.1 What is a RACI matrix? A RACI matrix is used to support the allocation of roles and responsibilities associated with carrying out a particular activity and therefore assists in showing that all required responsibilities have been allocated. Such a matrix can be used to analyse the roles and responsibilities involved in safety management activities. It has been found to be of particular use in relation to Safety Approval, where helping to show that all areas of approval responsibility are appropriately allocated. It will not generally need to be used in association with a Type A or Type B SMS and will be most frequently associated with a Type C SMS. ‘RACI’ is an abbreviation for “Responsible, Accountable, Consulted, Informed”, which are the four roles that can be assigned to the individuals involved in a given activity. The RACI roles are defined as follows:




IAN 139/11 of 266 Mar 11

Assignment Interpretation6 Accountable The party who is ultimately answerable for the activity. The party has ‘yes’ or ‘no’

authority and veto power. Only one ‘A’ can be assigned to an activity and this accountability cannot be delegated to another role

Responsible The party responsible for action/implementation. This party is usually the one which completes the task. However, this party may delegate parts of the work to others, including other organisations, although it retains responsibility for the completion of the task. If the party consists of several individuals, the degree of responsibility on each person is determined by the 'Accountable' person for that activity

Consulted A party which should be consulted prior to a final decision/action. Communication should be two-way, with the consultee required to respond

Informed The party which should be informed after a decision/action is taken. Communication is one-way. There is no requirement for an informed party to respond

Table D1 Defining RACI N.B. “party” in the above table can refer to an individual or group, as appropriate. D.2 How is a RACI matrix used? A RACI matrix can be used at any stage to clarify roles and responsibilities. For a particular process, a RACI matrix is produced in the following manner: Each of the roles involved in the process is defined A matrix template is created listing roles along one axis Each of the activities in the process are identified and listed along the other axis of the

matrix. The activities should be expressed in a concise manner in the matrix, and relate to a need rather than to an individual person/group, e.g. “Assess the impact on safety...” rather than “Safety manager should assess the impact on safety...”. It is useful to define the activities using an action verb, with an indication of the main outcome in the case of judgements or decisions, e.g. “Review safety report to achieve verification”

The appropriate RACI assignments should be allocated to the cells in the matrix produced by combining the ‘role’ and ‘activity’ parameters

D.3 Using a RACI matrix – An Example The following example shows what a RACI matrix may look like for the task of writing and gaining approval of a document. The steps involved are shown down the left hand side of the matrix and the roles involved across the top.

Role Team member

Team Leader Approver Document Distributer

Document is written R A I

Reviewed by team leader

C R/A I

Approval is provided I C A/R I

Activity

Document is issued to relevant recipients

A I R

Table D2 Example of Part of a RACI Matrix

6 Party in this context can also be an individual person




IAN 139/11 of 266 Mar 11

In this instance, there are four stages in the overall process and four individuals involved in executing this process. First, the document is written. For this activity, the team member is responsible although accountability for this activity remains with his superior, the team leader. The approver, who will be involved later, is informed that this activity is taking place. At this stage, the document distributor is not involved. Once the document is written, it is reviewed by the team leader, who is therefore both responsible and accountable for this activity. The team member is consulted i.e. two way communications take place and the approver is informed of progress. The third step involves approval being provided. The approver is therefore both responsible and accountable for this activity. The team leader is consulted but the team member is now only informed. The document distributor is also now informed as this will trigger his involvement. For the final step, the approved document is distributed. The document distributor is responsible for this activity, but accountability for making sure that it is appropriately completed remains with the team leader. The approver is informed that this has taken place, but the team member is no longer involved. Once the preliminary matrix has been produced, it should be reviewed in two stages: Analyse the individual roles (columns in example above) - Are the assignments of

R/A/C/I appropriate to the role? Warning signs include: – Many ‘A’s- is it necessary for this role to be accountable for so many activities?

There is a danger of delays if this role is overwhelmed by its responsibility for signing off so many activities

– Many ‘R’s- is this workload feasible? (This is a particular concern if the column refers to an individual rather than a group)

– No ‘R’s or ‘A’s- is this functional role required, or can its duties be assumed by another role?

– No empty spaces- does this role have to do so much? In particular, should some of the ‘C’s in fact be ‘I’s, or should some of the ‘I’s be blank?

Analyse the individual activities (rows in the example above) - Are the assignments of

R/A/C/I appropriate to the activity? Particular warning signs include: – No ‘A’s and/or ‘R’s- there should be only one ‘A’ and at least one ‘R’. Does this

activity need to be broken down further? – Many ‘R’s- are there too many roles involved in this activity for effective co-

ordination? – Many ‘C’s- are all these consultations justified? – Many ‘I’s- are all these information requirements justified? – No empty cells- too many roles are involved in the individual activity which may be

unnecessarily complicated D.4 The Need for a RACI matrix RACI matrices will not be required for all projects (generally only for Type C and occasionally Type B) and where they are, will only be needed for certain tasks. In general, such a matrix helps in a situation where: The particular activity in question has either novelty or uncertainty associated with it There is disagreement as to how particular activities should be undertaken or who should

be responsible for a particular activity




IAN 139/11 of 266 Mar 11

The benefits of RACI include: Assistance is obtained in clarifying roles and responsibilities Duplication of effort is more easily avoided Assistance with communication is provided as communications requirements are stated

explicitly An initial guide is obtained as to the required competencies for activities




IAN 139/11 of 266 Mar 11

APPENDIX E DERIVATION OF SAFETY INTEGRITY LEVELS

The concept of safety integrity levels (SILs) was introduced during the development of BS EN 61508 (BSI 2002) as a measure of the quality or dependability of a system which has a safety function. It is a measure of the confidence with which the system can be expected to perform that function. E.1 Definition of a Safety Integrity Level A Safety Integrity Level (SIL) is defined as the relative level of risk-reduction that is either provided or is required by a safety function/system. Defining a SIL therefore specifies a target level of risk reduction that a particular safety function/system should deliver. There are five levels of safety integrity with SIL 0 the lowest (meaning not safety related) and SIL 4 the highest (usually interpreted as meaning safety critical). SILs can be assigned to any electrical and/or electronic and/or programmable electronic systems. The greater the risk reduction to be delivered, the higher the integrity of the system providing that risk reduction must be, hence the higher the applicable SIL must be. The following diagram illustrates this point.

Increasing Risk

Residual Risk Tolerable Risk EUC Risk

Necessary risk reduction

Actual risk reduction

Increasing Risk

Residual RiskResidual Risk Tolerable RiskTolerable Risk EUC RiskEUC Risk

Necessary risk reduction

Actual risk reduction

Figure E1 Defining SILs

E.2 Implications of SIL Selection The SIL selected for a system/function has implications for the development processes that are used in association with the system/function. The higher the SIL, the more onerous that the development processes are that need to be applied and the Larger the associated overhead costs will be. E.3 SILs and IEC 61508 IEC (International Electrotechnical Committee) 61508 is an international standard in seven parts that sets out a generic approach for the safety lifecycle activities of E/E/PE (electrical and/or electronic and/or programmable electronic) systems. This standard provides a risk-based approach for determining the required performance of safety-related E/E/PE systems. It also describes how an appropriate SIL may be determined and the requirements for the development processes to be used in association with systems/functions defined as SIL 0 to 4. E.4 Deriving a SIL Part 5 of IEC 61508 describes a number of methods that can be used to determine the SIL of a system/function. The simplest method of obtaining a SIL is by comparing the system/function with a similar one for which a SIL has already been defined. If the systems are sufficiently similar the same SIL can be applied to the new system/function. However, not many systems in the highways sector have a defined SIL, so it may be necessary to derive a SIL from first principles.




IAN 139/11 of 266 Mar 11

E.5 Factors to take into account when deriving a SIL It should be noted that the example methods given in IEC 61508 cannot be used directly without further calibration against the criteria for tolerability of risk for the particular project under consideration.




IAN 139/11 of 266 Mar 11

APPENDIX F COTS AND SOUP

F.1 What are COTS and SOUP? COTS is an abbreviation for Commercial-Off-The-Shelf and covers both hardware and software. SOUP is Software-Of-Uncertain-Pedigree. Almost all highways projects that involve the deployment of equipment will require the use of COTS equipment or SOUP. F.2 Safety management implications of COTS and SOUP The complete development history of COTS equipment and SOUP is almost always not available so problems can arise in assessing the integrity of such equipment/software. It can then be difficult to show that a SIL requirement has been achieved. There are a range of actions that can be taken in order to produce an argument for the safety integrity of a particular piece of COTS/SOUP: Obtain information from the supplier regarding the development and testing of the

software, such as reliability statistics Obtain information from the operating system supplier or equipment supplier on the

operating system of operating platform, such as reliability statistics Construct a ‘proven-in-use’ argument based on evidence of how this software has been

used in other comparable projects Conduct extra in-house testing of the software to demonstrate its robustness, using both

functional and ‘soak’ testing (run the system at high levels of load for prolonged periods of time to identify any performance problems that appear after numerous transactions have been executed)

Reduce the safety integrity requirement that applies to the software/equipment in question by putting in place an additional mitigation that is not part of this equipment/software

Consider the specific hazards that may arise from lack of equipment/software integrity and make sure that they are mitigated

The following questions are a non-exhaustive list of the issues which should be considered: Is there sufficient experience of the software’s use to expose bugs? Have formal industry studies of the software’s stability been carried out? Are known software bugs mitigated by the application? How is the software update controlled? Can a system crash be handled in a safe way? Will changing software/hardware affect stability? Is the performance of the software appropriate for the application? How robust is each function? Running of regression tests – are appropriate procedures in place? How will virus attack be mitigated? Is there sufficient firewall protection? How are system administration requirements of the software addressed (e.g. security)? Are there sufficient skills available in respect of the software environment/tools? Has interference between independent applications running on the same platform been

considered? Have the completeness of the operating system for this application been verified? Are staff competent with all relevant aspects of the software? It is a requirement for all three types of projects (Types A, B and C) to consider the use of COTS equipment and SOUP and the impact of the associated integrity requirements.




IAN 139/11 of 266 Mar 11

APPENDIX G RELEVANT SAFETY STANDARDS

This section is for information only. The Work Instructions and Guidance Documents set out what is needed for projects. However, those interested may wish to consult some of the standards that are available. To that end, a brief overview of applicable standards is provided in this section. Such standards have a greater relevance for Type C SMSs. IEC 61508 (Functional Safety of Electrical/Electronic/Programmable Electronic

Systems). This standard, which draws significantly upon methods and practices used in the process industry, is based around hazard analysis and risk assessment. Considerable effort is expended on describing SILs, assigning SILs, and also on the methods that should be used in design in order to claim adherence to particular SILs. The standard is weak in describing a process to use for hazard identification and analysis. It also provides little guidance in dealing with the configuration data associated with safety related systems. There is little treatment of maintenance and operational effects in terms of safety. However, IEC 61508 is a standard that applies to all parts of a system, and not just the electronic/electrical parts. The standard notes that all aspects of a system must be analysed from a safety perspective and then the necessary mitigations incorporated. These mitigations may be through the design of electronic/electrical components but will also include maintenance and operational procedures

Cenelec Railway Standards (EN50126, 50128, 50129). These standards are an industry specific interpretation of IEC 61508. The approach that is described is therefore similar to that of IEC 61508, with some additional requirements that are deemed applicable to the rail industry

Engineering Safety Management, Fundamentals and Guidance (the ‘Yellow Book’). This is a UK specific standard, and can be considered to apply only to the mainline railway system, although other operators such as London Underground also make use of this guidance. The standard draws heavily on both IEC 61508 and also the Cenelec standards. It provides significantly more detail in specific areas, such as some areas of safety management and also defines a risk assessment process to follow. More guidance in the areas of configuration data and maintenance/operations is provided than with IEC 61508

Defence Standard 00-56 (Safety Management Requirements for Defence Systems). This standard, developed for the UK defence industry, sets out a safety analysis method. This method is based on an initial hazard analysis, followed by risk assessment of each hazard, using a risk matrix approach, and the identification of suitable mitigations. The standard recommends that a hazard log is produced and provides guidance on its format. The concept of a Safety Integrity Level (SIL) was introduced in this standard. Although issued before IEC 61508, there is a reasonable degree of consistency between the two standards

MIL-STD-882 (US Military Standard). This standard has some similarities to Defence Standard 00-56, in that it recommends a risk based approach, and offers the structure of an approach to follow rather than a more detailed prescribed method. It is in general strong on hazard analysis activities, and has more information on Operational and Support Hazard Analysis (OSHA), which is an area treated in minimal detail in most other standards. OSHA activities address the analysis of the processes and procedures that inevitably surround systems, and thus the human interaction that they describe

Defence Standard 00-58 (HAZOP Studies on Systems containing Programmable Electronics). This standard provides guidance on one specific technique (Hazard and Operability analysis) which is used to identify system hazards. In general, HAZOP studies form an important part of the overall hazard identification and analysis process

RTCA/DO-200A (FAA Standard). This standard, which builds on DO-178(B), a software testing standard, provides guidance on assuring the integrity of data used in conjunction




IAN 139/11 of 266 Mar 11

with safety critical software. It is targeted at aeronautical data, and sets out assurance levels for data used in applications of differing integrity

IEE/HSE/BCS Safety, Competency and Commitment Guidelines. A set of guidelines aimed at helping organisations to assess and record the competencies of staff working on all aspects of Electrical, Electronic and Programmable Electronic Systems (E/E/PES), particularly in safety-related applications

MISRA Guidelines. These are guidelines, which relate specifically to the development of software for in vehicle use. A subsequent update has been produced which relates specifically to the use of the C programming language in conjunction with in vehicle equipment. The standard follows the philosophy of IEC 61508, but is targeted specifically at software, and does not address the issue of system safety. It offers a significantly simplified approach to allocating and demonstrating conformance to SILs

None of these standards are directly applicable to the Highways Agency sector, and therefore to follow one standard rigorously creates the potential for missing certain risks. By drawing on a range of standards it is possible to make good on an individual standard’s weaknesses and also to ensure that the widest range of possible safety tools is considered.




IAN 139/11 of 266 Mar 11

Appendix H: IAN 139/11 Managed Motorways Project Safety Risk Work Instructions in English DBFO schemes.

When used on the M25 DBFO Scheme, this IAN is to be amended as follows:

Para No. Description All occurrences The HA Project Manager is the Department’s Nominee unless otherwise stated Part 0 Introduction 1.1 Delete “undertaken by the Highways Agency” and insert “undertaken for the Highways

Agency” Delete “an appropriate Safety Management System” and insert “a management system that addresses safety” Delete “SMS in place the HA” and insert “SMS in place or assessing the adequacy of an existing management system the HA” In the fourth paragraph delete “Agency’s” and insert “Highways Agency’s”

1.4 The requirement in the interpretation principles to delete this section shall not be implemented.

1.5 Delete “Project Manager” and insert “DBFO Co” Part 1: Work Instruction WI001


1.1 In the fourth paragraph delete “Agency’s” and insert “Highways Agency’s” 1.4 The requirement in the interpretation principles to delete this section shall only apply to

the first paragraph. 1.5 Delete “Project Manager” and insert “DBFO Co” 2.2 Delete last paragraph and insert “The outcome of Table 2.1 are to be included in the

DBFO Co’s Integrated Management System.” 2.5 Delete “Approval” and insert “Review” in the heading

Delete paragraph and insert “Deliverables arising from the application of the SMS Selection Process are to be included as Design Data.”

3.5 In the heading and paragraph delete “ownership” and insert “risk” 4 last bullet point Delete “departure applications” and insert “Alternative Proposal/Departure from Standard”5 Delete “formally approved” and insert “agreed under the Review Procedure”

Delete the second and third paragraph and insert: “If the project is recommending a Type B SMS, this is submitted to the the Department’s Nominee under the Review Procedure. The Department’s Nominee will consult with the PSCRG to decide whether or not to agree to this recommendation. If the project is recommending any aspects of a Type C SMS, this is submitted first to the Department’s Nominee under the Review Procedure. The Department’s Nominee will consult with the PSCRG and then submit a recommendation to the NSCRG. The NSCRG will then consider this and provide their response back to the Department’s Nominee. The Department’s Nominee then respond to the DBFO Co. Before work to implement the SMS begins, there must have been no objection under the Review Procedure to the project SMS.”

Appendix C CDM

Delete definition and insert “Construction (Design and Management) Regulations 2007”

Part 2: Guidance For Work Instruction WI001


1.1 Delete “and gain approval for” 1.4 The requirement in the interpretation principles to delete this section shall not be

implemented. Delete “Agency staff” and insert “Highways Agency and DBFO Co’s staff” at both occurrences. Delete “Agency’s” and insert “DBFO CO’s”

The second Table 2-1

In Section 4. Standards and Legislation - Departures from standards/existing standards and current standards are Alternative Proposals unless it is in respect of the Works in relation to a Later Upgraded Section and before the Price Adjustment in respect of such Later Upgraded Section is determined in which case a Departure from Standard is to be applied for.




IAN 139/11 of 266 Mar 11

Para No. Description Part 5: Work Instruction WI003

Safety Risk Management for Projects with Type B Features

1.1 Delete “Agency’s” and insert “Highways Agency’s” 1.4 The requirement in the interpretation principles to delete this section shall not be

implemented. Delete “all other relevant ………Road Safety Audit” and insert “the DBFO project”

3.2.2 Delete “HA policy or standards” and insert “HA policy, Contract requirements or standards”

5.2 In this section “Departures from Standards”, “Departure” and “Departures” shall mean an Alternative Proposals unless it is in respect of the Works in relation to a Later Upgraded Section and before the Price Adjustment in respect of such Later Upgraded Section is determined in which case a Departure from Standard is meant.

6.3 Delete “to the HA Project Manager” and insert “in the project records” 10 Delete first sentence and insert “All project safety deliverables must be submitted for

review under the Review Procedure.” Delete “The first step in this process” and insert “The Department’s Nominee” Delete “project team” and insert “Department’s Nominee” Delete the third paragraph and insert “Before work to implement the project safety deliverables begins, there must have been no objection under the Review Procedure to the project safety deliverables.”

Appendix B Delete entry for Project Manager Part 6: Guidance For Work Instruction WI003


2 fifth paragraph

Delete “The Departure process” and insert “The Departure from Standard/Alternative Proposal process” Delete “Consultants’ own internal project processes” and insert “DBFO Co’s own internal project processes”

3.2 Delete “For Major Projects, the” and insert “The” 3.2.2 Delete “the Departures process” and insert “the Departure from Standard/Alternative

Proposal process” 4.2 Delete “Departures” and insert “Departures from Standard/Alternative Proposals” at both

occurrences 7.2 Delete “For Major Projects and” and insert “For” 8.3 Delete “Managing Agent or consultant” and insert “DBFO Co” Part 7: Work Instruction WI004

Safety Risk Management for Projects with Type C Features

1.4 The requirement in the interpretation principles to delete this section shall not be implemented. Delete “existing HA project processes, such as the Departures” and insert “processes, such as the Alternative Proposals”

1.5 Delete “Project Manager” and insert “DBFO Co” 2 After Figure 2-1 delete “acceptance and approvals” and insert “compliance”

3.3 second bullet Delete “Agency” and insert “Highways Agency” at both occurrences 4.3 sixth bullet Delete “sub-consultant” and insert “Sub-Contractor” 4.3 tenth bullet Delete “as it is not …….. for its operation” and insert “where applicable.” 4.5 Delete “Approval” and insert “Review” 5.1.1 Delete “Departure” and insert “Departure from Standard/Alternative Proposal” at three

occurrences Delete “Departures” and insert “Departures from Standard/Alternative Proposals”

6.3 Delete “delivery to the ……… of project operation” and insert “inspection by the Department’s Nominee”

6.4 Delete “Approval” and insert “Review” Delete “, which does require approval”

7.4 Delete “Approval” and insert “Review” 8.4 Delete “Approval” and insert “Review” 9.4 Delete “Approval” and insert “Review” 10 Delete “formally accepted and approved by the relevant parts of the HA” and insert

“submitted to the Department’s Nominee under the Review Procedure” Delete “The first step ….. and then” and insert “The Department’s Nominee may” Delete “project team” and insert “Department’s Nominee” Delete “Once a project safety deliverable …….. shown in figure 10-1” and insert “The Department’s Nominee then returns the project safety deliverable under the Review Procedure”




IAN 139/11 of 266 Mar 11

Para No. Description Appendix C CDM




2.4 The requirement in the interpretation principles to delete this section shall not be implemented. Delete “Departure from Standard” and insert “Departure from Standard/Alternative Proposal”

4.3 Delete “Under normal circumstances …….Motorways projects.”

5.2 Delete the first paragraph and insert “The DBFO Co is responsible for all versions of the Safety Strategy and Plan. The operator/maintainer should be involved with safety management activities at an early stage as possible.”

5.3 Project Organisation

Delete “lines interface to the Highways Agency” and insert “lines interface to the Department’s Nominee”

5.3 Safety Organisation

Delete “The Project Team” and insert “The project team” Delete the entries for “Project Delivery/Project Delivery Consultant“ and ”The Delivery Team”

5.3 Ownership Delete the paragraph and insert “The DBFO Co is responsible for all versions of the Safety Strategy and Plan. The operator/maintainer should be involved with safety management activities as early a stage as possible.”

9.2 Delete “For all Agency projects” and insert “For all Department projects” Delete “HA Projects?” and insert “Department Projects?”

9.2 Table 9-1

At Section Reference 7.1: Delete “departures from standard” and insert “Alternative Proposal/Departure from Standard” Delete “sought to obtain departure from standard” and insert “obtained an Alternative Proposal/Departure from Standard”

9.4 Delete “approval” and insert “review” in heading and all occurrences in the paragraph

Part 9 Appendices to Guidance for Work Instructions WI001, WI003 & WI004 A.4 Delete “departure” and insert “Alternative Proposal/Departure from Standard” Part 10 Safety Report Template 8.1 Delete “departures” and insert “Alternative Proposals/Departures from Standards” Part 11 Safety Plan Template 2.3 Table 2-2

In Feature 4 delete “Critical departures” and insert Critical Alternative Proposals/Departures from Standards”




IAN 139/11 of 266 Mar 11

When used on all other English DBFO Schemes, this IAN is to be amended as follows:

Para No. Description All occurrences The HA Project Manager is the Department’s Nominee unless otherwise stated Part 0 Introduction 1.1 Delete “undertaken by the Highways Agency” and insert “undertaken for the Highways

Agency” Delete “an appropriate Safety Management System” and insert “a management system that addresses safety” Delete “SMS in place the HA” and insert “SMS in place or assessing the adequacy of an existing management system the HA” In the fourth paragraph delete “Agency’s” and insert “Highways Agency’s”

1.5 Delete “Project Manager” and insert “DBFO Co” Part 1: Work Instruction WI001


1.1 In the fourth paragraph delete “Agency’s” and insert “Highways Agency’s” 1.4 Delete the first paragraph 1.5 Delete “Project Manager” and insert “DBFO Co” 2.2 Delete last paragraph and insert “The outcome of Table 2.1 are to be included in the

DBFO Co’s Management System documentation.” Table 2-1 Delete “departures from standards” and insert “Alternative Proposals” 2.5 Delete “Approval” and insert “Review” in the heading

Delete paragraph and insert “Deliverables arising from the application of the SMS Selection Process are to be included as Design Data.”

3.5 In the heading and paragraph delete “ownership” and insert “risk” 4 last bullet point Delete “departure applications” and insert “Alternative Proposal” 5 Delete “formally approved” and insert “agreed under the Review Procedure”

Delete the second and third paragraph and insert: “If the project is recommending a Type B SMS, this is submitted to the the Department’s Nominee under the Review Procedure. The Department’s Nominee will consult with the PSCRG to decide whether or not to agree to this recommendation. If the project is recommending any aspects of a Type C SMS, this is submitted first to the Department’s Nominee under the Review Procedure. The Department’s Nominee will consult with the PSCRG and then submit a recommendation to the NSCRG. The NSCRG will then consider this and provide their response back to the Department’s Nominee. The Department’s Nominee then respond to the DBFO Co. Before work to implement the SMS begins, there must have been no objection under the Review Procedure to the project SMS.”

Appendix C CDM




1.1 Delete “and gain approval for” 1.4 Delete “Agency staff” and insert “Highways Agency and DBFO Co’s staff” at both

occurrences. Delete “Agency’s” and insert “DBFO CO’s”

The second Table 2-1

In Section 4. Standards and Legislation - Departures from standards/existing standards and current standards are Alternative Proposals

Part 5: Work Instruction WI003


1.1 Delete “Agency’s” and insert “Highways Agency’s” 1.4 Delete “all other relevant ………Road Safety Audit” and insert “the DBFO project” 3.2.2 Delete “HA policy or standards” and insert “HA policy, Contract requirements or

standards” 5.2 Delete “Departures from Standards” and insert “Alternative Proposals”

Delete “Departures” and insert “Alternative Proposal” Delete “a Departure” and insert “an Alternative Proposal” Delete “the Departure” and insert “the Alternative Proposal”




IAN 139/11 of 266 Mar 11

Para No. Description 6.3 Delete “to the HA Project Manager” and insert “in the project records” 10 Delete first sentence and insert “All project safety deliverables must be submitted for

review under the Review Procedure.” Delete “The first step in this process” and insert “The Department’s Nominee” Delete “project team” and insert “Department’s Nominee” Delete the third paragraph and insert “Before work to implement the project safety deliverables begins, there must have been no objection under the Review Procedure to the project safety deliverables.”

Appendix B Delete entry for Project Manager Part 6: Guidance For Work Instruction WI003


2 fifth paragraph

Delete “The Departure process” and insert “The Alternative Proposal process” Delete “Consultants’ own internal project processes” and insert “DBFO Co’s own internal project processes”

3.2 Delete “For Major Projects, the” and insert “The” 3.2.2 Delete “the Departures process” and insert “the Alternative Proposal process” 4.2 Delete “Departures” and insert “Alternative Proposals” at both occurrences 7.2 Delete “For Major Projects and” and insert “For” 8.3 Delete “Managing Agent or consultant” and insert “DBFO Co” Part 7: Work Instruction WI004


1.4 Delete “existing HA project processes, such as the Departures” and insert “processes, such as the Alternative Proposals”

1.5 Delete “Project Manager” and insert “DBFO Co” 2 After Figure 2-1 delete “acceptance and approvals” and insert “compliance”

3.3 second bullet Delete “Agency” and insert “Highways Agency” at both occurrences 4.3 sixth bullet Delete “sub-consultant” and insert “Sub-Contractor” 4.3 tenth bullet Delete “as it is not …….. for its operation” and insert “where applicable” 4.5 Delete “Approval” and insert “Review” 5.1.1 Delete “Departure” and insert “Alternative Proposal” at three occurrences

Delete “Departures” and insert “Alternative Proposals” 6.3 Delete “delivery to the ……… of project operation” and insert “inspection by the

Department’s Nominee” 6.4 Delete “Approval” and insert “Review”

Delete “, which does require approval” 7.4 Delete “Approval” and insert “Review” 8.4 Delete “Approval” and insert “Review” 9.4 Delete “Approval” and insert “Review” 10 Delete “formally accepted and approved by the relevant parts of the HA” and insert

“submitted to the Department’s Nominee under the Review Procedure” Delete “The first step ….. and then” and insert “The Department’s Nominee may” Delete “project team” and insert “Department’s Nominee” Delete “Once a project safety deliverable …….. shown in figure 10-1” and insert “The Department’s Nominee then returns the project safety deliverable under the Review Procedure”

Appendix C CDM




2.4 Delete “Departure from Standard” and insert “Alternative Proposal”

4.3 Delete “Under normal circumstances …….Motorways projects.”

5.2 Delete the first paragraph and insert “The DBFO Co is responsible for all versions of the Safety Strategy and Plan. The operator/maintainer should be involved with safety management activities at an early stage as possible.”

5.3 Project Organisation

Delete “lines interface to the Highways Agency” and insert “lines interface to the Department’s Nominee”

5.3 Safety Organisation

Delete “The Project Team” and insert “The project team” Delete the entries for “Project Delivery/Project Delivery Consultant“ and ”The Delivery Team”

5.3 Ownership Delete the paragraph and insert “The DBFO Co is responsible for all versions of the Safety Strategy and Plan. The operator/maintainer should be involved with safety




IAN 139/11 of 266 Mar 11

Para No. Description management activities as early a stage as possible.”

9.2 Delete “For all Agency projects” and insert “For all Department projects” Delete “HA Projects?” and insert “Department Projects?”

9.2 Table 9-1

At Section Reference 7.1: Delete “departures from standard” and insert “Alternative Proposal” Delete “sought to obtain departure from standard” and insert “obtained an Alternative Proposal”

9.4 Delete “approval” and insert “review” in heading and all occurrences in the paragraph

Part 9 Appendices to Guidance for Work Instructions WI001, WI003 & WI004

A.4 Delete “departure” and insert “Alternative Proposal/Departure from Standard”

Part 10 Safety Report Template

8.1 Delete “departures” and insert “Alternative Proposals/Departures from Standards”

Part 11 Safety Plan Template

2.3 Table 2-2

In Feature 4: Delete “Departures from Standards” and insert “Alternative Proposals” Delete “Critical departures” and insert Critical Alternative Proposals”



Safety Report Template Safety Risk Working Instructions

IAN 139/11 of 266 Mar 11

PART 10: SAFETY REPORT TEMPLATE SUMMARY This document provides a Safety Report

template for Managed Motorways projects APPROVING PROCESS AND DATES AUTHOR/FURTHER INFORMATION LEAD DIRECTOR APPLIES TO Managed Motorways projects VERSION 1 STATUS (Final/Draft) Final THIS DOCUMENT REPLACES None – New Document DISTRIBUTION Intranet REVIEW DUE DATE tbc





IAN 139/11 of 266 Mar 11

Contents Executive summary 227 2 Introduction 228 2.1 Background to the Project 228 2.2 Document Objective 228 2.3 Document Scope 228 2.4 Assumptions 228 2.5 Contents of this Report 228 3 Individual Measures 229 4 Scenario Appraisal 234 4.1 Transitions between Operational Regimes 234 5 Safety Objectives 235 5.1 Safety Objectives for Road Users and Road Workers 235 5.2 Safety Baseline 235 5.3 Methodology for Achieving Safety Objectives 235 5.4 Evidence that Safety Objectives have been/will be Achieved 235 5.5 Status of Scheme Verification 235 6 Safety Management System: Evidence a Robust System Followed 236 6.1 Robust Project Safety Management Process in Place 236 6.2 Robust Approval Process in Place 236 7 Hazard Risk Management: Identification and Management of Project-Specific

Hazards 237 7.1 Capture and Management of Scheme Hazards in Hazard Log 237 7.2 Identification and Analysis of Scheme Specific Hazards 237 7.3 Management and Closure of Safety Related Tasks 237 7.4 Identification and Tracing of Safety Requirements and Restrictions to Hazards 237 7.5 Evidence that Safety Requirements and Restrictions met by Design 237 8 Project Practice: Methods and Processes been followed during the Project 238 8.1 Design Compatibility with Standards and Regulations 238 8.2 Use of Good Practice during the Project 238 9 Conclusions 239 9.1 General Conclusions 239 9.2 Outstanding Key Actions 239 9.3 Items for Further Consideration 239 10 References 240 11 Glossary of Terms and Abbreviations 241 12 Appendices 242




IAN 139/11 of 266 Mar 11

1 EXECUTIVE SUMMARY

1.1 Introduction [This section to include in outline the details of the scheme, i.e. material from section 2] 1.2 Safety Objectives [Summary of section 4.1] 1.3 Conclusions [States to what degree the safety objectives have been met, either through theoretical calculation or measurement, depending on the project phase to which the safety report relates. It therefore draws on section 8] 1.4 Recommendations [Identifies any further actions that could further enhance the safety of the scheme and which are considered to be reasonable]




IAN 139/11 of 266 Mar 11

2 INTRODUCTION

2.1 Background to the Project [This section should include details of the scheme to be implemented, why it is required and what purpose it is intended to serve. It is strongly recommended that the reader becomes familiar with the ‘Managed Motorways Generic Safety Review’, document reference 718471/DOC/201, before attempting to develop this safety report template any further] 2.2 Document Objective [Objectives of the safety report, which should include: To summarise the evidence in relation to demonstrating achievement of safety objectives To provide evidence of compliance with the requirements of the Highways Agency

Project Safety Risk Management System (PSRMS)] 2.3 Document Scope [Covers the stage of the project and the degree of approval that is being requested.] Note that safety reports are expected to be generated at a number of points in the scheme lifecycle, several of which will be before operation begins. Typically, the following can be expected, although whether each is necessary is a project specific consideration: Outline Design/Preliminary Design Detailed Design As built Final, incorporating monitoring results from a period of operation 2.4 Assumptions [State here assumptions that are relevant to the Safety Report] 2.5 Contents of this Report [State here the sections of the report and what purpose they serve]




IAN 139/11 of 266 Mar 11

3 INDIVIDUAL MEASURES [This section to consider the individual measures that are available as part of managed motorways and identify those that are applicable to the scheme. This section should therefore in effect be the design features description. Options are listed in the table below along with their key features and the main hazards that affect them. If necessary include a map of the scheme showing which interventions are applicable at each location]




IAN 139/11 of 266 Mar 11

MM element Overview Hazards Safety benefits Non-Managed Motorway

No overhead gantries or MIDAS installed. Normal motorway hazards such as speeding (in particular high speed differentials), lane changes, collisions at the end of traffic queues and stopping on the hard shoulder.

Triple Package (TP)

TP comprises of three key elements: Motorway Incident Detection and Automatic Signalling (MIDAS) Advanced Motorway Indicators (AMI), i.e. signals Fibre optic cable TP was implemented to provide protection for traffic queues from approaching vehicles. This algorithm detects queuing or slow-moving traffic and protects this traffic by automatically setting lower speed limits of 40mph, with 60mph and 50mph settings further upstream to provide drivers with advance warning of the queues. The system can also include automatic setting of the Enhanced Message Signs (EMS) to provide drivers with information about the reasons for the signal settings such as ‘QUEUE AHEAD’ and ‘QUEUE CAUTION’. The signs are mounted on cantilevers, gantries or, on older systems, on posts in the central reserve. The posted speed limits are advisory only.

Normal motorway hazards such as speeding, lane changes and stopping on the hard shoulder.

TP addresses and looks to protect against one of the main motorway hazards, traffic queues and collisions due to lack of driver awareness and high differential speeds. 13 – 18i% reduction in the number of injury accidents above non-managed motorways has been reported.

Controlled Motorway (CM)

Smooth’s vehicle speeds progressively to minimise the risk of flow breakdown, creating a safer, ‘better’ environment, and therefore maximising the motorway’s potential throughput. CM is defined as Triple Package with Variable Mandatory Speed Limits (VMSL) set above each lane using gantry signalling plus the “Controlled Motorway” algorithm for congestion management. The CM system uses traffic data from TP and applies the “Controlled Motorway” algorithm to establish variable, mandatory, speed limits. AMIs displaying the VMSL are linked to speed enforcement cameras mounted on the overhead gantries.

CM addresses a number of typical motorway hazards. However accidents with vehicles stopped on the hard shoulder are not directly addressed.

The Variable Mandatory Speed Limits (and enforcement of the speed limits) help to improve compliance with speed limits leading to a safety benefit. CM reduces the differential speed between vehicles and the need to change lanes. CM & MIDAS/HIOCC implemented simultaneously has been calculated to delivers a reduction in safety risk of 26ii – 30xii% reduction on a non-managed motorway section. CM installed where MIDAS/HIOCC is already in place delivers an estimated further 15ii% reduction in the safety risk over TP (note at 95% confidence interval range of safety risk reduction ranged from a 31% reduction in collisions to a 6% increase).




IAN 139/11 of 266 Mar 11

MM element Overview Hazards Safety benefits Dynamic use of the Hard Shoulder (DHS)

Provides an additional running lane through the utilisation of the hard shoulder during periods of high vehicle flow. Guidance developed for the implementation of Dynamic use of the Hard Shoulder assumes its incorporation with Controlled Motorways (DHS [incorporating CM]). This element can be summarised as follows: Periods of low traffic flow, and no incidents, no signs or signals

are displayed Increasing traffic flows triggers VMSL to be automatically

displayed above the running lanes, unlike CM, a ‘Red-cross lane control’ aspect is displayed over hard shoulder

When traffic flows are predicted to require, and when it is safe to do so, the hard shoulder is opened to traffic by control room operators through the display of a mandatory speed limit above the hard shoulder, in addition to those displayed over the remaining running lanes, and appropriate text messages are shown on the display panels (MS4s)

When the demand level subsides, the hard shoulder is closed to traffic and the motorway reverts to the Controlled Motorway style environment with mandatory speed limits displayed above the running lanes and a ‘Red-Cross lane control’ aspect displayed above the hard shoulder

As traffic flows reduce, the signs and signals are automatically switched off and the carriageway returns to normal motorway operation

The introduction of DHS (incorporating CM) leads to substantial changes in operational practices, implementation of technology and changes to infrastructure. Use of and exiting from Emergency Refuge Areas (ERAs) during DHS operation. Collision with stopped vehicle on hard shoulder when opening or open. Hard shoulder obstructed by object during opening. Compliance with operating regime, e.g. speed restrictions, opening/closing. Carriageway design and operation – Existing line markings and studs will need to be replaced, specific hazard of motorcyclists crossing rumble strip, changes to lane widths, drainage system adopted.

Early indications from M42 CM-DHS pilot show that this is a safe, efficient and sustainable way of creating increased capacity within the existing road space to manage changing traffic conditions. ERAs provide a key mitigation for the operation of the hard shoulder as a running lane. They provide a place of safety for road users in the event of an emergency. The operation of the DHS means that running speed is restricted to a maximum of 60mph when the Hard Shoulder is open to traffic. This reduces the frequency and also likely severity of any collision. The system has also been shown to achieve a high level of compliance with the variable mandatory speed limits.




IAN 139/11 of 266 Mar 11

MM element Overview Hazards Safety benefits Dynamic use of Hard Shoulder (DHS) Continued

To manage the DHS environment and the process for opening and closing the Hard Shoulder, signals and message signs are mounted on gantries. ERAs are provided at approximately the same intervals (nominally ~ 800m spacing), generally co-located downstream of the gantry where the topography and road layout permits. Over each lane, an Advanced Motorway Indicator (AMI) displays VMSL and lane control aspects. Each gantry is equipped with a Variable Message Sign to provide driver information and reinforce the aspects set on the AMIs. Good compliance to the VMSL is supported through the use of an appropriate speed enforcement system (e.g. HADECS). CM provides the detection system for monitoring traffic speeds, flows and queues. Comprehensive PTZ coverage is provided to allow the control room operators to monitor the road network and rapidly detect and respond to incidents. Additionally there is a comprehensive fixed Closed Circuit TV (CCTV) system which monitors the status of the hard shoulder in order to be able to assess its ‘ready to run’ status.

Through Junction Running (TJR)

Opening of the hard shoulder within the junction to enable traffic approaching on the opened hard shoulder (DHS) to have the option of either exiting the motorway or continuing through the junction on the hard shoulder (LBS1). TJR should ideally only be implemented where both upstream and downstream sides of the junction have actively managed hard shoulders. A number of different scenarios have been developed and reviewed to understand the hazards, potential mitigation measure and safety level achievable. Note – this operating regime has never been implemented on the HA network.

The majority of changes to risk scores from TJR are associated with the increase in lengths of hard shoulder running introduced through the opening of the hard shoulder inside of junctions. Items relevant to the delivery of safety on TJR are: The treatments at the diverge and

merge nosing The length of the merge and diverge Driver confusion Unsafe lane changing Sudden weaving at exit Vehicle enters main carriageway

unsafely

No quantitative data is available for the impact of TJR on safety level achievable. The conclusion of the TJR safety review is that TJR solutions can be made to operate effectively from a safety perspective. If the design of a standard 60 mph merge/diverge can be accommodated within a TJR scheme, there should be limited/no additional risk to the DHS element, as long as road markings are clear and unambiguous. The safety review also concluded that the majority of the changes in risk scores are associated with the increase in lengths of hard shoulder running that are introduced through TJR.

Access Management (AM)

Intended to provide improved traffic flow benefits on the motorway through managing flow of on-slip traffic merging. Comprises of the installation of ramp metering and/or ramp management on the on-slips.

Interaction with possible DHS. Queues on on-slip backing up on to local road network. Differential speed between feeder traffic and motorway traffic.

The safety risk from the implementation of ramp metering is expected to be about the same as the current level of risk.




IAN 139/11 of 266 Mar 11

MM element Overview Hazards Safety benefits Hard Shoulder Incident Management (HSIM)

Within the context of this report HSIM refers to HSIM utilising AMIs. The actual operating procedure is under continual development and refinement. The following overview assumes that the implementation of HSIM using AMIs will require a TOS on scene before the hard shoulder is opened. The use of AMI equipped gantries to facilitate the management and flow of motorway traffic by the opening of the hard shoulder for incident management. In this report it has been assumed that the use of AMIs as part of HSIM can only be activated under the instruction of the TOS at the scene, and not initiated remotely from the RCC.

No additional hazards beyond existing HSIM hazards where AMIs are not currently used.

Some safety benefit is likely to be delivered through having AMIs supporting the incident management practices put in place by the on scene Traffic Officer.




IAN 139/11 of 266 Mar 11

4 SCENARIO APPRAISAL

[This section considers which options are relevant for scheme in question and the impact of these options. The applicable options should have been identified in the previous section, and in this section the impact of these options is considered in relation to safety objectives]

Figure 4-1 Options Flow Chart

The options flow chart illustrates that there are a number of possible Managed Motorway configurations: Scenario 1: TP Scenario 2: TP & CM Scenario 3: TP & CM & DHS Scenario 4: TP & CM & DHS & TJR Access Management can be applied to all of the above options. HSIM can be applied to Scenarios 2, 3 & 4. [It is expected that the options applicable to the scheme under consideration will be analysed in order to determine an appropriate safety objective for the scheme. Material to support for this analysis is available from the managed motorways generic safety case, which gives guidance as to the safety benefits that can be expected from each of the options identified above] 4.1 Transitions between Operational Regimes [In this section look at the transition issues that affect this scheme, given the options that are relevant. An example may be transiting from an area of CM to one where DHS also operates. At the simplest level, an MM scheme will have only the entry and exit boundaries. More complex schemes, with several different operating regimes, will need a more detailed consideration]




IAN 139/11 of 266 Mar 11

5 SAFETY OBJECTIVES

5.1 Safety Objectives for Road Users and Road Workers [Summarises the different objectives for road users and road workers. Make reference to supporting PSRMS documentation. Note that the safety objective will largely be set based on the analysis in section 3.1] [In general there will not be an objective for other third parties (such as public living in the vicinity of the road) but there may be a need to state that third party related hazards will be considered and mitigated appropriately] 5.2 Safety Baseline [State the safety baseline on which the road user safety objective is based. Note that the baseline will be largely derived from the analysis in section 3.1] 5.3 Methodology for Achieving Safety Objectives [Summary of approach as applicable and safety management approach] 5.4 Evidence that Safety Objectives have been/will be Achieved [Evidence of meeting Safety objective, expected to be through calculation (for Road Users). Provide evidence to support application of ALARP for Road Workers] 5.5 Status of Scheme Verification [Summarises activities completed and those outstanding. Note that as safety reports are produced at different stages of the lifecycle it is important to be clear as to what has been done for each report]




IAN 139/11 of 266 Mar 11

6 SAFETY MANAGEMENT SYSTEM: EVIDENCE A ROBUST SYSTEM FOLLOWED

6.1 Robust Project Safety Management Process in Place [Reference should be made here to the Project Safety Risk Management (PSRM) Work Instructions, showing that they have been applied and hence that an appropriate Safety Management System (SMS) has been selected. Particular reference will therefore need to be made to Work Instruction 001, which covers the selection of an SMS] 6.2 Robust Approval Process in Place [Again make reference to the PSRM Work Instructions, noting how the required approval process will be fulfilled]




IAN 139/11 of 266 Mar 11

7 HAZARD RISK MANAGEMENT: IDENTIFICATION AND MANAGEMENT OF PROJECT-SPECIFIC HAZARDS

7.1 Capture and Management of Scheme Hazards in Hazard Log [Expect to make reference here to the hazard log management tool and the fact that the scheme is based on the Managed Motorways hazard log template] 7.2 Identification and Analysis of Scheme Specific Hazards [Summary of project specific risk assessment activities] 7.3 Management and Closure of Safety Related Tasks [Provide details of the safety organisation of the project and the closure mechanism for safety actions, which will generally be tracked via the hazard log] 7.4 Identification and Tracing of Safety Requirements and Restrictions to Hazards [Safety requirements should be tracked via the hazard log] 7.5 Evidence that Safety Requirements and Restrictions met by Design [Summary of status of hazards in the hazard log, providing information as to whether sufficient mitigations have been applied to each hazard]




IAN 139/11 of 266 Mar 11

8 PROJECT PRACTICE: METHODS AND PROCESSES BEEN FOLLOWED DURING THE PROJECT

8.1 Design Compatibility with Standards and Regulations [Reference to any departures and the fact that these have been managed appropriately] 8.2 Use of Good Practice during the Project [Make reference to more general project controls being in place, such as document management, change control procedures, communications processes and other processes that essentially relate to quality control]




IAN 139/11 of 266 Mar 11

9 CONCLUSIONS

9.1 General Conclusions [The main conclusions to be entered here are: Whether or not the safety objective for road users has been/will be achieved Whether or not the safety objective for road workers has been/will be achieved] 9.2 Outstanding Key Actions [These are the items that need to be completed in order to show that the safety objective will be achieved. Having outstanding actions does not necessarily mean that the scheme cannot become operational but a justification will be needed as to why operation can commence with the action still incomplete] 9.3 Items for Further Consideration [Any issues that would benefit from further investigation should be listed here]




IAN 139/11 of 266 Mar 11

10 REFERENCES [Please list all references in this section]

[4] [5] [6] [7] [8]




IAN 139/11 of 266 Mar 11

11 GLOSSARY OF TERMS AND ABBREVIATIONS

[Amend the table below as required]

Acronym Description

AMI Advanced Motorway Indicators ATM Active Traffic Management CCTV Closed Circuit Television CM Controlled Motorway DFT Department for Transport DHS Dynamic use of the Hard Shoulder DM Demand Management DS Differential Speed ERA Emergency Refuge Area GALE Globally At Least Equivalent HA Highways Agency HADECS Highways Agency Digital Enforcement Camera System HGV Heavy Goods Vehicle HIOCC High Occupancy HSIM Hard Shoulder used for Incident Management KSI Killed and Serious Injury LBS Lane Below Signal MAC Managing Agent Contractor MIDAS Motorway Incident Detection and Automatic Signalling

MM Managed Motorway OGC Office of Government Commerce ORR On-Road Resource PIA Personal Injury Accidents RCC Regional Control Centre SLT Single Lane Tolling SSD Stopping Sight Distance SSR Safety and Standards Research Directorate TechMAC Technology Managing Agent Contractor TJR Through Junction Running TO (Highways Agency) Traffic Officers (on-road) TP Triple Package VSL Variable Speed Limits VMSL Variable Mandatory Speed Limits 4L 4-Lane




IAN 139/11 of 266 Mar 11

12 APPENDICES

[To include items such as: GSN diagrams Further details on safety requirements or key hazards Terms/definitions]



Safety Plan Template Safety Risk Working Instructions

IAN 139/11 of 266 Mar 11

PART 11: SAFETY PLAN TEMPLATE SUMMARY Safety Plan template for Managed

Motorways Projects APPROVING PROCESS AND DATES AUTHOR/FURTHER INFORMATION LEAD DIRECTOR APPLIES TO All Managed Motorways Projects VERSION 1.0 STATUS (Final/Draft) THIS DOCUMENT REPLACES DISTRIBUTION REVIEW DUE DATE TBD





IAN 139/11 of 266 Mar 11

Contents Executive summary 245 1 Introduction 246 1.1 Background 246 1.2 Document Objective 246 1.3 Document Scope 246 1.4 Document Structure 246 2 Safety Management System Selection 247 2.1 Process of Selecting a Safety Management System 247 2.2 Reviewing the Project Scope 247 2.3 Categorisation of Project Features 247 2.4 Implications for BBATM12 Project Safety Management System 249 3 Safety Lifecycle Activities 250 3.1 Safety Acceptance and Approvals Process 250 3.2 Define Safety Baseline and Objectives 250 3.3 Develop a Safety Plan 250 3.4 Risk Assessment Activities 250 3.5 Hazard Log Production 250 3.6 Achievement of Safety Objectives 250 3.7 Safety Report 250 4 Programme Management and Control 251 4.1 Management of Sub-Consultants 251 4.2 Configuration Control 251 5 Key Project Safety Roles 252 Appendix A 253




IAN 139/11 of 266 Mar 11

EXECUTIVE SUMMARY

[Give brief background to project. The text below may be modified to suit project requirements] This document is the Project Safety Plan. Its objectives are to: Define how the project safety objectives will be achieved Describe the Safety Management System (SMS) and corresponding safety activities that

will be undertaken in order to achieve those objectives, including a description of the activities that have been carried out to date

Describe how the SMS has been selected Describes the project organisation, how responsibility for safety activities has been

devolved and the associated programme management and control processes The application of this document will produce evidence to demonstrate that [project name] is capable of being operated in an acceptably safe manner.




IAN 139/11 of 266 Mar 11

1 INTRODUCTION

1.1 Background [Provide information as to what project is and why it is being undertaken. It is strongly recommended that the reader becomes familiar with the ‘Managed Motorways Generic Safety Review’, document reference 718471/DOC/201, before attempting to develop this safety plan template any further] 1.2 Document Objective [Modify sample text below as required] The objectives of this document are to: Define how the project safety objectives will be achieved Describe the Safety Management System (SMS) and corresponding safety activities that

will be undertaken in order to achieve those objectives, including a description of the activities that have been carried out to date

Describe how the SMS has been selected Describes the project organisation, how responsibility for safety activities has been

devolved and the associated programme management and control processes The application of this document will produce evidence to demonstrate that [project name] is capable of being operated in an acceptably safe manner. 1.3 Document Scope This document is applicable to all of the project lifecycle stages of [project name] including operations and decommissioning. The document will evolve as the project progresses, with more detail being added as more information becomes available. [Indicate which version of the report this is and whether it is addressing any particular phases of the project lifecycle] 1.4 Document Structure [State here the sections of the report and what purpose they serve]




IAN 139/11 of 266 Mar 11

2 SAFETY MANAGEMENT SYSTEM SELECTION

2.1 Process of Selecting a Safety Management System [Make reference to Project Safety Risk Management Work Instruction 001 and note that it is through applying this Work Instruction that a Safety Management System (SMS) is selected. Note also the directive in the associated CHE memo for Managed Motorway projects] 2.2 Reviewing the Project Scope [Either summarise project scope or make reference to a document where it is described] 2.3 Categorisation of Project Features [Typical material to be included is provided in the remainder of this section. Table 2 will require marking up to show which Types are chosen for each feature]

Feature Implications for [project name]

Stakeholder interest

Operational experience

Technology

Standards and legislation

Impact on Organisation

Project Scale

Table 2-1 Project Features

These features are interpreted by WI001 as requiring differing levels of safety management. The safety activities relate to the feature types as follows: Type A: Basic safety management needs to be applied. Note that even in this case, a

record shall be kept as to how the decision was reached, justifying the level of safety evidence that is to be recorded

Type B: A moderate level of safety management needs to be applied. Some kind of Safety Report will be needed and some level of risk assessment will need to be carried out

Type C: Rigorous safety management shall be applied. Records shall be kept of all activities undertaken, all decisions and their justifications shall be recorded and extensive risk assessment shall be carried out

The feature categorisation for [project name] is given in Table 2-2.




IAN 139/11 of 266 Mar 11


– Stakeholders – Influence


Several Limited


Many Limited

or

Key Significant



Widespread UK

Limited UK

or

Some Overseas only





application


– Safety risk implications Low Medium High 4. Standards and Legislation

– Design covered by existing standards

– Departures from standards – Changes to legislation

All None None

Mostly Some None

No Many None

or

New standard Critical departures

Yes



No changes

Minor changes/responsibility transfer

Significant change or responsibility transfer

6. Project Scale – Infrastructure affected – Potential for wider roll-out




Table 2-2 Project Feature Classification [this table to be completed by circling or highlighting appropriate fields]




IAN 139/11 of 266 Mar 11

2.4 Implications for [Project name] Safety Management System [Summarise here the categorisation of the project. The default for Managed Motorway projects will be a ‘Type B’ SMS]




IAN 139/11 of 266 Mar 11

3 SAFETY LIFECYCLE ACTIVITIES

[This section provides a description of the safety management activities that are to be undertaken. It should be possible to identify these from the relevant Project Safety Risk Management Work Instruction. The accompanying deliverables should also be identified] 3.1 Safety Acceptance and Approvals Process [Provide a definition of the Safety Acceptance and Approvals Process] 3.2 Define Safety Baseline and Objectives 3.2.1 Safety Baseline [Please refer to the Managed Motorways Generic Safety Review, document reference 718471/DOC/201] 3.2.2 Safety Objectives [Please refer to the Managed Motorways Generic Safety Review, document reference 718471/DOC/201] 3.3 Develop a Safety Plan [Make reference to this document and any future versions that may be planned] 3.4 Risk Assessment Activities [Describe the main risk assessment activities that will be undertaken] 3.5 Hazard Log Production [Note that for Managed Motorways projects a partly populated hazard log will be provided] 3.6 Achievement of Safety Objectives [Described how the achievement of safety objectives will be shown] 3.7 Safety Report [Describe what the Safety Report will show and when it will be produced. Note that a Managed Motorways project will produce difference versions of the Safety Report as the project progresses. Reference to the separate versions should be included here.]




IAN 139/11 of 266 Mar 11

4 PROGRAMME MANAGEMENT AND CONTROL

4.1 Management of Sub-Consultants [Identify relevant processes and procedures] 4.2 Configuration Control [Identify relevant processes and procedures]




IAN 139/11 of 266 Mar 11

5 KEY PROJECT SAFETY ROLES

The key safety roles currently specified are listed below. [Provide a list of the key safety roles. These should include the person who is the project Safety Manager i.e. has responsibility for managing delivery of safety activities, any safety specialists involved and those responsible for safety approval. It is normal practice on such projects to form a review committee to check and approve safety work before it is submitted for any wider approval]




IAN 139/11 of 266 Mar 11

APPENDIX A

[To include items such as terms/definitions or other information that is most appropriately provided in an appendix]




IAN 139/11 of 266 Mar 11

PART 12: HAZARD LOG REPORT TEMPLATE

SUMMARY Hazard Log Report template for Managed

Motorways Projects APPROVING PROCESS AND DATES AUTHOR/FURTHER INFORMATION LEAD DIRECTOR APPLIES TO All Managed Motorways Projects VERSION 2.0 STATUS (Final/Draft) THIS DOCUMENT REPLACES DISTRIBUTION REVIEW DUE DATE TBD





IAN 139/11 of 266 Mar 11


(Insert title of attached Project Safety Deliverable, document reference, version, status design, construction,


This approvals process shall also apply to any changes introduced to project safety documentation after operation has commenced. This is to ensure appropriate consideration and approval for the safety implications of any changes across all aspects of the project. In this situation, the ‘MP Project Manager’ and ‘Major Projects


Name ____________

Date _____________

Signature _____________

Project Consultant

(Project Director)

I confirm that:



Name ____________

Date _____________

Signature _____________






Name ____________

Date _____________

Signature _____________



Name ____________

Date _____________

Signature _____________



Name ____________

Date _____________

Signature _____________

Network Services





Name ____________

Date _____________


Major Projects







IAN 139/11 of 266 Mar 11

Contents Executive summary 257 1 Introduction 258 2 Initial Hazard Log Scoring 259 2.1 Initial Population of the Hazard Log 259 2.2 Assumptions 259 2.3 Key Hazards 259 3 Hazard Log Actions 261 3.1 High scoring hazards 261 3.2 Hazards related to specific populations 261 3.3 SME Peer Review 261 3.4 Outstanding Actions 261 4 Future Hazard Log Activities 261 Appendix A: Hazards 262 Appendix B: High Scoring Hazards 263 Appendix C: Specific Population Hazards 264 Appendix D: Scoring Parameters And Indices 265




IAN 139/11 of 266 Mar 11

EXECUTIVE SUMMARY

Introduction Include text along the lines of the following: This Hazard Log Report has been produced for the <<Scheme Title>> MM scheme, to

support the PCF requirements. Its purpose is to provide documentary evidence that the relevant Hazards have been

identified and categorised. It presents a review of the process including peer review by SME, used for identifying

hazards and populating the hazard log. High scoring hazards (i.e. those with the greatest level of risk) have been identified Hazards related to specific populations have been identified (eg: on road resources /

maintenance workers) Key mitigations, tasks and requirements have been identified to manage the key

hazards. Conclusions State progress towards achieving the scheme safety objective. Recommendations If required, identify any further actions that could further enhance the achievement of the scheme safety objective.




IAN 139/11 of 266 Mar 11

1 INTRODUCTION <<include text similar to the following>> This short report has been produced to accompany the Hazard Log for the scheme title MM scheme, to support PCF requirements. This report contains the following: A description of the procedure followed to populate the scores for each

hazard A list of the assumptions that underpin the hazard analysis A list of the high scoring hazards, i.e. those that have been identified as

having the greatest risk associated with them Where necessary additional information on the risk assessment process Information on the work that has taken place to mitigate the risks identified A list of outstanding actions for consideration during subsequent PCF

stages.




IAN 139/11 of 266 Mar 11

2 INITIAL HAZARD LOG SCORING

2.1 Initial Population of the Hazard Log

<< Insert general information on the initial population of the hazard log. Include information on the approach taken (e.g. risk assessments), risk assessment support documents, data collection and preliminary calculations>>

2.2 Assumptions <<Insert a list of the assumptions that are used in the hazard log. An example of the type of table that could be inserted is shown below. >> ID Name Value Units Notes

A2 Average duration a vehicle will limp down LBS2 when LBS1 is closed

24 Seconds In the absence of further data, a value of 24 seconds has been used based on an assumed distance travelled (200m) and an assumed speed (20mph)

A3 Average duration an illegal pedestrian present per occurrence

60 minutes In the absence of further data, a value of 60 minutes has been assumed

A4 Average Duration for a Breakdown

50 Minutes Typical value obtained from TRL data (report PR/TT/072/99 "Safety on Hard Shoulders on M25")

2.3 Key Hazards

<<Insert text similar to the following>> The scoring exercise and the Hazard Log structure enabled the safety team to target the required further safety appraisal at those issues that pose the greatest risk and where further action will likely have the greatest safety impact. The key hazards were considered to be those: o with a ‘before’ or ‘after’ risk score of 7 or more; or o those associated with maintenance activities and On Road Resource. A list of all the Hazards with descriptions is presented in Appendix ‘A’. The ‘Before’ and ‘After’ scores associated with hazards with risk scores of 7 or more are presented in Appendix ‘B’ The ‘Before’ and ‘After’ scores associated with all hazards that are associated with Specific Populations7 <<state here what they are>> are presented in Appendix ‘C’ The parameters that make up each risk score is presented in Appendix ‘D’. In summary: o Insert number of the insert number hazards scored are considered to be

high scoring hazards. o There were insert number hazards related to Specific Populations <<state

here what they are and the number of hazards related to each>>

7 Specific Populations are to include as a minimum ‘On Road Resources/Maintenance Workers’ and

‘Pedestrians/Motorcyclists’. Other populations should be presented if they have particular relevance

to the scheme.




IAN 139/11 of 266 Mar 11

o Anti-log calculations show that the total score for ‘after’ represents a insert percentage change in risk when compared to the’ before’ situation.”

<< for the last item, state how the scheme is expected to perform in relation to the scheme safety objective. This can be placed either above or below the following text>>

Despite the use of numbers, the risk score is at best semi-quantitative and does not provide an absolute measure of risk, even approximately. The methodology is designed to place each hazard into one of a number of bands, so that it can be seen clearly which hazards are considered to present the greatest risk. This approach also facilitates the calculation of risk changes that a project brings about, thus enabling an assessment to be made as to whether a project has achieved its safety objective. In order to complete such an assessment, each hazard must be reviewed and the impact that the project has on its score considered. By adding together the impact of all such risk changes, the overall change in risk that the project brings is calculated. However, the use of semi-quantitative approach means that undue weight should not be placed on the quoted change in risk as it is only indicative of the change in risk for the scheme as a whole.




IAN 139/11 of 266 Mar 11

3 HAZARD LOG ACTIONS

3.1 High scoring hazards

<< state the identified mitigations that are to be used to manage the key hazards. State also any tasks and requirements that have been identified. >>

Hazard ID

Comments (Mitigations, Tasks and Requirements)

3.2 Hazards related to specific populations

<< state the mitigations that are to be used to manage specific populations. State also any tasks and requirements that have been identified. (Information for each specific population should be presented in a separate sub section e.g. “3.2.1 On Road Resources/Maintenance Workers”, “3.2.2 Pedestrians/Motorcyclists’” etc) >>

Hazard ID

Comments (Mitigations, Tasks and Requirements)

3.3 SME Peer Review

<<The Hazard Log should be reviewed by the Peer Review SME Group for consistency. The outcome discussed shall be recorded in the report.>>

3.4 Outstanding Actions <If relevant, Insert text similar to the following> At the time of writing there are a number of actions that are ongoing. Where an action has been progressed as far as feasible by the scheme designers and further work is required by either the contractor or the operator then this task has been converted to a requirement. On completion of the work required this requirement can be marked as complete and the necessary changes made to the risk score for the associated hazards.

4 FUTURE HAZARD LOG ACTIVITIES <If relevant, Insert text similar to the following> This report has been prepared at the conclusion of PCF Stage insert number, in insert date. Further reviews of the hazard log and the Hazard log report will be conducted in accordance with PCF guidance.




IAN 139/11 of 266 Mar 11

Appendix A: Hazards <<Insert hazards information/table from hazard log identifying all the hazards. An example is presented below>>

Id Name Description Class Type

H1 Abnormal loads -

escortable

An abnormal load (one that requires an escort) travels along the

motorway.

Traffic Conditions

EVENT

H2 Abnormal loads –

notifiable

A notifiable abnormal load is one that is beyond a certain size, but

does not require escorting by Police (or TO).

Traffic Conditions

EVENT

H3 Aborting or pausing

LBS1 opening sequence half-way

This hazard considers what happens if the operator detects an obstruction

whilst opening LBS1 and must pause the opening sequence.

Operation EVENT

H4

Blanking of signals on one gantry when LBS1 open to traffic

indicates sudden local closure of LBS1

This is a failure specific to one gantry within a section that has

LBS1 operational. So preceding and following gantries still show LBS1 as in operation. It also refers specifically

to failures that cause blanking.

Failure STATE




IAN 139/11 of 266 Mar 11

Appendix B: High Scoring Hazards

<<Insert scoring details/table from Hazard log. Below is an example of what can be inserted>>

ID Hazard Name Risk Score Before Risk Score After

H129

Vehicle stops in running lane E9.0 E8.5

H19 Drivers assume they can use

LBS1 on rest of network E0.0 E7.0

H128

Vehicle stops in LBS1 when LBS1 open

E0.0 E7.0

H1 Abnormal loads - escortable E5.0 E7.0




IAN 139/11 of 266 Mar 11

Appendix C: Specific Population Hazards

<<Insert scoring details/table from Hazard log for each specific population. Below are examples of what can be inserted. Note: these example tables are not intended to show all the hazards affecting each population. >> On Road Resources/Maintenance Workers


H22 Emergency staff /TO etc on foot

at scene of an incident E6.0 E7.5

H34 Incident management - rolling

block E5.0 E5.0

H82 Short duration stops / debris

removal by TO / maintenance workers

E6.0 E5.5

H94 TO arrives, but has difficulty

containing the scene E5.0 E4.5

Pedestrians/Motorcyclists


H48 Legal/Illegal pedestrian(s) in path

of vehicles in ERA E0.0 E6.0

H67 Pedestrian in running lane: live

traffic E8.0 E7.5

H68 Pedestrian on slip road S7.0 S6.5

H59 Motorcyclist falls off crossing line

on entry to ERA E0.0 E5.5




IAN 139/11 of 266 Mar 11

Appendix D: Scoring Parameters And Indices <<Insert tables similar to the following>>

Hazard scores are calculated as follows:

Event Frequency indices (Likelihood Score)

Frequency Classification Nominal Value: Occurrences/year mile Very frequent 1,000 316 Frequent 100 31.6 Probable 10 3.16 Occasional 1 0.316 Remote 0.1 0.0316 Improbable 0.01 0.00316 Incredible 0.001




IAN 139/11 of 266 Mar 11

State Frequency indices (Frequency Score) Likelihood Classification

Interpretation

Very frequent At least 1 occurrence present at anyone time per motorway mile. Present 115 days per year per motorway mile

Frequent Present 36.5 days per year per motorway mile Present 115 days per year per motorway mile Probable Present 3.65 days per year per motorway mile

Present 1.15 days per year per motorway mile Occasional Present 9 hours per year per motorway mile Present 3 hours per year per motorway mile Remote Present 50 minutes per year per motorway mile Present 15 minutes per year per motorway mile Improbable Present 5 minutes per year per motorway mile Present 90 seconds per year per motorway mile Incredible Present 30 seconds per year per motorway mile

Collision Indices (Rate/probability that hazard lead to an accident)

Severity Indices (severity of accident score)

Severity Classification

Interpretation Index Value

Severe The proportion of collisions that are fatal is expected to be higher than average by at least a factor of 10

2.0

Higher than average The proportion of fatal collisions is expected to be higher than average by a factor between 3 and 10

1.5

Average The distribution of collisions (i.e. ratio of damage-only to fatal) is expected to be similar to the motorway average

1.0

Lower than average The proportion of fatal collisions is expected to be lower than average by a factor between 3 and 10

0.5

Minor The proportion of collisions that are fatal is expected to be lower than average by at least a factor of 10

0.0

Classification Events Value States If this hazard occurs then: This hazard, if present, will: Certain A collision is certain 4 Definitely causes a collision Probable A collision is probable 3 Frequently causes a collision Occasional A collision will occasionally

happen 2 Occasionally causes a collision

Remote There is a remote chance of a collision

1 Infrequently causes a collision

Improbable A collision is improbable 0 Rarely causes a collision

IAN 139/11 - Department for Transport

Documents

Transcript of IAN 139/11 - Department for Transport