Categories
Safety Management

SMP02 Project Safety Committee

Our Second Safety Management Procedure is the Project Safety Committee. Okay, so committees are not the sexiest subject, but we need to get stakeholders together to make things happen!

Project Safety Committee: Introduction

Definitions

Safety Committee is defined as:

A group of stakeholders that exercises, oversees, reviews and endorses safety management and safety engineering activities.

Def Stan 00-56

Objectives

The key elements for the effective management and delivery of safety are coordination, agreement, and proper response by those authorities with responsibilities for the equipment. 

The PSC brings together those with safety management responsibilities and other stakeholders with relevant specific knowledge, authority, or Subject Matter Expertise. It, therefore:

  1. Provides a forum through which all those with safety responsibilities can ensure effective co-ordination on safety issues;
  2. Provides access for decision-makers to all those with relevant knowledge;
  3. Provides competent oversight of the Safety Case during its development and upkeep;
  4. Provides, through records of its meetings, an audit trail showing that suitable advice has been sought and that safety management decisions were well-founded.

The Enterprise PSC may be supported by Panels, Sub-Committees, or Working Groups with the appropriate level of Subject Matter Expertise and defined Terms of Reference to address specific safety issues.

Although contractors will be members of the Enterprise PSC, they may also need to form and chair their own Safety Committee. Typically this might be necessary on more complex projects where there are multiple sub-contractors. Enterprise will be represented on the Contractor’s Safety Committee to ensure that there is an adequate understanding of the in-service environment and the user’s needs. If there are both Enterprise and Contractor Safety Committees, then they must each have clear Terms of Reference, and their inter-relationship must be well defined.

In Australia, it is a legal requirement for those with safety responsibilities (Duty Holders) to consult, coordinate and cooperate with others. Other countries may use different terms for similar requirements. The bottom line is that it’s a good idea!

Top Tip

Project Safety Committee: Procedure

Membership

The PSC should include representatives, as appropriate, from the following areas:

  1. The Delivery Team (including the Project Safety Manager, and other technical, contracts, and finance officers as required);
  2. Integrated Logistics Support teams;
  3. Equipment support teams;
  4. Customer representatives (project sponsor);
  5. User representatives (Equipment End User);
  6. Trials team;
  7. Maintenance specialists;
  8. Training Authorities;
  9. Prime contractor;
  10. Design organization;
  11. Independent Safety Auditor (if appointed);
  12. Specialist advisors (e.g. from Enterprise, certification authority, or industry safety consultants);
  13. Enterprise Safety Authority; and
  14. Enterprise Safety and Environmental Protection Group.

Other representatives that may be required to participate should include contractors, consultants, subject matter experts, safety sustainable development & continuity, operators, users, and maintainers of the equipment. These should also include reliability and quality managers, (other government departments or representatives of other nation-states governments or departments – for public sector projects.)

However, don’t invite anybody and everybody ‘just in case’, as this devalues the PSC and its work.

Top Tip

More information on PSC membership has been provided at Annex A – example Terms of Reference for a PSC. Further advice is available from QSEP.

Chair

The Committee(s) should be chaired by the safety-competent individual holding formally-delegated responsibility for safety within the Project.  A Letter of Delegation may detail the scope of the delegation holders’ responsibility and authority to carry out the safety management tasks on that program.

Quorum

In order for a PSC to make decisions concerning the safety of a capability or equipment, it should be declared quorate at the beginning of the meeting. In order for a PSC to be declared quorate, the following SQEP and authorized members should be in attendance:

  • Delivery Team safety delegation holder
  • Project Safety Manager
  • Design organization
  • Customer representative (Project Sponsor)
  • Safety Case author

The quorate for a PSC can be expanded depending on the nature of the project. Details should be provided in the Project Safety Management Plan (SMP) or Terms of Reference.

If there are insufficient attendees for the PSC to be declared quorate, the meeting can still proceed with decisions being noted and only implemented once an agreement has been received from the quorum ex-committee. 

This is a good point. PSCs don’t always meet frequently, and getting some members to attend can be challenging. Nevertheless, it is important to keep moving forwards.

Top Tip

Meeting Frequency and Mechanisms

The PSC may meet regularly as a body, or its work may be included as a permanent item in another forum (in this instance care should be taken that all relevant parties are included), or simply through written communications. The key principles are to ensure that all relevant authorities are consulted, actions are agreed upon and properly allocated, and a record is kept of proceedings. A PSC can either be established for a single type of equipment, or a family of variants of equipment.

Smaller projects may choose to integrate the PSC activities with other meetings. As a minimum, the discussion of safety issues should remain a unique item on meeting agendas.

Working Level Support

Depending on the complexity of the project, one or more working groups may be established that support the PSC by assessing hazards or reviewing the integrity of specific systems. Integrity working groups could consider structure, propulsion or other electrical or mechanical systems, reporting significant issues to the PSC.

