HOW TO MANAGE A RISK ANALYSIS PROGRAM

James McLinn Reliability Consultant Rel-Tech, Inc. Hanover, MN 55341

SUMMARY
A risk analysis program is one of the most important activities in which a reliability engineer, quality engineer or project designer can take part. The team activities that go into creating a risk analysis are often some of the most critical and important for any company. Primary results are the reduction of direct risk to a company and the improvement of products and processes. The secondary results are often more important. These include time to market, corporate reputation, enhanced system performance, reduced reliability and warranty costs and maintenance of a favorable reception of a corporate product line. Most importantly, included in secondary benefits is the extension and enhancement of corporate reputation. Risk analysis can be viewed as the balancing of a number of dynamic, non-linear and critical corporate business factors all related to corporate success (McLinn 1994, 1996, 1997). Thus, the method of and outcomes from the risk analysis are vital. Three common tools are used for risk analysis: failure mode effects analysis (FMEA), fault tree analysis (FTA) and hazard analysis.

KEY WORDS
failure mode effects analysis, hazard analysis, risk analysis

INTRODUCTION
The three common tools of risk analysis are briefly and incompletely described in a number of reliability books and articles. There are several major problems with these brief descriptions. They might be grouped as technical problems, execution problems and team problems. This paper will show how many of these problems may be avoided or prevented. In addition, it will go beyond the simple technical description to show how the level of effort to complete the FMEA, FTA or hazard analysis may be reduced while the quality of the output is improved. Harm is defined in the European Standard (EN1441:1998), as physical injury and/or damage to health or property, while hazard is defined as a potential source of harm. Risk is the probable rate of occurrence of a hazard causing harm and the degree of severity of the harm, while risk analysis is the investigation of available information to identify hazards and estimate risks. Which method is best? This question is often asked and the answer depends upon what you know, the stage of the project and the main goal. Each method has strengths and weaknesses. Hazard analysis is a short method best applied during the early stages. Since this method has somewhat vague scales for severity and occurrence, it is compatible with the lack of detailed knowledge that is typical of the early design/development stage. It may provide estimates of problems and safety concerns. The strength of the FTA is that multiple failure causes can be easily described. For example, when a hardware and software failure both occur, FTA easily covers the possible complex interrelationship, but gives little help in determining which failure modes are the most significant. No simple priority of importance results during an FTA. One value of FTA is that it can be done any time, even very early in the design process. One need only have a knowledge of the system functions and relationships. Detailed design information is not required. Safety issues can be identified but absolute estimates of likelihood do not typically result. FMEA, on the other hand, gives priority of importance but requires detailed design knowledge and cannot easily handle multiple failure causes. Think of hazard

40

ASQs 53rd Annual Quality Congress Proceedings

41

analysis as a quick estimate, FTA to cover complex relationships and FMEA to identify priorities. Some companies choose to perform 2 or all 3 of these activities.

1.0 PLANNING FOR THE BIG FMEA EVENT

What manager of any standing would start any big task without asking the fundamental questions? What is the task? What is (are) the purpose(s)? and What are the limits? After these questions, planning, planning and more planning is prescribed. After all, this is typically a big job, consuming up to 50 man-hours per team member. Selection of team members can be very important, so plan carefully who will be on the team. The following simple rules might help. Selecting the design FMEA team members is the first task. Select members from broad corporate functions. Be sure to include customer service, field service or technical service, that is, any group that helps customers solve problems. As a rule, add design, quality, manufacturing engineering, a facilitator and anyone to represent critical assemblies. This could be the customer or even a supplier. Dont over invite; this is a common error. Keep the team to about 6 or 7 people and avoid having both a person and his/her supervisor as a member. Plan what will be covered in the first team meeting. That is, be sure some of the people bring critical data. This is any relevant qualification test data, field data or system performance data. Have field data sorted by frequency of event (failure) and by dollar cost. This latter should be total cost to repair a failure, not just the standard engineering cost of a replaced part or assembly. Help the team avoid problems by creating a short document that defines failures. These are hard failures, secondary failures, soft failures, parametric problems or any other item the customer would perceive as a failure of the system to perform any of the intended functions. Next, also define the customers use environment. This might be temperature, vibration, voltage, on time as well as active system use time and system load or direct stresses. Be sure to define the average customer and the 95% customer/heavy use customer. Lastly, cover customer rough handling, misuse, abuse and potential safety problems. Summarize each of these on a sheet of paper.

