Safety Management

SMP01 Project Safety Initiation

In ‘Project Safety Initiation’ we look at what you need to do to get your safety project or program started.



stakeholder is anyone who will be affected by the introduction of the system and who needs to be consulted or informed about the development and fielding of the system, and anyone who contributes to the ultimate acceptance of the project.

We will look at the RACI chart of stakeholders under a later SMP.

Top Tip

Project Safety Initiation: Objectives

This procedure describes the start-up of safety management activities on a project. It identifies safety stakeholders and legislative and other standards that need to be satisfied. The procedure also creates the key elements of the safety management organization for the project.

In normal circumstances, this procedure would be applied at the outset of a project, early in the Concept phase. However, it can be applied at any point of the life cycle where it is necessary to initiate a formal safety management process on an existing system. The procedure may also be re-applied at significant points in the life cycle (e.g. after Full Business Case approval), to review and update the project safety arrangements and ensure that they continue to be appropriate.

Remember that a Project delivers on a specific:

a) Outcome, result or benefits, e.g. meeting requirements;

b) Schedule; and

c) Quality criteria, e.g. needed to realise benefits.

Top Tip

This procedure assumes that the Program Director has already been appointed, and that clearly defined safety responsibilities have been formally delegated to a suitably safety-competent individual within the Delivery Team.  

Although this is written as a safety procedure, it is recognized that at this early stage the safety and environmental processes are very similar and may be carried out together. Where appropriate, the same formats and tools are recommended for stakeholder and legislative requirements to provide a single consistent basis for subsequent safety and environmental activities. These tools are described here for completeness. It is also recognized that in many projects, the roles of Project Safety and Environment Manager may be combined, and a single Project Safety and Environmental Committee may exist.

The purpose of Safety Initiation is to ensure that the safety management process is commenced on a firm basis by identifying basic information, interfaces, and responsibilities. These include:

  1. Stakeholders (including industry);
  2. Regulators and Approval Authorities;
  3. Project Safety Manager;
  4. Independent Safety Auditor if appropriate;
  5. Project Safety Committee;
  6. Project Safety Responsible, Accountable, Consulted, Informed (RACI) Chart;
  7. Enterprise internal safety regulator/audit group.

All applicable factors need to be lined up to ensure the success of a safety project or program.

Top Tip

Project Safety Initiation: Procedure

Stakeholder Identification

A stakeholder is anyone who will be affected by the introduction of the system and who needs to be consulted or informed about the development and fielding of the system, and anyone who contributes to the ultimate acceptance of the project. This may include individuals or groups that:

  1. Have safety responsibilities at any stage of the project;
  2. Have safety requirements (including information) from the project;
  3. Hold safety information relevant to the project (e.g. other Delivery Teams with interfacing or sub-systems);
  4. Have specialist or operational knowledge that can aid the project in achieving safety requirements.

As a minimum, the following will be consulted:

  1. Project Sponsor (e.g. the Director of the End Users’ Business Unit);
  2. Equipment end user;
  3. Technical Director;
  4. Other Delivery Teams involved in any sub-systems of the project;
  5. Other Delivery Teams involved with systems, projects or systems platforms with which the system/project will be closely associated;
  6. Subject Matter Experts with specialist technical or professional expertise in a subject area relevant to the Project;
  7. Relevant Enterprise internal safety regulator/audit group (via Questionnaire Form SMP01/F/01 – Safety Operating Environment Questionnaire).

When stakeholders have been identified, their contact details and involvement in the project will be recorded in form SMP01/F/02 – Register of Stakeholder Requirements and Information.

Initially, stakeholders identified and consulted at this stage will be restricted to the Enterprise. However, any relevant external stakeholders identified e.g. (other) government departments, industry, research organizations, regulatory bodies, etc., should be logged and included in a communication plan, which identifies when they should be consulted, by whom, and for what purpose. The Project may choose to include external stakeholders at this stage.

Note that for projects that involve a high number of stakeholders, consideration will be given to developing a project communication plan that includes contact details, information requirements, lines of communication, responsibilities, and any relevant security considerations.

