Hello,
This is an interesting article. While I do agree that yes, companies can make these common mistakes, it still does not hurt to follow a process. The article mentioned that risk management is looked at as a "checkbox" activity. The checkbox is there to guide the company on brainstorming the potential risks and figuring out how to prevent or minimize them. Without it, it is very easy to get lost in the mayhem, so to speak. Where would one start when beginning a risk analysis?
When determining risks for medical devices especially, companies need to expect the unexpected. This means that the analysis will be done in several sittings instead of one and over the course of a period of time. Problems are always bound to arise and not 100% of them will be recognized. Therefore, following a checklist can be a good thing, at least to keep the company organized and help the engineers on track as to not forget about certain risks.
I agree with what you've written above and I think the problem lies within the company's philosophy itself. More often than not, these companies are not making devices to "help people" but rather to make money. With that, there are deadlines that need to be met and competition to beat. Therefore, I think many companies get complacent and allow risk management to become that "checkbox" activity. That being said, they like to hedge their risks as well to protect them financially so the big risks are usually covered. As someone mentioned before, the small risks need attention and I think those are the ones that really show if a company truly cares about their product or if they want to just meet their deadlines and make their profit.
- Saad Ali
Wow, reading this was extremely interesting and a definite eye-opener. It is an interesting discussion. Companies should perform risk assessments throughout the entire lifecycle of the product—even when it is placed on the market. This is a way to ensure the consumer that the product is functioning effectively and it is safe for use. A satisfied customer would allow sales to increase due to confidence in the product itself. Additionally, concerns and complaints from the customer should be heard with open ears and incorporated into the assessment in order to improve future prototypes and final products. Risks would ultimately be minimized. Risk management and safety is significant and a company should not assume that there are no risks associated with their product. It’s upsetting when companies do not follow through and do an analysis after their product is on the market. It shows that they do not completely care about whether or not their product is actually succeeding and meeting customer needs.
I agree that risk management is a “checkbox” activity to some companies. Just like quality control and quality assurance, risk management is important to producing a safe product built of high quality. I believe there is a point where a product design reaches a limit, however if the safety or quality of a product can be improved upon without adding too much time and cost, why not go for it?
I agree that Risk Management should be considered a living document to help a company document and keep track of their product post production. There are some issues that a product can experience after production their complaints can help a company create a better version of the said product. This piece of information can also help the FDA identify any common issues that other similar devices may have after gathering this data. Risk management help determine the hazards that the product may experience, this is where Risk Management is different from QA and QC, those two departments ensures that the device meets the need of the customer, performs validation and verification to ensure the device meets the gold standard, but does not take into consideration the hazards and how to plan against them.
Few of the mistake that company make that I came across are
1. Not considering opportunities – just threats
2. Confusing risk causes, risk events & impacts
3. Using checklists and not ‘scanning the
horizon’ for other risks
4. Understating risk impacts, and not scaling the
impacts based on project drivers
5. Not using 100% probability during planning
7. Calling risk response planning ‘mitigation’
6. Not considering sensitivity with risk analysis
8. Not considering contingency plans when
doing risk response planning
9. Not making specific project team members
responsible for specific risk events
10. Not making managing risks an on-going process
I agree that #4 "Risk management is not a lifecycle process" and that it is a mistake to think that once the development process is completed that the risk management documentation ends. I agree with @smk45 that it should be treated as a "living" document. As Dr. Simon discusses in lecture there should risk management documents in DHF: Risk Management Plan, Risk Analysis, and Risk Management Questionnaire.
Risk Management Plan-tells you how you are going to handle risks and what level of risks you will accept. This allows the rules to be set on how to deal with risks.
Risk Analysis-Lists the risks and tells you how you will mitigate them
Risk Management Questionnaire- Gives you questions to brainstorm and helps you to list the risks. This is what ISO wants you to look at.
I found an article shows that you could call this a Risk Management file (RMF) and can be structured and organized by an individual product or for a product family. It contains evidence of:
-Risk Management Plan
-Risk Analysis
-Risk Evaluation
-Risk Controls
-Evaluation of Overall Risk Acceptability
-Risk Management Report
-Production and Post-Production Risks
Again the Risk documentations should be a living document and should be used as a tool as for production and post-production and can be helpful to document CAPAs, complaints, etc.
I agree that trying to predict extreme events is a critical mistake in risk management. Instead of trying to predict extreme scenarios, I think it would be better to focus on the consequences. Instead of trying to predict when a major event will happen, they should understand how the company will be affected and be prepared IF the situation should occur. By changing this approach, the facilitator doesn’t neglect other possibilities and makes them less vulnerable.
There were a lot of mistakes can be made while implementing the FMEA. The mistakes cause the FMECA not meeting the objectives of it. Conceptually, Poka Yoke is able to fit into the Process FMEA. Failure Mode and Effect Analysis (FMEA) helps predict and prevent problems through proper control or detection methods. Mistake proofing emphasizes detection and correction of mistakes before they become defects. Poka Yoke helps people and processes work correctly the first time. It refers to techniques that make mistakes impossible to commit. These techniques eliminate defects from products and processes as well as substantially improve their quality and reliability.
I feel as though all the mistakes you mentioned highlights the fault in companies when it comes to understanding how to handle risk management. I agree that risk management and design control are separate things and that risk management should be treated like a checkbox activity that can be used to improve the design as its being designed as opposed to leaving the task for later in the development process. One thing I don't totally agree with that is considered a mistake is the use of the Failure-Mode and Effect Analysis (FMEA). I fell as though the FMEA is good assessment of potential risks for a product and should be considered in order to easily visualize all the risks and their severity. FMEA is a good predictor of whether or not a project is worth pursuing or not; however, I think the mistake the article mentions stems from this idea that risk management is being handled later the development process. If the FMEA is utilized early-on, it can save the company a lot of trouble. With that being said, I also agree with the notion that the risk management document should be a living document that is aggressively updated in order to cover things that may appear suddenly somewhere in the development process.
To change the way we think about risk, we must avoid making six mistakes.
1. We think we can manage risk by predicting extreme events.
2. We are convinced that studying the past will help us manage risk.
3. We don’t listen to advice about what we shouldn’t do.
4. We assume that risk can be measured by standard deviation.
5. We don’t appreciate that what’s mathematically equivalent isn’t psychologically so.
6. We are taught that efficiency and maximizing shareholder value don’t tolerate redundancy.
These mistakes that this article points out are very crucial as the previous mistakes mentioned above. I think that to ensure there aren't mistakes, the risk managements should be carefully reviewed over and over again.
References: https://hbr.org/2009/10/the-six-mistakes-executives-make-in-risk-management
I completely agree with the notion that risk management documentation should be considered a living document. I think that updating risk management documentation based off of feedback and complaints after its out on the market is important to improve processes as well as the quality of the product. This can also help identify products that needs to be recalled to prevent further problems with consumers which is troublesome and costly.
Point #4 - Risk Management is not a lifecycle process is one of the most common errors that occurs for most companies when they assess risk management. Risk management is done at the beginning stages of product development and theoretically should be updated accordingly and periodically as the product moves toward complete development. From my experience, I have noticed once a product is launched there are sometimes potential complaints from customers. Those complaints lead to CAPAs or multiple Change Orders to address the issue. One of the issues may potentially be changing the product such as the material. ALL risk management files would need to be addressed and updated if a material change, for example, were to occur. What I have noticed is that companies tend to just make the change and completely neglect the risk management and assume that the risk stays the same. Even if it does the company still needs to document it. When the company is audited this is a serious violation because Quality/Regulatory is failing to document a change that directly makes contact with a customer. I've seen Warning Letters issued because of this.
That's a good one. The differentiation between the Design Controls and Risk Management was well clarified. This is like a general idea. Whatever we work on, if there is any change from the prior planned method we should concentrate on the effects that it cause. It might be in a common game or a business, if there is a modification in the strategic approach into the world of competition, then twist and turns are to keenly monitored and certain measures to be taken. This is the simple idea which revolves in this article.
I also agree with the 4th example being a very important aspect of risk management. When a company conducts it own identification of risks and test they try to be very thorough. However, a company cannot identify all risk and issues which can arise with the product under various unknown circumstances. Therefor processes like change orders address and issue and hopefully by solving the issue lead to a better project. I also agree that the rick management should remain very active especially when changes are made, because this change may solve the first problem but it can lead to undiagnosed risk factor that could have been checked but were overlooked.