1.1 THE FIRST TEAM MEETING

This may start with a short orientation for the team members if they are not familiar with the details of the FMEA itself. After this session, bring out the data, including all definitions, customer information and relevant failure information. Be sure everyone gets a chance to briefly review and comment. Discuss what you know and gather divergent ideas about customers, product use and product performance.

1.2 WATCH YOUR WORDS

The next activity will be outlining the typical team rules. These are One person speaks at a time, Listen until the end of a statement before responding, Be respectful of opinions and ideas, etc. The next team activity might be a review of the words to avoid in an FMEA. These words are all vague and therefore misleading. These are examples but are not an exhaustive list: wrong, bad, too, no, good and out of specification and an example of a vague statement is The system has the wrong output. This innocent sentence is very vague. The wrong output is any of a number of outputs that are unacceptable. It is best to make a more precise statement for the reader to easily identify. A simple example: a steady blue star is expected as a system response. Wrong outputs include red stars, black stars, blue circles, blinking blue stars, yellow boxes, an audio signal and failure of the system to provide any output. The customer response will be different for each of these wrong outputs as will any technical solution. Be sure to use a complete sentence for all FMEA inputs. This may seem unnecessary but, just like the example above, is critical. Try the following word broken. Imagine this were a one-word FMEA entry. If it were in the failure mode column it might describe the propagation mechanism that leads to system failure. For example, this single word could stand in for the more complete thought, The output sensor has a broken lead or even The case of the output sensor shows a crack. This single word in the effects column of an FMEA might stand in for The system does not operate at all or even The system is providing a misleading output for some feature. It is up to the reader to try and guess what a single word entry or an incomplete thought as an entry might actually mean. Ask three people and most of the time you get three different guesses. The team is responsible for writing a careful sentence that expresses an exact idea, not too much or too little. Normally this takes one or two tries to get a best statement. Be sure each team member agrees before moving on to the next entry.

42

ASQs 53rd Annual Quality Congress Proceedings

The FMEA is a collection of ideas that are most of the time not organized in a logical fashion. The FMEA typically starts with the failure mode, moves to the effect on the customer and lastly lists some of the causes. Normal everyday logic operates in a cause, mode and then effect. Most often, the failure mode can be described as the overt, directly observable mechanism that leads to a system effect. It is often confused with the cause. Treat the mode as the way and the cause as the why and the effect as the what happened.

1.3 WHAT DO YOU ALREADY KNOW

At the first team meeting and before you can start the FMEA, be sure to do the following. Take 5 to 10 minutes to discuss the purpose of the FMEA. Be sure to consider design purposes, customer purposes and manufacturing purposes. Write these down on the FocusSheet in an organized fashion (see Figure 1). A short sentence, 15-word maximum, would describe each area. Next, write down what you know about the natural limits associated with the FMEA. This may include how far to go with the FMEA, the extremes of customer use or even the environmental conditions. The last and most difficult item for the FocusSheet is to list the assumptions for the FMEA. Almost all team members arrive at each meeting with these assumptions. Talk about them and then write them down. Why you may wonder? Because no two people arrive with the same set of assumptions and half the time team members do not even recognize that they have been making and using assumptions. An example of one common assumption is that Only conforming components are in use in the design. If this is not a true statement, then the FMEA must be extended to include entries that describe situations where components may be just out of specification at either the high and low side and also very far out of specification at either extreme. One should also identify the limits of each of these categories. For example, some simple tolerance stack-up situations are found to be incompatible with the successful operation of the system (see Figure 2). Considering this assumption forces a design review if the various out-of-tolerance limits cannot be easily identified.

1.4 AVOIDING THE RUBBER YARDSTICK OR CREATING EFFECTIVE TABLES

The three tables of the FMEA are the yardsticks by which the team makes judgments and recommendations, initiates corrective actions and makes critical business decisions. Far too little discussion about creating rational tables is in the FMEA literature. Often the impression is that these tables are all based upon opinions and as such are really arbitrary biases. The following is a short discussion of how these critical tables might be logically created to avoid much of the human bias. The severity table is the most logical and straightforward in an FMEA. If it is well constructed, it is the most logical. It describes the impact of some sort of a failure on the customer. Almost all severity tables are based upon a hierarchy of importance. Low numbers are the most trivial and the high numbers are the most important. As such, it

