First, I'd want to make sure that everyone in the project understands what the device is, its purpose, its design, and how it will be processed. Once we understand the device and what is going to happen, we can then as a team decide together what we think the risks would be. Based on what we learned in lecture, we must consider the risks for the product, the product design and the manufacturing process. We will list risks accordingly based on product, product design, and manufacturing. Once the list of risks are determined we can move on to evaluating each risk by using the FMECA as suggested in lecture. Once evaluation is done, we will determine how to manage each risk based on its severity and whether we can accept it, avoid it, mitigate it, or go through transference. Once that's figure out, we can begin to develop solutions for those risks that need attention.

The Risk assessment meeting is an important part of any project. The risk assessment meeting should be a formal meeting conducted during the project’s planning process. First step is the project manager has to send a meeting invitation to all the attendees well ahead of time, so that they can review it and be prepared when it is time for the meeting. in real life, these people should be invited: project manager, project team, key stakeholders, subject matter experts, and project sponsors. Before the risk assessment meeting the project manager will have compiled a list of risks from previous projects. These will be reviewed at the beginning of the meeting as a way to not only identify some common risks but also as a catalyst to get the participants thinking about risks. Next, we should categorize the risks to identify duplicate risks and acts as to trigger for determining additional risks. The project manager then discusses the risks identified under each category with the participants. Now, we assign probability and impact to each risk. For the risks which have been identified with a high risk score, the participants will determine the triggers or causes and identify responses. After the meeting the project manager will combine all the risks and give the high scoring risks to the project management plan.

Adding to what was mentioned by amandaally1029 above after the risk analysis is completed in the FMECA technique; a critical decision must then be made by the heads of the company. That decision is: does this product’s risk outweigh the potential monetary gain that we hope to achieve though marketing the final design? This critical decision must be made in some of the very first risk assessment meetings so that time/ money/ and human resources are not wasted on a product/ device that is deemed too risky for that company to undertake. Although the product may be potentially extremely lucrative, it if also poses unavoidable unnecessary high risk, it may be scrapped for a less lucrative, more legally secure option. Most of the time, this is generally not an issue, however, I believe that this is an important situation to consider any time a life altering device is being proposed.

I agree with Mark about the formality, necessity, and process of a risk and with @dag56 about profit/risk scale. I think it would also be beneficial to have prior smaller meeting building up to this big scale meeting that Mark has mentioned. For examples, a meeting between all the engineers and scientist and PM to draw up the risks before all the profit, $ numbers from marketing dept. involve. It is always difficult to determine what's the best ratio for risk over benefit but I think seeing these risks separately and then together early on would help to make better decisions onward.

As others have said in this thread I think it is very crucial to ensure that everyone attending / participating in the risk management meetings have a thorough understanding of exactly how the product works. From there as a team you should break down all the different risks associated with these 3 categories: what risks / failures are associated with the product by the “design” of the product, what risks/ failures are associated with the product by the way the end user will “use” the product, and what risks / failures are associated with the product by the way the product is “manufactured”. As a team a list of the failures should be documented for each category and then prioritized.

Before the meeting the risk manager should compile a list of risks
The manager should also entertain a list of risks from the team
Categorize the risks for easy identification of duplicates
The manager should create a chart which will determine the region the risks fall in (this will help determine the probability and impact for that risk)
Risks that have been identified with high score, the participants will determine the triggers or cause and identify responses

To run a risk management meeting, first I would identify the technical experts that are related to that topic. Then I would get everyone in a room and I would have a brain storming session. I would first start by identifying the stakeholders. Then for each stakeholder that we brain stormed, I we would think about their individual risk associated with the topic. Then after this, I would use the risk matrix to determine the risk for each topic. This would be a very long meeting (at least 6 hours with a 2 hr break for lunch) and would only be about 10 people max. Too many people would make this a longer meeting and I wouldn't want to do that as it is already long enough. There will already be too much back and forth with 10 people in a room (why it would take 6 hrs). At the end, I would output a report on the meeting complete with meeting mins, action items, and a summary of what was decided in the meeting.

while many have mentioned FMECA as the main tool for identifying risk, I believe during the brainstorming process identifying risks, priority should be placed on the risk of the most critical parts of the device that cannot be avoided, followed by the risk on that can be mitigated or transferred, then lastly risks that can be accepted. this same procedure should be taken with level of parts with decreasing criticality until the entire device has been reviewed. by prioritizing types of risks during brainstorming, the risk identification process should require less rounds of analysis to properly document and address all risks involved.

The best strategy in running risk management meetings is to ensure understanding of the device. A basic understanding of the device components, it's functionality, and how the end user will be utilizing the device are all key in recognizing risks associated with the device. From the initial meeting onward a running list of potential risks should be updated at meetings and quality should be responsible in assessing any risks that are presented. Prior to conducting any trials there should be a comprehensive list of potential risks and the severity of those risks and strategies in neutralizing the risk would be discussed with the project team.

Risk management is an important aspect of business in order to have a successful product release. In terms of assuring that the final device run smoothly, these risk management meetings must occur on a constant basis. Problems arise throughout the project and these problems must be solved early on to prevent more damage or setbacks in the future. All of the previous answers posted provide a valid point in how these risk management meetings. I want to highlight the importance of risk identification and classification. There is always a trade off in the process of development so it is important to analyze which practices can be justified and which practices are not worth it. It is also important to keep an open meeting, meaning that different departments must have representatives so that everyone in the project is on the same page and has information to contribute.

I agree with markabdelshahed that a risk management meeting starts with the project manager sending a meeting invitation to all the attendees ahead of time so that they prepare themselves adequately for the meeting. Usually, the attendees would want to discuss about a risk, its characteristics, actions that they think can help and those they think would not help. The project manager need not to stop the contribution of these attendees because they are contributing connected lines of thought—they are not just throwing words for the sake of contribution.
Important risk management actions should be documented as soon as they arise in every risk management meeting because this helps to speed up the meeting. I also agree with merzkrashed that a strategy for breaking down the risks should be in place and that people should be prepared. To add on this, individuals should be advised to be more open-minded and realistic about the future possibilities. Meeting objectives should also be outlined right from the start.

For a Risk Management Meeting it's really important to have all departments heads. If there is any change in the design, then it affects all the further steps in a mild or a severe way depending upon the change. Whatever it is we have take everything into consideration. In regulatory, the changes should be checked whether it is under all the regulations to be followed. Also, in Preclinical the testing strategy might be changed due to any effects. This applies in Clinical trials also. Majorly Marketing people should give a detailed report about the profits and loss regarding the changes with respect to the customer details.

As others have mentioned, a thorough understanding and full participation from all members is crucial for a risk management meeting. In order to ensure unique thought and involvement, I feel that it would be best to have members analyze risks independently, drawing from their own backgrounds and then compiling the list of risks together for review. Then, it can be systematically discussed and clarified throughout the meeting. By having an independent analysis, members are less prone to prioritize the risks brought up by more prominent members in the meeting and thus less likely to overlook risks that may have otherwise gone unnoticed.

Risk management meetings in my opinion are the most successful with a great deal of varying backgrounds. When creating a risk document it is important to encompass all of the possible negative outcomes. For my company they are categorized by occurrence ad severity and then given a risk index from that point. The team is forced to try to list all of the possible issues that could occur with the device. This is why it is important to have not only engineers but also those from production, quality, and also the engineers in charge of production. They can all offer different information that would be vital to the meeting. In a meeting with only have the teams being represented in my opinion is a useless meeting.