Preliminary Hazard Analysis

The Preliminary Hazard Analysis (PHA) is a risk tool that is used during initial design and development, thus the name “preliminary”, to identify systematic hazards that affect the intended function of the design to provide an opportunity to modify requirements that will help avoid issues in the design.

Like a fair amount of tools used in risk, the PHA was created by the US Army. ANSI/ASSP Z.590.3 “Prevention through Design, Guidelines for Addressing Occupational Hazards and Risks in Design and Redesign Processes” makes this one of the eight risk assessment tools everyone should know.

Taking the time to perform a PHA early on in the design will speed up the design process and avoid costly mistakes. Any identified hazards that cannot be avoided or eliminated are then controlled so that the risk is reduced to an acceptable level.

PHAs can also be used to examine existing systems, prioritize risk levels and select those systems requiring further study. The use of a single PHA may also be appropriate for simple, less compelx systems.

A. Identify Hazards

Like a Structured What-If, the Preliminary Hazard Analysis benefits from an established list of general categories:

by the source of risk: raw materials, environmental, equipment, usability and human factors, safety hazards, etc.
by consequence, aspects or dimensions of objectives or performance

Based on the established list, a preliminary hazard list is identified which lists the potential, significant hazards associated with a design. The purpose of the preliminary hazard list is to initially identify the most evident or worst-credible hazards that could occur in the system being designed. Such hazards may be inherent to the design or created by the interaction with other systems/environment/etc.

A team should be involved in collecting and reviewing.

B. Sequence of Events

Once the hazards are identified, the sequence of events that leads from each hazard to various hazardous situations is identified.

C. Hazardous Situation

For each sequence of events, we identify one or more hazardous situations.

D. Impact

For each hazardous situation, we identify one or more outcomes (or harms).

E. Severity and occurrence of the impact

Based on the identified outcomes/harms the severity is determined. An occurrence or probability is determined for each sequence of events that leads from the hazard to the hazardous situation to the outcome.

Based on severity and likelihood of occurrence a risk level is determined.

I tend to favor a 5×5 matrix for a PHA, though some use 3×3, and I’ve even seen 4×5.

Intended outcomes		Likelihood of Occurrence
Severity Rating	Impact to failure scale	1 Very unlikely	2 Likely	3 Possible	4 Likely	5 Very Likely
5	Complete failure	5	10	15	20	25
4	Maximum tolerable failure	4	8	12	16	20
3	Maximum anticipated failure	3	6	9	12	15
2	Minimum anticipated failure	2	4	6	8	10
1	Negligible	1	2	3	4	5
Very high risk: 15 or greater, High risk 9-14, Medium risk 5-8, Low risk 1-4

F. Risk Control Measures

Based on the risk level risk controls and developed and applied. These risk controls will help the design team create new requirements that will drive the design.

On-going risks should be evaluated for the risk register.

Flow Chart

The flow chart is a simple, but important, graphic organizer. Placing the states or steps of an event or process into the correct sequence allows you to reach conclusions and make predictions.

However, its simplicity means we don’t always work to be consistent and can benefit from a little effort to ensure users are aligned.

I am a huge fan of including flow charts in all process and procedure documents.

Steps for Building a flow chart

Capture

Capture the events or steps of the process. Resist the urge to arrange them sequentially and concentrate on capturing the events/steps only.

Cull

If there are more than eight steps in a flow chart we start creating cognitive overload. If a process or procedure has more than eight steps you need to:

Ensure the steps are at the right level, sometimes we have substeps represented and we can cull that. Ensure they are all on the same level of process/procedure/task.
Decide we need to break the procedure into multiple documents. This is a great way to decide what work instructions are necessary.
Look for opportunity for process improvement.

Sequence the events and draw the flow chart

The focus now shifts to temporal relations. The correct sequential arrangements of steps or events helps to reach conclusions about past events and prepare for future events.

Example

I’m writing the procedure for my mornings, I capture the following:

Eat breakfast
Take shower
Take dog out
Get dressed
Decide on tea
Heat water
Drink tea
Read for 30 minutes
Deal with morning email
Snuggle with dog

Taking a look at the list I realize that not everything is on the same level of process/procedure/task and end up with a shorter list.

Breakfast
Take shower
Take dog out
Get dressed
Read for 30 minutes
Deal with morning email
Snuggle with dog

Notice how I combined all the tea stuff into a breakfast category. When brainstorming my list I put a lot of weight on tea, because it is important to me (yes I have been using tea as a training example since 2005, I just love tea).

I can then put them in sequence:

When I was making things sequential I realized that two of my activities (read and dog snuggle) were concurrent, so I combined them as one step.

Using the Outcome Identification Loop

The Outcome Identification Loop asks four questions around a given outcome which can be very valuable in understanding a proposed design, event, or risk.

The four questions are:

1	Who else might this affect?	Stakeholder Question
2	What else might affect them?	Stakeholder Impact Question
3	What else might affect this?	System/analysis Design Question
4	What else might this affect?	Consequence Question?

4 questions in the Outcome Identification Loop

Through answering these questions, outcomes and relationships to further define a central question, and can be used to shape problem-solving, risk mitigation, and process improvement.

Questions 1 “Who else might this affect?’ and 2 “What else might affect them?’ are paired questions from stakeholder identification and analysis techniques.

Question 3 “What else might affect this?” relates to system analysis and design and can be fed by, and lead to, the chains of outcomes elicited using analysis methods, such as process modelling and root cause analysis.

Question 4 “What else might this affect?” considers uncertainty and risk.

These four questions can be iterative. Use them near the beginning to define the problem and then at the end to tie together the entire work.

Is-Is Not Matrix

The Is-Is Not matrix is a great tool for problem-solving, that I usually recommend to help frame the problem. It is based on the 5W2H methodology and then asks the question of what is different between the problem and what has been going right.

	IS	IS NOT
What	What specific objects have the deviation? What is the specific deviation?	What similar object(s) could reasonably have the deviation, but does not? What other deviations could reasonably be observed, but are not?
Where	Where is the object when the deviation is observed (geographically)? Where is the deviation on the object?	Where else could the object be when the deviations are observed but are not? Where else could the deviation be located on the object, but is not?
When	When was the deviation observed first (in clock and calendar time)? When since that time has the deviation been observed? Any pattern? When, in the object’s history or life cycle, was the deviation observed first?	When else could the deviation have been observed, but was not? When since that time could the deviation have been observed, but was not? When else, in the object’s history or life cycle, could the deviation have been observed first, but was not?
Extent	How many objects have the deviation? What is the size of a single deviation? How many deviations are on each object? What is the trend? (…in the object?) (…in the number of occurrences of the deviation?) (…in the size of the deviation?)	How many objects could have the deviation, but do not? What other size could the deviation be, but is not? How many deviations could there be on each object, but are not? What could be the trend, but is not? (…in the object?) (…in the number of occurrences of the deviation?) (…in the size of the deviation?)
Who	Who is involved (avoid blame, stick to roles, shifts, etc) To whom, by whom, near whom does this occur	Who is not involved? Is there a trend of a specific role, shift, or another distinguishing factor?

Is-Is Not Matrix

Here is a template for use.

SIPOC for Data Governance

The SIPOC is a great tool for understanding data and fits nicely into a larger data process mapping initiative.

By understanding where the data comes from (Suppler), what it is used for (Customer) and what is done to the data on its trip from supplier to the customer (Process), you can:

Understand the requirements that the customer has for the data
Understand the rules governing how the data is provided
Determine the gap between what is required and what is provided
Track the root cause of data failures – both of type and of quality
Create requirements for modifying the processes that move the data

The SIPOC can be applied at many levels of detail. At a high level, for example, batch data is used to determine supply. At a detailed level, a rule for calculating a data element can result in an unexpected number because of a condition that was not anticipated.