It may be helpful to rename the project communication plan the Project Stakeholder Management Plan – what do you need from stakeholders for your Project to succeed?

Top Tip

Identify Applicable Legislation, Standards, and Requirements

The identification of relevant legislation at the start of any project is essential so that any conditions for compliance can be incorporated into the acquisition process. Project Safety Manager (PSMs) will identify and maintain a register of applicable legislation as part of the development of the Safety Case, and continuously review it and revise it as necessary.

This is the initial identification of potentially applicable safety standards and requirements (including legislation, policy, and best practice standards) that may apply to the project over its lifetime. The Register of Safety Legislation and Other Significant Requirements (see Form SMP01/F/03 – Register of Safety Legislation and Other Significant Requirements) will be used to list and document these standards for each of the life cycle stages. A separate sheet should be used for each standard identified.

Within the Enterprise, each project’s Legislative Register should be taken to include matters of Government or policy and international treaty obligations. 

Note that this will be an evolving process through several stages of the project. The Preliminary Hazard Identification and Analysis procedure (Procedure SMP04 – Preliminary Hazard Identification and Analysis) will identify additional requirements, to be consolidated into the safety requirements (see procedure SMP10 – Safety Requirements and Contracts).

Useful information sources include:

  1. Other equipment safety standards;
  2. Other relevant legislation and standards for operations in other legal jurisdictions.

For more information on this vital task, see the post on System Requirements Hazard Analysis here.

Top Tip

Create Project Safety Organization

Ultimately, the project safety management organization will be defined in the Safety Management Plan (SMP) (Procedure SMP03 – Safety Planning). However, in advance of the preparation of this document, it is necessary to set up key elements of the safety management organization, as follows:

  1. Appoint competent PSM;
  2. Appoint Independent Safety Auditor (ISA), if required;
  3. Form Project Safety Committee (PSC) (membership and role defined in Procedure SMP02 – Safety Committee);
  4. Produce high level definition of other project safety responsibilities, in the form of an initial project RACI (Responsible, Accountable, Consulted, Informed) chart for the safety management process defined for this stage of the project.

Appointment of an ISA is advisable for projects that are complex, novel, or assessed as having high levels of safety risk. The appointment of an ISA may also be mandated by domain-specific requirements or standards. 


The organization uses a number of methods of enabling compliance:

  1. Delivery Teams develop System Specifications to meet User Concept Document statements from the Project Sponsor. This is an important method for advising industry of the Enterprise’s safety and environmental requirements;
  2. The Through Life Management Plan incorporates the impact of safety and environmental legislation on the relevant equipment both now and in the future (The Project Safety and Environmental Management Plans are integral parts of the Through Life Management Plan);
  3. Use of Enterprise guidance in the development of contracts and contract conditions.

Where the Delivery Team also develops the User Concept Document on behalf of the Project Sponsor, it is extremely important that these reflect the Enterprise safety and environmental performance objectives and targets, recognizing and emphasizing any politically or publicly sensitive issues. The advice of organizational Subject Matter Experts in Safety, Sustainable Development & Continuity must be sought in the construction of the User Concept Document.

Although reference to Enterprise guidance provides the Enterprise with some protection, any Invitation to Tender must explicitly describe the project’s requirements for safety and environmental management.  In addition, compliance and performance requirements, resulting from the User Concept Document and System Specification and the project’s Safety Management Plan.

Access to information about safety and environmental legislation is enabled via a number of organizations and media – the following provides some primary examples:

  1. Legislative Registers held by the Program Teams;
  2. Defence Regulator intranet pages, Enterprise’s Safety net etc;
  3. Websites and publications of the Health & Safety Executive, Professional Societies and of lawyers or consultancies specialising in providing information and knowledge of safety and environmental matters and current affairs;
  4. Suppliers, contractors and consultants;
  5. Other projects and Delivery Teams.

Identification of and compliance with all relevant safety and environmental legalization will always ultimately be the responsibility of the Delivery Team member with delegated authority for safety and environmental protection.

