If I were a PM running a risk management meeting, I would first create a timeline of events with my team from the time the device is shipped out of the manufacturing facility till the time it is implanted in the patient and even after that. Then we would work through the timeline, identifying any hazards that may occur at each step. This process creates a structured framework for identifying risks, and reduces the possibility of forgetting something. I personally like this approach better than just a brainstorming session where everyone tries to think of potential risks that may occur.

Similarly like srg36, if I was a PM running risk management meetings, I would schedule major and minor checkpoint meetings throughout the entire development process. Major meetings for when we complete a step in the development cycle, such switching from initial planning to conceptual design. Minor meetings to study any risks for when we want to add something to the product that we feel is beneficial that wasn’t part of the design previously. Basically what I’m saying is to have risk management meetings at any given point that a potential risk is created and when new risks are fond when a new phase is initiated in the development cycle. Leave no risk untouched.

I think it would be wise to get everyone familiarized before starting risk management meetings with the ISO 14971 standard. Before even running these risk management meetings it is important that everyone in the group that I am in charge of have a baseline understanding of ISO 14971 and basically what a risk/hazard is. Towards the beginning of the series for these meetings as a PM I would keen in on assessing the risk. This not only would be on the product but the whole process involved around the product encompassing the manufacturing process as well. The main focus of a lot of meetings I would host would be identify unacceptable risk first and then work my way down in severity.
It would also be important to get buy in subject matter experts not directly involved in the project to provide an outside perspective view on determining potential hazards with the product. Ultimately my main goals for the majority of risk management meetings would be to determine potential hazards and assess those risks. Once there is visibility to those risks, designation can be provided to individuals to work on risk mitigation that can then be discussed with the broader team during risk mitigation meetings.

Hello,

When we conduct a risk management meeting give an wide array of risk that can detail a project,identifying key risks and developing plans for preventing then or mitigating their adverse effects.Risk management consists of three steps:
1. conducting a risk audit : To conduct a risk audit, take stock of all the things that could go wrong with your project. Collect ideas widely , Identify internal risks , identify external risk.
2. Take action to avoid or minimize risk you've identified : Look at the risks that represent the wrong thins that could go wrong for your project and that are most likely to occur. With other risks,you may take steps to prevent them from escalating into full-blown crises.
3. Develop contingency plan : Develop contingency plan for unavoidable and uncontrollable risks. A contingency plan is a course of action you prepare in advance to advance to deal with a potential problem.

Risk management meetings always have the content that says about bad things going to happen and also about thinking about all adverse effects going to happen paper-works and formal procedures. So in this if I was a PA I would ask everyone to think about the risks associated. I would expect that ongoing battles would be controlled. I would even encourage them to bring up new ideas for risks. In the meeting I would bring up people with different backgrounds so that they bring up different fixations for different problems.

If I were a PM running a Risk Management meeting, I would ask the attendees of the meeting to have them familiarize themselves with with the ISO 14971 standard as @aij5 mentioned, and for them (i) come up with a list of risks (ii) analyze the potential risks using Failure Mode Effects and Criticality Analysis (FMECA) and Process (PMECA) to look at; how it could fail, the severity of the consequences, and the probability that it will fail and also considering the detectability that if something goes wrong the probability you can detect it (iii) come up with solutions on how to manage the risk (avoidance, mitigation, acceptance, and transference)> I think then it would be a productive meeting to see if people came up with the same/different lists, evaluations, and ways to manage these risks.

I worked on a project where we had to collaborate with a different company or our validation projects. Because I was more familiar with the system and they were basically adding to our current system I basically came up with the risk management system and the focus of the meetings. I found the best place that the resources that we were getting form the other company. Because our equipment that was being validated was linked to different processes, we had to include the user’s qualification and the process qualification. This increased out risk by a great deal simply because all the factor was affected by regulatory.

If I was running a risk management meeting, the first thing I would do is ask the team to review IS0 14971, because it is basically the bread and butter for risk analysis for medical devices. I would have a meeting to assess the the risk/hazards with the project team and other project managers, depending on how big this project is. As the leader of the meeting I would also bring awareness of the current risk statements if there are any, and ask the team to bring any new ideas for any the potential risk or hazard before the meeting(s). In the meeting, instead of identifying the risk or hazard and listing them, our goal would be to define the risk, by finding any cause and effect. Some questions that need to be brought up are, Why should this potential risk or hazard be considered? What is the cause of this issue, and is there any way to fix it? I would also go over a rating system. Which risk or hazards are critical or major, and which ones are minor.