Purpose 1. ______________________________________________________________________________ 2. ______________________________________________________________________________ 3. ______________________________________________________________________________ Assumptions ________________________________________________________________________________________ ________________________________________________________________________________________ ________________________________________________________________________________________ Natural Limits ________________________________________________________________________________________ ________________________________________________________________________________________ ________________________________________________________________________________________ Figure 1. FocusSheet.

ASQs 53rd Annual Quality Congress Proceedings

43

Figure 2.

Tolerance ranges in FMEA.

is possible to describe 1, 2 or even 3 levels of low system impact. These are called simply aesthetics and typically describe paint blemishes, dented system chassis or even the loss of back lighting. Sometimes it is said that these require special tools or knowledge to measure. Beyond this level, there are always minor system functions that are not critical to system operation. One, 2 or even 3 levels of these may be described as appropriate. Next, in ascending importance is the failure of major system functions. These are the functions that are required for system operation, so there is strong customer impact. One, 2 or even 3 levels of impact can be described. These might be a slight error in a reading, such as 2%. Next, is a large error in a reading such as 40% or an intermittent reading (operation). The last level could be no reading or operation. Above these are failures that lead to safety situations or violations of regulatory standards. One to 5 levels might be described, such as minor injury not requiring medical attention, minor injury requiring professional medical attention, injury reversible such as broken arms, irreversible serious injury and serious hazard (see Figure 3). Now meld these into ten categories. The occurrence table can be easily created. It represents either some probability of failure or is proportional to a failure rate. It measures the probability of the cause being present. It is not the probability of the effect, as is often mistaken. There are a variety of ways to create an occurrence table. Consider the following approach for creating a ten level table.

Figure 3.

Severity table.

44

ASQs 53rd Annual Quality Congress Proceedings

Determine how many systems, N, will be built over some period of time. Then, lowest probability of failure is 1 . This often sets a lower limit. At the other extreme consider the threshold for a single component or assembly is N of economic pain. Imagine 20% of the systems would fail during a period of time such as the first five years. With the two extremes defined, the eight remaining can be determined one of two ways. Divide the distance between the upper and lower limit into eight even categories. This approach tends to overemphasize the high probabilities of failure. It ignores the large relative differences between low probabilities. A viable alternative is to take the ratio of the highest number divided by the lowest and then the eighth root (Method B shown in Figure 4). This gives a multiplicative factor for forming each of the categories. Method A has all the probabilities as 2 while method B has four different numbers for the four different probabilities. Other methods do exist for creating simpler scales. These are shown later.

1.5 VERIFICATION OR HOW GOOD ARE YOUR EVALUATION SYSTEMS

The third scale for a DFMEA is sometimes labeled verification. It is well described in the AIAG FMEA Handbook (SAE 1993) as . . . an assessment of the ability of the proposed current design controls to identify a potential cause (design weakness) before the component, subsystem or system is released for production. In order to achieve a lower ranking, generally the planned validation/verification program has to be improved. Thus, it asks how well one evaluates the design feature associated with a failure mode and failure cause. The creation of the scale might best start by making a list of all the design evaluation, qualification, verification activities that are part of the design/development process. With this list the efficacy of the test may be estimated for the failure cause. This approach also allows identification of weaknesses in the qualification/evaluation plan. Figure 5 shows one such table. Included are numerical estimates that help teams focus while making their estimates of this number. Many systems provide only vague categories and it can be very hard to identify the best choice. A detection table for a process FMEA focusing upon inspection opportunities and manufacturing controls can be created in a similar fashion.

1.6 WHY NOT HAVE A TEAM FACILITATOR?

Some companies have yet to realize the value of a facilitator to an FMEA team. This team member is there to help plan the first meetings, make sure they run well, serve as a check for consistency of entries and keep the team focused and moving. Only a few simple tools are required to keep the team moving. Consider the following suggested rules for a facilitator: 1. Ask all team members to come prepared. Be sure to check on activities that are planned to go on between team meetings. 2. Encourage all people on the team to participate. Be sure to ask anyone who doesnt seem to be active if they agree with the most recent entry. 3. Ask leading questions occasionally. For example ask Is there anything else before moving on?

Number 1 2 3 4 5 6 7 8 9 10

