Printer-friendly version
PDF version2.1. Introduction
2.1.1. Definitions
2.1.1.1.
A Safety Committee is defined in Def Stan 00-056 as:
“A group of stakeholders that exercises, oversees, reviews and endorses safety management and safety engineering activities.”
2.1.2. Objectives
2.1.2.1.
The key elements for the effective management and delivery of safety are co-ordination, agreement and proper response by those authorities with responsibilities for the equipment.
2.1.2.2.
The PSC brings together those with safety management responsibilities and other stakeholders with relevant specific knowledge, authority or Subject Matter Expertise. It therefore:
- Provides a forum through which all those with safety responsibilities can ensure effective co-ordination on safety issues;
- Provides access for decision makers to all those with relevant knowledge;
- Provides competent oversight of the Safety Case during its development and upkeep;
- Provides, through records of its meetings, an audit trail showing that suitable advice has been sought and that safety management decisions were well founded.
2.1.2.3.
The MOD 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.
2.1.2.4.
Although contractors will be members of the MOD 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. MOD 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 MOD and Contractor Safety Committees, then they must each have clear Terms of Reference and their inter-relationship must be well defined.
2.2. Procedure
2.2.1. Membership
2.2.1.1.
The PSC should include representatives, as appropriate, from the following areas:
- The Delivery Team (including the Project Safety Manager, and other technical, contracts and finance officers as required);
- Integrated Logistics Support teams;
- Equipment support teams;
- Customer representatives (Capability or Equipment Customer);
- User representatives (Equipment User);
- Trials team;
- Maintenance specialists;
- Training Authorities;
- Prime contractor;
- Design organisation;
- Independent Safety Auditor (if appointed);
- Specialist advisors (e.g. from MOD, certification authority or industry safety consultants);
- Defence Safety Authority.
- DE&S Safety and Environmental Protection Group
2.2.1.2.
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 defence departments.
2.2.1.3.
More information on PSC membership has been provided at Annex A - example Terms of Reference for a PSC. Further advice is available from QSEP.
2.2.2. Chair
2.2.2.1.
The Committee(s) should be chaired by the safety-competent individual holding formally-delegated responsibility for safety within the Project. The Letter of Delegation will detail the scope of the delegation-holder's responsibility and authority to carry out the safety management tasks on that programme.
2.2.3. Quorum
2.2.3.1.
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 authorised members should be in attendance:
- Delivery Team safety delegation holder
- Project Safety Manager
- Design organisation
- Customer representative (Capability or Equipment Customer)
- Safety Case author
2.2.3.2.
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.
2.2.3.3.
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 agreement has been received from the quorum ex-committee.
2.2.4. Meeting Frequency and Mechanisms
2.2.4.1.
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 and properly allocated, and a record is kept of proceedings. A PSC can either be established for a single equipment, or a family of variants of an equipment.
2.2.4.2.
Smaller projects may choose to integrate the PSC activities with other meetings. As a minimum the discussion of safety issues should remain as a unique item on meeting agendas.
2.2.5. Working Level Support
2.2.5.1.
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.
2.2.6. Safety Management Committee
2.2.6.1.
Where a number of similar equipments 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 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.
2.2.6.2.
The SMC will monitor and control the activities of the individual PSCs, which will operate to their own SMP's. Structures can be tailored to suit individual circumstances. Terms of Reference, including membership, for a 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 a SMP. Figure 2.1 shows an example of a Safety Committee structure, together with the management documents that sit at the relevant committee level.
2.2.6.3.
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 organisation of the programme. The emphasis should be on establishing a Safety Committee with suitable chairmanship and Terms of Reference.
2.2.7. Project Safety Committee Authority and Competence
2.2.7.1.
The chairman of the PSC should hold a Letter of Delegation detailing the authority for carrying out the safety management tasks on that programme.
2.2.7.2.
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.
2.2.7.3.
Whilst not all members of the PSC need have specific competence and experience in Safety Management, it is essential that some committee members do have this competence and are consulted with. 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).
2.2.7.4.
As a minimum, the Project Safety Manager should have system safety competence to practitioner level. Competence requirements for the safety delegation holder will be defined in a relevant Assignment Specification.
2.2.7.5.
Where it is considered beneficial, a combined committee may be established for the safety and environmental management activities. It should be ensured that the programmes are aligned as far as possible and that data is shared where relevant.
2.2.7.6.
It is suggested that where there are separate safety and environmental committees, these meet consecutlively over a morning and afternoon – with membership and specialists attending as appropriate to each.
2.2.7.7.
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.
2.2.7.8.
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.
2.2.7.9.
The Ordnance Safety Review Panel (OSRP), Release To Service and Naval Authority Certification procedures are activities that are carried out independent of the PSC. The PSC may include updates from such assurance activities.
2.2.8. Records and Project Documentation
2.2.8.1.
The records from this procedure will consist of PSC meeting minutes which should record the following:
- Those present;
- The discussions;
- Advice given;
- Decisions made;
- Recommendations to those with delegated authority for safety management;
- Actions agreed.
2.2.8.2.
Where relevant, the outputs from this procedure will feed into the following:
- System Requirements Document – for any specific safety requirements;
- Customer Supplier Agreement – to document agreements on safety information to be delivered by the Delivery Team;
- Through Life Management Plan;
- Safety elements of Outline Business Case and Full Business Case submissions.
2.2.9. Review and Agreement of Safety Documents
2.2.9.1.
The role of the PSC includes reviewing safety documents and advising the safety delegation holder on their suitability. Agreement that the document is suitable can be signified in various ways and the Team Leader should define which is required. Methods for recording the review and its findings could include:
- Formal sign off of the document by all members of the PSC;
- A recommendation, recorded in PSC minutes, that the document is satisfactory and can be authorised for release by the agreed signatory.
2.2.10. Warnings and Potential Project Risks
2.2.10.1.
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.
2.2.10.2.
If the PSC do 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.
2.2.10.3.
If the PSC do not review and approve the Safety Management System described in the SMP, then they may not identify areas of disagreement concerning responsibilities for safety.
2.2.10.4.
If the PSC do not meet with sufficient frequency, then they may not identify in a timely manner, any issues with the safety programme. This could result in impacts on project time and cost.
2.2.10.5.
If the PSC attempts to control the detail design solutions, rather than relying on the contractor’s Safety Committee and design function, then MOD will take responsibility from the designer. MOD staff will be represented on the contractor’s Safety Committee and shall exercise influence at that forum and through setting appropriate requirements.
2.2.11. Procedure Completion
2.2.11.1.
Delivery Teams will complete the procedure, in conjunction with advice and information from members of the PSC.
2.3. Timing
2.3.1. Formation
2.3.1.1.
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 Team Leader, to set out the safety requirements for the equipment.
2.3.2. Meetings
2.3.2.1.
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.
2.3.2.2.
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.
2.4. Required Inputs
2.4.0.1.
The procedure may use the following reference inputs, as available:
- Outputs from procedure SMP01 – Safety Initiation;
- Documents to be reviewed such as:
- Project Safety Management Plan;
- Independent Safety Auditor Audit Plan (if appointed);
- Independent Safety Auditor Audit Report (if appointed);
- Other Safety Audit Plans (e.g. self or Peer audit);
- Safety Audit Report;
- Hazard Log Report;
- Safety Requirements;
- Safety Assessment Report;
- Safety Case Report.
- Acquisition System Guidance Functional Competencies for System Safety Management (SYSSAF 1);
- Records of previous meetings of the Safety Committee.
2.5. Required Outputs
2.5.0.1.
The outputs of the procedure will comprise:
- Established Safety Committee membership;
- Defined Terms of Reference for the Safety Committee (see Further Guidance – Examples Terms of Reference for Project Safety Committee);
- Records of Safety Committee meetings, including advice given and actions agreed;
- 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 authorised by the Team Leader. If authorisation is not recommended, then the reasons should be recorded.
2.6. Annex A
2.6.1. Example Terms of Reference for Project Safety Committee
2.6.1.1.
Terms of Reference for – Project XXXX
2.6.1.2.
Purpose:
To provide a forum for monitoring and co-ordinating 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 Team Leader or in a larger Delivery Team to the Safety Management Committee.
2.6.1.3.
Tasks:
- To set and keep under review the project’s safety policy and strategy;
- To set and keep under review the project’s safety targets and objectives;
- To define the system boundaries for safety responsibility;
- To advise the Chairperson of the Safety Committee on the safety responsibilities for each authority associated with the project;
- To advise the Chairperson of the Safety Committee on the standards, statutory regulations and any restrictions with which the projects should comply;
- To review, monitor, classify and allocate new equipment hazards as they are identified;
- To carry out reviews of the project’s Safety Case and progress on achieving safety targets, to a predetermined programme, issuing the results to the Delegated Authority;
- To agree any control measures that are deemed necessary to reduce identified risks to ALARP;
- To ensure proper and timely availability of training and issue of documentation;
- To carry out actions from ISA, regulatory or internal audit findings;
- To operate a system for reviewing and monitoring safety performance and maintain the Safety Case.
2.6.1.4.
Membership:
- Delivery Team responsible for the procurement aspects of the project;
- Customer representative (Capability or Equipment Customer);
- Safety Officer (if appointed);
- Design organisation;
- Delivery Team responsible for the support aspects of the project;
- Equipment User;
- Training Authority;
- Maintainer;
- Maintenance Authority;
- Specialist Advisors (as required):
- Defence Safety Regulators;
- Defence Ordnance Safety Group;
- Land Accident Prevention and Investigation Team;
- Military Aviation Accident Investigation Team;
- Serious Equipment Failure Investigation Team;
- Independent Safety Auditor;
- Interfacing Delivery Teams;
- Technical Specialists.
2.7. Version Control
2.7.1. Version 2.3 to 3.0 uplift
2.7.1.1.
Major uplift from the Acquisition System Guidance (ASG) to online version.
2.7.2. Version 3.0 to 3.1 uplift
2.7.2.1.
Minor changes implemented, including clarity of Safety Committee structures. A minor uplift to correct spelling, grammar, and to remove some duplication of text
2.7.3. Version 3.1 to 4.0 uplift
2.7.3.1.
Major reorganisation of all SMPs:
- Restructure into a consistent format.
- Responsibilities, Alignment with Environment and guidance for different acquisition strategies have been removed and included in the POSMS summary.
- All further guidance has been placed into the Procedure section, and duplicated text has been removed
- Annex A has been created for the PSC Terms of Reference template.
2.7.4. Version 4.0 to 4.1 Uplift
2.7.4.1.
Minor text changes to align with ASP taxonomy.
2.7.5. Version 4.1 to 4.2 Uplift
2.7.5.1.
Text change replacing Project Team with Delivery Team.
2.7.6. Version 4.2 to 4.3 Uplift
2.7.6.1.
Minor amendment to replace reference to Initial Gate and Main Gate and change these to Strategic Outline case, Outline Business Case and Full Business Case. This change brings terminology in line with JSP 655.