If I was a PM running a Risk Management meeting, I would, as most mentioned above, get everyone attending the meeting to be familiar with ISO 14971. I would start by getting everyone to identify the possible risks. The next step would be to evaluate and address these risk. We would speak about the risk that may be possibly present throughout the whole life of this product. This would include inventory management, surgical team set-ups, the patients who will use the product, and the caregivers who will administer the products. It is important that we speak about every risk that is possible from the beginning of the product to the very end.

This is a very Interesting topic to Discuss on since its brings professional experience as well as new idea. As a PM i would first ask my team to study about the risk and complaints about other type of similar devices in the market and to make a list of it and later ask to check if our device has similar issues. After that I would ask my team to Divide those risk into various categories and go through each category one at a time and check what all Risk are associated. This would divide Bigger piece into smaller chunk and will make everyone to come out with more defined questions and risk.

As a PM running a risk management meeting, I'd focus on defining risks instead of identifying risks and make sure everyone in the meeting is clear on them. I would have a top-to-down breakdown of the risk sets with room for flexibility depending on how the meeting is going. After each risk set is presented, I would establish "next steps" with the team. Throughout the meeting, I would like the team to be engaged and help them think of risk management controls that could be implemented. Not everyone will agree with everything covered within the meeting but as PM, it should be responsibility to push everyone to be open-minded to potential risks and how to avoid/address them if necessary.

As a project manager the first thing I would do is brainstorm with my team all of the possible project and product risks in the initial risk management meeting. For future meetings I think it would be important to balance both a macroscopic and microscopic view of related risks. The major risks involved always need to be considered but time would also be devoted to addressing smaller risks that would only be relevant to the current phase of the project. Using a tool such as the risk matrix in the powerpoint, we would try to quantify these risks. Then we would discuss how to lower or limit these risks. After optimizing these risks, a decision would need to be made about whether or not each risk is acceptable and worth enduring. The last step would be documentation and creating a procedure for how to handle these risks.

Being a part of a team that handles various projects at a time, I have encountered and discussed many risks associated with my projects as well as my team's. One key aspect is to have all the projects, the stage they're in, the next steps, and risk factors all in an organized fashion such as in a spreadsheet. The next step is to, as mentioned by @smk45, define the risk and see what next steps it is affecting. Once all the risks are listed with each project, the next step involves prioritizing them. If one individual's projects all have a high risk, the team shifts resources and adds other individuals who have more lower-risk projects to help with the higher-risk projects. This allows each project to be addressed in an appropriate manner and allows the team to regroup and identify major risks as a benchmarking routine. This way all risks are managed and each project is still being attended to. Essentially, the main focus of the meeting should be on techniques and resources that will be used to asses and mitigate the risk of each project.

The risk management meeting must be conducted in detail to ensure that all possible risks are identified, prepared for, and avoided. Prior to a risk management meeting, as the project manager I would send attendees a brief overview of what will be discussed in the meeting to allow for individual brainstorming. I agree with other posts that moving forward through the timeline of the project to identify risks chronologically is an effective way to perform the meeting, and it is probably how I would choose to identify risks if I were a regular team member. However, since these meetings need to be detailed, I think it’s important to start it off by asking all team members how they would prefer to identify and define risks to ensure that everyone is comfortable enough to express their opinions. Allowing everyone to speak ensures that all risks are covered (even those that seem silly but may be detrimental to the project). After performing the selected technique to define risks and respective management plans, I’d send a follow up email to all attendees and stakeholders with risks discussed in the meeting, and in this email, I’d also schedule a second meeting. I think that proper risk management is crucial in a project to ensure that the project stays on track and nothing goes wrong. Therefore, one meeting is not enough to define all risks and their respective management strategies. Although a second meeting may be time consuming, it prevents much greater delays associated with defined risks. In regard to the number of risks defined, when should the project manager end a risk management meeting?