Since safety and environmental legislation is continuously evolving, Delivery Teams are strongly recommended to seek expert advice on new requirements that might be likely to come into force during the project life cycle.

The wider Enterprise may maintain a list of approved specialist contractors as part of a Framework Agreement for Technical Services enabling arrangement (AKA a list of approved suppliers). This maps suppliers’ capabilities against a range of safety and environmental management areas, enabling Delivery Teams to select contractors with the necessary levels of experience and expertise for specific tasks.

Membership of the framework agreement is open to companies of all sizes and is secured by qualification against pre-determined criteria, rather than by competition. All members are subject to the same terms and conditions throughout the duration of the framework agreement.

Records and Project Documentation

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

  1. System Specification – 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 submissions.

In addition, as the competence of the PSM is relevant to the safety assurance on the project, the evidence should be retained from the selection process to verify the appointed individual is competent to perform the required responsibilities.

Warnings and Potential Project Risks

If Delivery Teams fail to carry out this procedure in a timely manner, there will be delays in engaging stakeholders, recognizing legislative or other requirements, or creating the safety organization. This will inevitably result in risks to project costs and timescales.

If the project fails to co-ordinate the treatment of stakeholders and legislative requirements between the safety and environmental management system, there is a risk that there will be inconsistent communication to stakeholders and duplication or omission of requirements (e.g. falling between the two).

The legislative and other requirements register will not be read across from one project to another, even if they are similar in scope, without a detailed review.

The competence of PSMs and ISAs is critical to the safety success of the project. It is important that this competence should be assured, and that records demonstrating that this has been done should be retained. If this is not done it will be difficult to demonstrate that safety and environmental responsibilities have been discharged correctly.

Procedure Completion

The PSM will identify the legislation, regulators, and approval authorities that the project will need to satisfy, and any requirements for independent safety certification.

The PSM will maintain a legislative register as an integral part of the Safety Case for each project.

The internal and external auditors should check for legal and policy compliance as part of their assessment of the Safety Management System (SMS), Safety Management Plan (SMP), and Safety Case.  It should be noted that responsibility for compliance still rests with those with delegated responsibility rather than with the auditor.

Project Safety Initiation: Timing

Initial Application

In an acquisition program, the procedure should be carried out early in the Concept phase.  Stakeholders, system boundaries, supporting systems/arrangements, and acceptance authorities need to be identified as early as possible to support the subsequent Preliminary Hazard Identification activity (Procedure SMP04 – Preliminary Hazard Identification) and the preparation of the SMP.

The procedure can be applied at any point of the life cycle where it is necessary to initiate a formal safety management process.


The registers of stakeholders and requirements should be reviewed and updated after Outline Business Case and Full Business Case as part of the review and update of the SMP.

New Safety Managers could also use this as a take-over checklist, to make sure all necessary decisions have been made and clearly documented.

Top Tip

Project Safety Initiation: Required Inputs

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

  1. User Concept Documentation (for Acquisition Programmes);
  2. Any other information on the proposed functionality, use, support and context of the proposed system;
  3. Existing Hazard Logs for existing similar systems;
  4. Relevant Enterprise Policy.

Project Safety Initiation: Required Outputs

The Outputs of the procedure will comprise:

  1. Appointed PSM and ISA, if appropriate;
  2. Completed Form SMP01/F/01 – Safety Operating Environment Questionnaire;
  3. Completed Form SMP01/F/02 – Register of Stakeholder Requirements and Information, which should be reviewed and updated as the project proceeds;
  4. Completed Form SMP01/F/03 – Register of Safety Legislation and Other Significant Requirements, which should be reviewed and updated as the project proceeds.

The Delivery Team should consider addressing legislation and similar issues amongst standardization issues especially when producing and reviewing the standardization strategy and implementation plan. These issues occur throughout the life of the project which the Delivery Team controls. These also occur when updating the project standards database, and project Safety Initiation documents SMP01/F/03 with changes in legislation and international agreements.

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 Initiation: How would you kick off your Safety Program?

Leave a Reply

Your email address will not be published.