Range - Less than 1/1,000,000 - 1 to 4.6/1,000,000 - 4.61 to 21/1,000,000 - 21.1 to 97/1,000,000 - 97.1 to 447/1,000,000 - 447.1 to 2/1,000 - 2.1 to 9.45/1,000 - 9.46 to 43.5/1,000 - 43.6 to 0.20 1.20 - Greater than 0.20 Figure 4. Occurrence table.

Std. Dev. 4.83 4.61 4.26 3.93 3.51 3.09 2.60 2.02

ASQs 53rd Annual Quality Congress Proceedings

45

Number 1. 2. 3. 4. 5. 6. 7. 8. 9. 10.

Description of Verification Effectivity Probably catch more than 98% of mode during development. Catch more than 95% of mode during development. Catch more than 90% of mode during development. Catch more than 80% of mode during development. Catch more than 60% of mode during development. Catch more than 40% of mode during development. Catch more than 20% of mode during development. Catch more than 10% of mode during development. Catch more than 5% of mode during development. Catch more than 2% of mode during development. Figure 5. Verification table.

4. Once a discussion starts on an entry, the facilitator should mentally ask after about a minute Can this discussion go anywhere? If so, let it continue as is by saying nothing. At about five minutes, if the discussion has not reached a conclusion, take a more active role to bring it to one. Summarize, restate and clarify as necessary to get the team to an agreement or a recognition that outside data or a different approach is required. 5. If a strong disagreement arises, let it go on briefly. About 30 seconds after it starts, the facilitator should ask if this can be resolved. If it does not look like it can be resolved or is only a matter of opinion, the facilitator should stop the team and ask Who will take the action to find out or resolve the disagreement? Resolve the problem outside of the meeting, perhaps by those who disagree. Now it is time to get started for the FMEA team, so begin at the FocusSheet to get the team moving.

2.0 FAULT TREE ANALYSIS

This tool is sometimes the best one to employ for evaluating a complex system. This tool is best applied early in the design process. It starts by defining a system failure event and proceeds to speculate about possible causes (Ireson et. al. 1996, OConnor 1996, Stamatis 1995, Mattsson 1995 and Raheja 1990). Figure 6 shows a simple example of an electrical lead-based sensing system with some lower level fault events. The FTA process does not identify the most likely or critical faults from those that are less likely or even less critical. Some believe that the best application of this tool is for software-dominated systems and when looking for safety-related faults or paths.

Figure 6.

FTA simple example.

46

ASQs 53rd Annual Quality Congress Proceedings

Number 1 2 3 4 5

Description Aesthetic failure or Negligible Impact Minor function failure or Marginal Impact Major function failure or Significant Impact Minor safety issue or Reversible Injury Serious safety/regulatory issue or Serious Hazard Figure 7. Severity table for hazard.

The fault tree is built of simple AND and OR logic elements. These may be combined through complex logic paths. Low level events such as the two that contribute to the electrical failure AND in Figure 6 may be built from complex combinations. The circle represents a lowest component level failure, while the diamond is an event of low significance. Common mode failure causes may also be easily depicted in an FTA. Thus, the same low level problem that contributes to the electrical failure may also be part of another fault event. All FTA teams can certainly follow the same facilitator recommendations as outlined in the FMEA section. A FocusSheet is appropriate in this case as well. Few terms appear on the fault tree, but occasionally a detailed written table may be created by the team to explain or provide more detail to the FTA.

3.0 HAZARD ANALYSIS

This tool might be described as FMEA light. The focus is upon the severity of a valid failure mode and the likelihood of occurrence. It is often applied early in the development cycle, even before the design details are complete. The intent is to identify areas of concern for the design so that additional effort might be focused for prevention. Since much less is known at this point, the tables that support severity and occurrence need not be very precise. Figures 7 and 8 show typical generic tables often employed for the two hazard analysis tables of severity and occurrence. The generation of these two tables would probably follow the same approach as noted for FMEA. Fewer and larger categories cover the uncertainties that accompany this method. The tables should be tailored for individual situations of market, application and customers. Figure 9 shows a generic hazard analysis table. This tool is typically employed to help determine what failure modes should be pursued and suggest the level of effort that may be required. Note in this figure, small numbers are traditionally undesirable. The worst combination of severity and occurrence is then labeled a 1. This hazard table is created based upon the traditional words that describe the categories, ignoring the negligible impact category. Thus, for a serious hazard with a remote or improbable occurrence, the team should review the situation for appropriate responses and actions.

