Air Force System Safety Handbook - System Safety Society

After using the checklist, there are some hints that may be
helpful in selecting Tasks. For the customer, it is often better
to time safety analyses deliverables based upon significant
program milestones (like a preliminary design review) than to
specify a certain number of days after contract award. This
allows greater flexibility in case the design schedule changes.
Whenever practical, consider requesting an update to an
existing report instead of a whole new report. This can be a
cost saver. If uncertainties exist in design which make a
difference in what analysis is requested (ex. unsure if flight
controls will be fly-by-wire or mechanical), leave the option to
decide after the program has progressed. An example would
be to add to the statement of work to perform fault tree
analysis on a set number of topics mutually agreed upon at
the system safety working group. Contractors should be
particularly careful with contracts that require many analyses
but few deliverables. It is especially important to keep an
orderly backup file of all information that was used to support
the deliverables. This file should be made available to the
customer for review. This checklist can form part of a
substantiation for additional budget or could surface areas for
renegotiating or trading of tasks. Both customer and contractor
can go beyond just identifying the particular MIL-STD-882
tasks.
4.7 Abuses. (16:C-1 to C-2)
Various abuses to the process are noteworthy, such as boilerplate,
smorgasbord, invisible, and cutup tailoring.
The boilerplate utilizes verbiage that has been used numerous
times before. It references the original MIL-STD-882, not the
current version. Defenders of this method claim it is “proven
effective” and has “management approval.” New start
programs should use the latest version. It may be valuable as
a method of time savings to utilize similar requirements from
previous similar programs; however, it is often used for all
programs regardless of similarities.
The smorgasbord contains practically everything in MIL-STD--
882. Many times, there is a long list of tasks with only a few
deliverables. The theory behind this is if a little bit of 882 is
good to have, a lot must be better. This burdens the contractor
to programs; however, it is often used for all programs regardless
of similarities.
The smorgasbord contains practically everything in MIL-STD--
882. Many times, there is a long list of tasks with only a few
deliverables. The theory behind this is if a little bit of 882 is
good to have, a lot must be better. This burdens the
contractor to produce a lot of programs; however, it is often
used for all programs regardless of similarities.
The smorgasbord contains practically everything in MIL-STD--
882. Many times, there is a long list of tasks with only a few
deliverables. The theory behind this is if a little bit of 882 is
good to have, a lot must be better. This burdens the contractor
to This method suggests the customer views safety as a
spectator sport. Customer involvement is essential to
success. The application of MIL-STD-882D as a whole
document should prevent this from occurring.
Invisible tailoring of tasks is accomplished by omitting the very
last paragraph of each task. This paragraph describes what
the managing authority shall do. This is of no concern to the
contractor. So, it is as if this task were never tailored. This
misses the whole point of tailoring.
Cutup contracts are ones which bear little resemblance to the
original input by the customer’s safety department because it
37
was “revised” before final transmittal to the contractor. Unfortunately,
the contractor will have to work with the customer’s
safety department and try to satisfy their original needs without
exceeding the bounds of the actual content.
4.8 Small Programs. (33:123-132)
A major program may need most or all of the tasks in
Deskbook applied to the program. Small programs are much
different. There is a need for the further delineation of a set of
recommended procedures for conducting a small system
safety program. Such a program may be called for in such
cases as small projects (e.g., the design and fabrication of a
missile transport cart), projects with obviously minimal hazards
(e.g., development of a new mechanical typewriter), projects
that do not fit into the normal life cycle process (e.g., military
facilities design and construction) and, unfortunately, projects
for which the safety activity is dollar limited.
The following are recommended as a minimum effort in a system
safety program:
1. Prepare a preliminary hazards list (PHL).
2. Conduct a preliminary hazard analysis (PHA).
3. Assign a Risk Assessment Value for each item.
4. Assign a priority for taking the recommended action
to eliminate or control the hazards, according to the
Risk Assessment Values.
5. Evaluate the possibility of deleterious effects from
interfaces between the recommended actions and
other portions of the system.
6. Take the recommended actions to modify the
system.
7. Prepare a System Safety Assessment Report as a
wrap-up of the system safety program.
The PHL can be derived in several ways. One of these is by
the examination of the energy transfer in the system. This is
based on the concept that all losses are created by an interference
with the normal exchange of energy. The system is
examined for incorrect, untimely, or omitted energy exchanges
as a base for the PHL. There are also available hazard review
checklists in which hazards are listed, together with the usual
occurrence mode, the possible cause and the possible effects.
The PHA is the initial development of the relationships
between hazard causes (faults), effects, and recommended
actions to be taken to eliminate or control the hazards.
An in-depth hazard analysis generally follows the PHA with a
subsystem hazard analysis, a system hazard analysis, and an
operating and support hazard analysis, as appropriate, but for
a small safety program, the PHA will usually suffice as the only
formal analysis.
A comprehensive evaluation is needed of the safety risks
being assumed prior to test or evaluation of the system or at
contract completion. It identifies all safety features of the
hardware and system design and procedural hazards that may
be present in the system being acquired and specific procedural
controls and precautions that should be followed.
It is to be remembered that the hazards encountered in a
small program can be as severe and as likely to occur as
those of a major program. Usually one can expect fewer
hazards in a small program. Caution needs to be exerted to
ensure that in tailoring the system safety effort to fit a small
program, one does not perform a wholesale slashing, but