Risk? What Risk?
As an engineering professional and subject matter expert in product and process quality, I am often asked about quality in terms of risk analysis. How is risk analyzed, and how is risk mitigated in a systematic way? In many cases these questions are asked by legal professionals who need to understand how to defend or attack a risk analysis approach. My first response is usually ‘what risk would you like to talk about?’, and the response usually comes back ‘What do you mean?’. So I thought it would be good to write an article on the subject.
Risk Analysis Approach is a very broad topic. There are many documents that talk about risk and describe it in different ways. It happens at different levels and the analysis can be done for different parties (ie. the financial risk a company takes when launching an NPI (New Product Introduction) program, the risk of a system or component failure to an end user (like breaks on a car), or the potential of harm to a company factory worker when performing a task (Safety Analysis). So let’s assume we are speaking about the risk of a design harming an end user. If you have an interest in risk analysis from another perspective drop me a line or make a comment and I will try to answer.
In a comprehensive risk analysis approach we look at risk on several levels like machine, system, subsystem and component. We also stratify risk by how the risk can be mitigated like Requirements, Design, Process and Product Usage. It is often the case that roughly 80% of a complex system consists of purchase finished parts from suppliers. This stratification can happen within the suppliers as well. Naturally the purchasing company can not be directly involved with the risk assessment of every level at every supplier. However quality systems like APQP (Advanced Product Quality Planning) does give the option of requiring artifacts from suppliers proving their execution of risk mitigation duties. These documents can be requested and held through the PPAP (Production Part Approval Process). Keep in mind, companies have other design work going on outside of NPI in R&D and special assignments with suppliers in the development of new technologies. For now I will assume anything outside of NPI is out of scope. If non-NPI work is of interest to you drop me a line or make a comment and I will try to answer.
A couple of definitions may help at this point.
Function: States what the design is expected to do. Most primary functions are known, they are the reason for pursuing the design. Other functions can be discovered by analyzing the design in the context of the things it interacts/interfaces with.
Requirements: Requirements are the measurable criteria that product and process designers use to make design decisions. Requirements put quantitative measures to function. Requirements state “how well” the design must perform the expected functions.
New Content: is considered something that is new to a product that engineering doesn't have experience with and is unknown. This includes the application of the product, design, and manufacturing change. Different companies have different methods of calculating the amount of new content, but this general definition should suffice for the purpose of this article.
Carry Over: is the list of problems and issues being carried over from the previous product generation into the new product being developed.
Design: Designs are specific solutions to provide machine functionality and meet technical requirements. Designs are documented in different forms. High to mid level system designs (such as prime product and complex systems) are described by architecture diagrams and technical specifications. Architecture diagrams show what systems are in the design concept. Technical specifications describe what each of the systems in the design is expected to do and how well. Low level designs (components and parts) are described by solid models and prints.
Risk: The possibility of something bad happening.
In order to understand the risk of developing a product we first must be sure we understand what the design is supposed to do. So the functions and requirements of the product we will be developing must be defined and prioritized. Without this first step we will fail in the identification and prioritization of risk, because risk is defined in terms of the requirements. So although we may not be identifying any risk when we identify and prioritize requirements we can not proceed without this first step. That is why it is at the top of the funnel in the Risk Identification Activities graphic.
The first level of risk identification is a high level product view of new content and carry over analysis. These analyses give the program manager a level of understanding about how much design work is ahead of them. It also identifies the systems and subsystems that have the new content and carry over. The more content of a product we don't have experience with (designing & building), and the more complex the product requirements and design are, the greater the risk.
The next level of risk identification is the Risk Assessment Survey. This survey can be applied at the machine, system or component level. The survey asks the engineer to rate the product with general questions regarding regulatory requirements, new content and manufacturing capability. It then classifies the product at a certain risk level. It might use a ranking system like 1, 2, 3 or 4 risk. Where 1 risk is the highest and 4 risk is the lowest level of risk. These coarse calculations of new content, carry over analysis and the risk assessment survey are critical to the quality of the product. A company has limited resources and time to work on a product. It does not have the luxury of doing a complete analysis of everything on every generation of a product. So priorities must be set.
Complex machines require huge amounts of resources to develop. They are never developed over night, but rather are developed over many generations of the product and even generations of designers. When we make a change to a product or become aware of a problem with a product we must focus our attention on where the change or problem exists. However with the complexity of the machines there are many interfaces and interactions which make the prioritization of what to focus on difficult.
Think about today's driver-less car compared to the first model T. How many systems were developed and refined in order to make this functionality available (satellite, radar, obstacle recognition cameras, computing power...)? If we chose to make a change to the power system of the driver-less car, we could have an impact on the speed or distance the car could travel which could in turn have an impact on the feasibility of making a certain trip or the route chosen. This would have to be accounted for in the algorithms of the car's navigation system. Such complexity was not a factor with the model T Ford. Refinement in the understanding of the risk of a product starts with knowing & understanding the requirements. Then coarsely identifying the risk by what is new, what is old or known, what is related to the customer, what is related to regulations, and in which systems, subsystems and components these risks reside. These all help the engineer prioritize where a more refined and specific risk analysis will be used.
Once the risk has been identified at the various levels we begin a more refined process of risk identification and mitigation. This means we start to stratify the risk into other categories like design, process or usage. Ideally we would like to do this at each level where the risk has been identified as either 1 or 2 risk. So for instance if we had a hydraulic system that had been identified as level 1 risk due to New Content, we would now use the system requirements and do a Design Failure Modes and Effects Analysis (DFMEA). The DFMEA sets the stage for the risk mitigation activities. It identifies elements of the design that could or should be changed through recommended actions. The DFMEA also sets the stage for the appropriate design verification and validation activities. These verification and validation activities are known in the DFMEA as Controls, and their purpose is to prove the design meets its intent through testing and measurement. So these controls go into the product test plan.
In the DFMEA, the process of identifying design elements that will be hard to manufacture or assemble is begun and finished. These design elements which are difficult to build are known as Special Characteristics.
How the design is built/manufactured/assembled introduces risk to the design as well. So in order to mitigate process risk, Process Failure Modes and Effects Analysis (PFMEA) is introduced. The PFMEA works much like the DFMEA by identifying risk in the process. This risk is typically mitigated through changes to the process, but can also be mitigated through feedback to the design group. The PFMEA also receives Special Characteristics from the design team and identifies where those characteristics are created in the process. The PFMEA identifies process characteristics which are hard to control but could impact design specifications. The PFMEA includes how certain aspects of the process are to be controlled. These controls go into what is called the Control Plan. The Control Plan is the list of activities the process engineer and operator will check and do on an ongoing basis. These controls are there to ensure the product is consistently manufactured to engineering specifications.
Lastly there is product usage. This refers to the potential risks inherent in the usage of the product which apply to service personnel, owners and operators. These can be identified and communicated to the service personnel, owners and operators through a variety of means such as warning labels, operator manuals, lock out / tag out procedures, maintenance manuals and procedures, and technical bulletins.
Within my multi decade career, I have worked as a design engineer, design liaison, warranty design engineer, six sigma black belt, manufacturing engineer, quality engineer, process owner, NPI liaison, engineering manager, quality manager, subject matter expert, trainer, coach/mentor, and Subject Matter Expert (SME) to legal counsel. I have seen and evaluated product and process risk from every angle. If you have a question or different perspective on risk, I would like to hear it. Learning is a passion of mine, and I am always open to discussion. Feel free to send me a message or make a comment.
Like it? Leave a comment & feel free to share it!