Number 1 2 3 4 5

Description Very rare event Rare event Occasional Frequent Very Frequent Figure 8.

Numerical Probability Less than 1/10,000 probability from 1/10,000 to 1/1000 probability from 1/1000 to 1/100 probability from 1/100 to 1/10 probability greater than 1/10 probability

Occurrence table for hazard.

ASQs 53rd Annual Quality Congress Proceedings

47

Figure 9.

Hazard table.

CONCLUSIONS
The management of risk analysis programs is one of the most important product development activities that an engineer or manager can perform. Three common tools were described in this paper with recommendations on their use. In addition, methods of easy implementation were noted. Planning for the risk analysis program is the best way to ensure that it will come to successful completion.

REFERENCES
European Standard EN1441:1998. Ireson, Grant, Coombs, Clyde and Moss, B. 1996. The Handbook of Reliability Engineering and Management, New York, McGraw-Hill. Mattsson, Fredric, SEMKO. 1995. An Introduction to Risk Analysis for Medical Devices, Compliance Engineering, November/December, pp. 4757. McLinn, James. 1994. Improving the Product Development Process, Proceedings of the 48th Annual Quality Congress. pp. 507516. McLinn, James. 1996. Reliability Development and Improvement of a Medical Instrument, Proceedings of the Annual Reliability and Maintainability Symposium, pp. 236242. McLinn, James. 1997. TQM Metrics for Product Development and Projects, 41st Annual Congress of the European Organization for Quality, Trondheim, Norway, vol. 1 pp. 149158. OConnor, Patrick. 1996. Practical Reliability Engineering, 3rd. edition. John Wiley and Sons, New York. Raheja, Dev. 1990. Assurance Technologies: Principles and Practices, McGraw-Hill, pp. 142157. SAE Potential Failure Mode and Effects Analysis. 1993. Published by the Automotive Industry Action Group (AIAG). Stamatis, D. H. 1995. Failure Mode and Effect Analysis: FMEA from Theory to Execution. ASQ, Milwaukee.

How to Manage a Risk Analysis Program May 24, 1999 James A. McLinn

A Risk Analysis Program The FMEA Tool

Plan, Plan, Plan! I Its a big job so organize all the available information that you have. I Invite the customer and field service and bring the real data, dont depend on opinions. I Invite design, quality and manufacturing engineering etc.
I

Watch Your Words in a FMEA

I Remember to say exactly what you

mean! Dont talk around the topic. The contents are very important. I Be precise and succinct with words and phrases. I Dont say too much. Each entry is not a book. Keep the entries focused.

Watch Your Words cont.

I Dont say too little. Use a complete

sentence to describe a complete thought. I Avoid certain words - Wrong, Bad, Too, No, Good, Out of Specification are usually part of vague terms or phrases.

Out of Specification Means?

Identify one of the 7 ranges below
Far out of Spec - Low Just in Spec. Center of Spec. Just out of Spec - Low Just out of Spec - Hi Far out of Spec - Hi

Know the FMEA Purpose

Define your customers - Identify the design needs and even wants. I Remember safety concerns, warnings, indicators and alarms. I The Design FMEA should be compatible with manufacturing. Dont try to sort potential design or supplier problems. I Design problems usually have design solutions.
I

Know Your Customers

I Define the average use customer, the

heavy use and light use customers. I Remember to include the possibility of customer misuse, abuse and rough handling of the system. I What level of automatic protections and warnings exist to prevent misuse or injury?

What do you already know?

Write down the natural limits associated with the FMEA. Examples include limits on operating time, customer use, manufacturing plants, common products, customer environments, impact of maintenance activities I Include limits of the design, i.e. to connectors or to a natural interface.
I

What do you already know? - cont.

Examine the hidden assumptions of the team. Consider the impact of the MRB, the supplier qualification process and recent other projects. Are components and assemblies conforming or qualified as received? I Look at the design intent, verification and validation activities and even estimate their effectivity.
I

Learn How to Create Effective Tables

I

The three tables are the yards sticks of the FMEA. If they are well designed, the FMEA contents to be meaningful.
Design FMEA Process FMEA

Severity Occurrence Verification

Severity Occurrence Detection

Severity - The Measure of Customer Impact

Aesthetics Minor System Functions Major System Functions 1 or 2 levels 1 2 3 4 5 6 7 8 9 10