Safety Management Committee

Where a number of similar equipment are managed in a single Delivery Team, consideration should be given to establishing a top-level Safety Management Committee (SMC) to set out and agree on the safety management policy and strategy for those projects. The strategy would detail the formation of PSCs for individual equipment, or groups of similar equipment e.g. radio systems, or support vehicles rather than a type of radio or vehicle.

The SMC will monitor and control the activities of the individual PSCs, which will operate in accordance with their own SMPs. Structures can be tailored to suit individual circumstances. Terms of Reference, including membership, for an SMC, should be similar to that of a PSC. The safety management policy and strategy for those projects will be recorded in a Safety Management System document, similar to an SMP. Figure 2.1 shows an example of a Safety Committee structure, together with the management documents that sit at the relevant committee level.

Figure 2.1 – Safety Committee Structure

Safety Committee Structure

Figure 2.1 represents an example of a Safety Committee structure, with supporting working groups and hazard reviews in place. Teams can modify the structure of the Safety Committees to suit the specific organization of the program. The emphasis should be on establishing a Safety Committee with suitable chairmanship and Terms of Reference.

The structure shown in Figure 2.1 would be suitable for a large Program managing several important projects. However, it is probably overkill for most projects. With committees, less is sometimes more.

Top Tip

Project Safety Committee Authority and Competence

The chairman of the PSC should hold a Letter of Delegation detailing the authority for carrying out the safety management tasks on that program.

The PSC exists to provide information and specialist advice to those who have specific responsibility for safety management on an acquisition project so that they can reach informed decisions. The Project safety delegation holder is required to seek and consider relevant advice through the PSC but remains the decision-maker.

Whilst not all members of the PSC need to have specific competence and experience in Safety Management, it is essential that some committee members do have this competence and are consulted.  In addition to the safety delegation holder, whose competence must be established prior to their delegation being issued, other members of the PSC who must be safety competent would typically include the Project Safety Manager and the Independent Safety Auditor (if appointed).

As a minimum, the Project Safety Manager should have system safety competence at the practitioner level.  Competence requirements for the safety delegation holder will be defined in a relevant Assignment Specification.

The level of competence needed is driven by many factors – size, complexity, novelty – and this will be discussed under a post on ‘Proportionality’ (TBD).

Top Tip

Where it is considered beneficial, a combined committee may be established for the safety and environmental management activities. It should be ensured that the programs are aligned as far as possible and that data is shared where relevant.

It is suggested that where there are separate safety and environmental committees, these meet consecutively over the morning and afternoon – with membership and specialists attending as appropriate to each.

The PSC may cover groups of similar projects within a Delivery Team where common activities are required, although separate committees are envisaged for very large, high risk or diverse projects within a Delivery Team.

The PSC may meet regularly as a body, or its work may be included as a permanent item in another forum (in this instance care should be taken that all relevant parties are included), or simply through written communications. This last option is less desirable because there is no opportunity for direct interaction.

Records and Project Documentation

The records from this procedure will consist of PSC meeting minutes which should record the following:

  1. Those present;
  2. The discussions;
  3. Advice given;
  4. Decisions made;
  5. Recommendations to those with delegated authority for safety management; and
  6. Actions agreed.

Where relevant, the outputs from this procedure will feed into the following:

  1. System Requirements Document – for any specific safety requirements;
  2. Customer Supplier Agreement – to document agreements on safety information to be delivered by the Delivery Team;
  3. Through Life Management Plan;
  4. Safety elements of Outline Business Case and Full Business Case submissions.

Review and Agreement of Safety Documents

The role of the PSC includes reviewing safety documents and advising the safety delegation holder on their suitability. The agreement that the document is suitable can be signified in various ways and the Project Director should define, which is required. Methods for recording the review and its findings could include:

  1. Formal sign off of the document by all members of the PSC;
  2. A recommendation, recorded in PSC minutes, that the document is satisfactory and can be authorized for release by the agreed signatory.

Warnings and Potential Project Risks

If the PSC is not established early in the acquisition life cycle, then some of the stakeholders involved may not be identified and their needs may not be addressed adequately in the development of the safety requirements or the production of the SMP. This could also occur if the PSC is established with an incomplete membership.

If the PSC does not review and approve the safety tasks described in the SMP, then the activities may be inappropriate to deliver the required levels of safety performance and safety assurance.

If the PSC does not review and approve the Safety Management System described in the SMP, then they may not identify areas of disagreement concerning responsibilities for safety.

Beware of the PSC delving into detail and doing what is expedient, rather than was is needed. Set appropriate TORs and agendas and stick to them.

Tip Top

If the PSC does not meet with sufficient frequency, then they may not identify in a timely manner, any issues with the safety program. This could result in impacts on project time and cost.

