Home > White Papers > Organization and Management    s

Organization and Management

It is not enough to talk about "absolute safety" and of "zero accidents." There must also be proper organisation and management to ensure that actions live up to words.

British Department of Transport
Investigation into the Clapham
Junction Railway Accident

A sincere commitment to safety by management is the most important factor in achieving it. Top management's participation in safety issues is the most effective activity in controlling risk and reducing accidents. It shows a personal involvement, which communicates the importance of the effort to others throughout the organization. Upper management also needs to assign capable people to the system safety effort and give them appropriate objectives and resources. Appropriate organizational structures must be set up to ensure that the safety effort has the authority, as well as the responsibility, to ensures system safety. Lastly, upper management must be responsive to initiatives by others.

Managements responsibilities include setting policy and defining goals. Management must define responsibility, fix accountability, and grant authority. These three properties must be distributed so that the people responsible and accountable for system safety have the authority to affect the design and construction of the system. Communication channels must exist to collect information necessary for safety engineers to perform their tasks, and the system safety effort must be able to disseminate information in such a way as to affect the system designers.

The corporate safety policy should be a written statement of intentions, philosophy, experience, and belief that guides attainment of stated goals. The policy should clearly define the role of safety with respect to other organizational goals and provide scope of discretion, initiative, and judgment in deciding what should be done in specific situations. The policy should include:

bulletgoals of the safety program
bulletset of criteria for assessing short and long-term sucess
bulletarticulation of values to be used in trade-off decisions
bulletclear statement of responsibilities, authority, accountability, and scope of activities

The policy may be broken into two parts. The first is a concise statement of general policy and organization. The second is a more detailed document handling rules and procedures. Procedures should include means for reporting back to policy makers any problems in carrying out the safety policy. Flexibility should be allowed in procedures to respond to safety problems. Incentives and reward structures should encourage proper trade-offs between safety and other goals. Informal rules (social processes) as well as formal processes must support the safety policy. Employees need to feel that they will be supported by management when they raise safety issues.

In one organization structure, the program manager has ultimate responsibility for safety. The program manager delineates the lines of authority, cooperation, and administration for safety throughout the program organization. The system safety manager provides support and information to the program manager for decision making. The system safety manager has an organization to support these activities and appropriate authority. Independence of the safety manager from other structures of the program is important; responsibility for safety should be separated from other goals.

Communication channels must be established both for information dissemination and for feedback.

Feedback includes comparing actual performance with desired performance and ensuring action is taken. A project may require redundant channels and cross-checking at successive levels of the organization. Software and software development must be included in this communication.

The system safety organization must have a high-level, independent role in an organization. The role of the safety organization includes:

bulletParticipation in the formulation and implementation of the safety policy.
bulletDocumentation and tracking of hazards and their resolution.
bulletEducation and promotion.
bulletAdoption and development of standards.
bulletConducting and participating in hazard analysis and other system safety activities.
bulletTrend analysis and maintenance of safety documentation.
bulletPlanning and monitoring of testing and operations for safety issues.
bulletParticipation in program reviews and milestones.
bulletLiasion with other safety groups (including outside groups).
bulletAccident investigation and analysis.
bulletFacilitate communication with and among engineering groups with respect to safety activities.

System safety engineers should be trained in system engineering techniques. They should have extensive knowledge of the application or the capacity to learn quickly. A system safety engineer requires good communication skills and a knowledge of system safety engineering.

A software safety engineer should have good knowledge of both hardware and software. This engineer also needs the ability to communicate with and influence both software engineers and hardware engineers. A software safety engineer is responsible for software safety analyses and for software inputs to system safety analyses. They must participate in design reviews and sit on the configuration control board. The software safety engineer establishes and oversees the audit trails for identified software hazards. The software safety engineer should also participate in the integration tests and other activities.

In general, safety engineers should have a direct link to decision makers, independence, direct communication channels, influence on decision-making, focus, and coordination. At the corporate level, the system safety effort may define and enforce corporate safety policy. Depending on the application, the system safety engineer may be subject to independent review or certification.

At lower levels in the organization, a safety group should be located at each level, with function dependent on that level. Software safety's group should be within software engineering. An independent person would have difficulty having adequate influence on software development activities. But close coordination and communication will be needed with system safety activities.

The safety process must be tailored for each project. System and software safety plans and tasks should not be separated. The whole should be one process with subprocesses. Software development should participate in the process of defining software safety activities (to get an early buy-in). Subcontractors should develop their own safety efforts in coordination with the overall system safety plan.

Studies have ranked an effective safety information system (SIS) as second in importance only to top management concern for safety. The safety information system should contain an updated system safety program plan. It should include the status of activities and the results of hazard analyses. Additionally, the SIS should track status information on all known hazards in the system. Incident and accident information should include corrective actions taken. As this data accumulates over time, the SIS should provide trend analysis data. The three parts of the safety information system are information collection, analysis, and dissemination.

The following questions may serve as a guide to evaluating your organizations safety efforts.

  1. Do you have a corporate safety policy? Describe it.
  2. Who has responsibility for safety in your organization's projects?
  3. Is there a special system safety organization? What is its role?
  4. What are the communication channels for safety information in your organization? Who is responsible for software safety? What background must they have? What relation do they have to the system safety organization (assuming there is one)?
  5. Where is safety located in the organization? Are there different types of groups at different levels?
  6. What types of safety documentation do you have? Safety program plan? Safety reports? Safety information system?

Home Products Services Publications White Papers About Us

Copyright 2003 Safeware Engineering Corporation. All rights reserved