1 to 3 levels

1 to 3 levels

Safety, Regulatory 1 to 4 levels or Liability issues

Whats the Probability of Occurrence ?

Avoid vague categories such as frequent, seldom or often in an FMEA table. These terms are better suited for Hazard Analysis tables. I The occurrence table covers the range of reasonable possibilities of failure causes. I Identify the lower table limit. Try 1/(planned build) as a low limit probability.
I

Whats the Probability of Occurrence? - cont.

Set the upper limit based upon economic hardship, customers needs or market drives etc. This might be 5% to 50% over the life of a product. I Divide up the 8 remaining numbers in between these limits. I Be sure to use at least 4 occurrence numbers out of 10 in the Design FMEA.
I

Occurrence Table Example

Number Probability Range
1 - Less than 1/1,000,000 chance 2 - 1 to 4.6/ 1,000,000 3 - 4.61 to 21/1,000,000 4 - 21.1 to 97/1,000,000 5 - 97.1 to 447/1,000,000 6 - 447.1 to 2/1,000 7 - 2.1 to 9.45/1,000 8 - 9.46 to 43.5/1,000 9 - 43.6 to 0.20 10 - Greater than 0.20 or

Std. Dev.
+4.83 +4.61 +4.26 +3.93 +3.51 +3.09 +2.60 +2.02 +1.28

Product Verification - How good are your corporate qualification systems?

Verification measures the sum total of all the preproduction qualification, evaluation, reliability and durability testing you do or intend to do. I Include any supplier qualification and reliability testing of purchased components and assemblies I Make a list of the evaluation tests you actually do.
I

The Verification System

Perform Design Verification during prototype development. Operate a series of reliability evaluation tests during prototype and pre production phases. Perform product qualification. Perform thorough design reviews. May include history of similar products.

Suggested Verification Table

Number Description
1. Probably catch more than 98% during development. 2. Probably catch more than 95% 3. Probably catch more than 90% 4. Probably catch more than 80% 5. Probably catch more than 60% 6. Probably catch more than 40% 7. Probably catch more than 20% 8. Probably catch more than 10% 9. Probably catch more than 5% 10. Probably catch more than 2%

Detection Table for Process FMEA

This is the sum total of all the quality control, manufacturing activities and machine checks of the manufacturing process. I It applies typically anywhere in-house for a potential process problem. I Does not depend upon the customer to recognize or identify the problem.
I

Now begin the first FMEA team meeting

Organize the design drawings or process documents I Start at an important place and set limits. I Write down plausible single point failure modes only. I Dont select system failure modes based upon multiple events, except for safety related areas.
I

Facilitator participation is very important

I Ask all team members to come

prepared with data at the first team meeting. I Encourage all people to participate. I Employ good time management.

Focus Sheet
Purpose 1 -Design ____________________________________ 2 - Manufacturing______________________________ 3 - Customer__________________________________ I Assumptions ____________________________________________ ____________________________________________ I Natural Limits ____________________________________________ ____________________________________________
I

Fault Tree Analysis

I A top-down logical method of

identifying the failures of a incompletely defined system. I May show complex logic and interconnections. I Can show how software and hardware events interact.

Simple FTA Example Detection Circuit

Lead Does not Sense

Abnormal Tissue growth High Resistance Electrical Fail

Hazard Analysis
A simple approach to estimate risk. I Can be best utilized when few details about a design or process are known. I Much less work than FMEA or FTA. I Lower quality output, hazards less precisely known. I Employs Severity and Occurrence only.
I

Typical Hazard Severity Table

Number Description 1 Aesthetic failure or Negligible 2 Minor function failure or Marginal 3 Major function failure or Significant 4 Minor safety or Reversible Injury 5 Serious safety/regulatory issue or Serious Hazard

Hazard Occurrence Table

Number Description 1 Very Rare event - Less than 1/10,000 2 Rare event - 1/10,000 to 1/1000 3 Occasional -1/1000 to 1/100 4 Frequent - 1/100 to 1/10 5 Very Frequent - greater than 1/10

Hazard Table
Severity Serious Major Requires Action Occurrence Frequent 1 3 Probable 2 5 Occasional 4 6 Remote8 10 Improbable 12 15 Significant
May Require Action

Marginal 13 16 18

7 9 11 14 17 19

20
No Activity Required