If the PSC attempts to control the detailed design solutions, rather than relying on the contractor’s Safety Committee and design function, then Enterprise will take responsibility from the designer. Enterprise staff will be represented on the contractor’s Safety Committee and shall exercise influence at that forum and through setting appropriate requirements.

Procedure Completion

Delivery Teams will complete the procedure, in conjunction with advice and information from members of the PSC.

Project Safety Committee: Timing

Formation

The PSC should be established during the Concept phase of a project by the Customer, or Requirements Manager, through the Capability Working Group, in conjunction with the relevant Project Director, to set out the safety requirements for the equipment.

The PSC has an important role to play in influencing safety requirements. This is not mentioned in ‘PSC: Required Outputs’, below, but is possibly the PSC’s most important contribution.

Top Tip

Meetings

The required frequency of the PSC meetings depends on various factors including the stage of the project, the complexity of the system, and whether the PSC is supported by Working Groups or has complete responsibility.  Meetings will be required at greater frequency during periods of significant review and decision making, typically when project milestones are approaching.

PSC meetings may occur less frequently during periods of stability, such as during the in-service phase, when fewer safety decisions are necessary.  However, the PSC still has an important duty to provide oversight of the Safety Case and ensure that it remains valid and monitoring safety performance.  This will include considering whether the system or its usage is changing and seeking counter-evidence that shows the predicted level of safety performance is not being achieved in practice.

Project Safety Committee: Required Inputs

The procedure may use the following reference inputs, as available:

  1. Outputs from procedure SMP01 – Safety Initiation;
  2. Documents to be reviewed such as:
    1. Project Safety Management Plan;
    2. Independent Safety Auditor Audit Plan (if appointed);
    3. Independent Safety Auditor Audit Report (if appointed);
    4. Other Safety Audit Plans (e.g. self or Peer audit);
    5. Safety Audit Report;
    6. Hazard Log Report;
    7. Safety Requirements;
    8. Safety Assessment Report;
    9. Safety Case Report.
  3. Acquisition System Guidance Functional Competencies for System Safety Management;
  4. Records of previous meetings of the Safety Committee.

Project Safety Committee: Required Outputs

The outputs of the procedure will comprise:

  1. Established Safety Committee membership;
  2. Defined Terms of Reference for the Safety Committee (see Further Guidance – Examples Terms of Reference for Project Safety Committee);
  3. Records of Safety Committee meetings, including advice given and the actions, agreed;
  4. The advice given by members of the Safety Committee should include recommendations on whether a reviewed document (e.g. Safety Management Plan or Safety Case Report) should be authorized by the Project Director. If authorization is not recommended, then the reasons should be recorded.

Annex A

Example Terms of Reference for Project Safety Committee

Terms of Reference for – Project XXXX

Purpose:

To provide a forum for monitoring and coordinating all safety management and risk reduction activities associated with the project to ensure effective levels of safety and provide an appraisal of the Safety Case. The Project Safety Committee reports to the Project Director or in a larger Delivery Team to the Safety Management Committee.

Tasks:

  1. To set and keep under review the project’s safety policy and strategy;
  2. To set and keep under review the project’s safety targets and objectives;
  3. To define the system boundaries for safety responsibility;
  4. To advise the Chairperson of the Safety Committee on the safety responsibilities of each authority associated with the project;
  5. To advise the Chairperson of the Safety Committee on the standards, statutory regulations, and any restrictions with which the projects should comply;
  6. To review, monitor, classify and allocate new equipment hazards as they are identified;
  7. To carry out reviews of the project’s Safety Case and progress on achieving safety targets, to a predetermined program, issuing the results to the Delegated Authority;
  8. To agree on any control measures that are deemed necessary to reduce identified risks to ALARP;
  9. To ensure proper and timely availability of training and issue of documentation;
  10. To carry out actions from ISA, regulatory or internal audit findings;
  11. To operate a system for reviewing and monitoring safety performance and maintain the Safety Case.

Membership:

  1. Delivery Team responsible for the procurement aspects of the project;
  2. Customer representative (Capability or Equipment Customer);
  3. Safety Officer (if appointed);
  4. Design organization;
  5. Delivery Team responsible for the support aspects of the project;
  6. Equipment User;
  7. Training Authority;
  8. Maintainer;
  9. Maintenance Authority;
  10. Specialist Advisors (as required):
    1. Defense Safety Regulators;
    2. Defense Ordnance Safety Group;
    3. Land Accident Prevention and Investigation Team;
    4. Military Aviation Accident Investigation Team;
    5. Serious Equipment Failure Investigation Team;
    6. Independent Safety Auditor;
    7. Interfacing Delivery Teams;
    8. Technical Specialists.

Acknowledgment of Copyright

In this article, I have used material from a UK Ministry of Defence guide, reproduced under the terms of the UK’s Open Government Licence.

Project Safety Committee: Who would You Include?

Leave a Reply

Your email address will not be published.