Martin Novich’s Post

Risk Priority Number (RPN) is your go-to metric for navigating the complex terrain of risk analysis. It's like the GPS for your project's risk management, guiding you to prioritize risks effectively. #fmea #leansixsigma

Risk Matrix Unveiled 🚦 https://lnkd.in/eamDGwP 🚨 Risk Alert: Are you leveraging the power of RPN in your risk assessments? Risk Priority Number (RPN) is your go-to metric for navigating the complex terrain of risk analysis. It's like the GPS for your project's risk management, guiding you to prioritize risks effectively. Here's how it works: Severity (S) ⚠️: How severe would the impact be if the risk materialized? Rate from 1 (least severe) to 10 (catastrophic). Occurrence (O) 🔁: What's the probability of the risk occurring? Score it from 1 (unlikely) to 10 (almost certain). Detection (D) 🔎: Can you catch the risk before it wreaks havoc? This is your chance to assess detection from 1 (easily detected) to 10 (sneaky and elusive). Multiply S, O, and D for the RPN value and let the Risk Priority Matrix guide your action plan. Prioritize with clarity: High (H): Action is needed as soon as possible! Medium (M): Keep an eye on it. Low (L): Monitor, but lower urgency. Remember, a color-coded system will help you visualize the priority: 🔴 Red: Defcon 1 risks! Immediate action is required. 🟡 Yellow: Caution advised, consider action. 🟢 Green: Risks accepted, breathe easy (for now). But watch out for the pitfalls of RPN! No number is too high or too low to ignore. An RPN of 13? That's a no-go in this matrix. And two risks with the same RPN might not be equally threatening. Always remember, there's no one-size-fits-all RPN. Your company's risk appetite and the maturity of your product or process are key to defining what's acceptable. 🔗 Connect the dots in your risk management strategy and lead your projects to success with confidence. #RiskManagement #ProjectManagement #RPN #SafetyFirst #ContinuousImprovement #QualityControl #ProcessOptimization

𝐓𝐡𝐞 𝐏𝐫𝐨𝐜𝐞𝐬𝐬 𝐨𝐟 𝐄𝐯𝐚𝐥𝐮𝐚𝐭𝐢𝐧𝐠 𝐎𝐩𝐭𝐢𝐨𝐧𝐬 Evaluating options is about considering and assessing the options that are available to address the business problem or issue, and presenting proposals for change to senior management in the form of a business case. There are four main elements to this work: - identifying the options available; - reducing the possible options to a more manageable      shortlist; - preparing the elements of a business case; - presenting the business case to management for decision-making. 𝐈𝐝𝐞𝐧𝐭𝐢𝐟𝐲 𝐨𝐩𝐭𝐢𝐨𝐧𝐬   This involves getting as comprehensive a list as possible of the options available, without eliminating any too early (before they have been properly considered). 𝐒𝐡𝐨𝐫𝐭𝐥𝐢𝐬𝐭 𝐨𝐩𝐭𝐢𝐨𝐧𝐬  The initial ‘longlist’ of possible options needs to be whittled down to a more management set that can be considered more carefully. This can be done by using SWOT analysis or PESTLE and also by employing feasibility analysis or force-field analysis. 𝐏𝐫𝐞𝐩𝐚𝐫𝐞 𝐛𝐮𝐬𝐢𝐧𝐞𝐬𝐬 𝐜𝐚𝐬𝐞  For the selected option (and maybe for the key alternatives too), the business case now needs to be constructed. The issues to consider here are: cost–benefit analysis – contrasting the expected costs of the option with its predicted benefits; impact analysis – identifying and assessing any non-cost impacts of the proposed change, such as new ways of working; risk analysis – identifying the risks to success and possible countermeasures; investment appraisal – putting the (financial) costs and benefits together to see whether the project pays for itself. 𝐏𝐫𝐞𝐬𝐞𝐧𝐭 𝐛𝐮𝐬𝐢𝐧𝐞𝐬𝐬 𝐜𝐚𝐬𝐞  Finally, the various elements of the business case need to be presented to senior management for their decision. This can involve either, or usually both, of business case report creation and business case presentation. Thank you for your valuable time.

Poorly documented risks make issues spiral out of control down the road. Documenting risks is easier than you think - if you know the framework. Here's the best way to write risk statements. Write your risks in this framework:
 If [this event happens], then [that impact will happen]. Here are 3 examples: Example 1: Bad risk statement: Vendor availability. Good risk statement: If ABC vendor doesn’t supply parts on time, then we must buy from an alternative vendor with a 10% higher cost. Example 2: Bad risk statement: Technical issues Good risk statement: If the subsystem A and subsystem B integration isn’t done by September 15th, then the system release will be delayed by 6 weeks. Example 3: Bad risk statement: Lack of stakeholder engagement Good risk statement: If we don’t fully engage all stakeholders during the requirements phase, then the project schedule will be delayed by change requests during the execution phase. Your goal is to make risks statements: Understandable and actionable. Specific and succinct. Clear and complete. Writing risks like this transforms muddled ambiguity into manageable action. And helps you keep potential issues from spiraling out of control.

How to identify system constraints(bottlenecks) Constraints are an inevitable part of any system. The presence of constraints is a big opportunity knocking the door. Only through constraints, can a pathbreaking improvement emerge. But, only if the constraint is correctly identified. ‘Non-constraints’ , generally, disguise as constraints and we end up taking actions on these. And all the potential improvements remain unexplored. The real constraint , on the other hand, has a tendency to appear as a ‘non-constraint’ and create a ‘Mirage’. The following approach can be adopted to identify the real constraints: 1. The process where the real constraints reside, are sluggish, slow paced and full of inertia. There will be a lot of protocols to break their immobility. 2. There will be a huge WIP pile up at the constraint process, and such process owner is helpless in improving the situation, even if they wish to. (** if it’s a capacity issue, surely the non constraint process in the upward chain are over producing). 3. Generally, a constraint would be at a place where there are multiple interventions ( workflow, people, platforms). 4. The process having constraints will exhaust all the available buffer. 5. Mostly, the constraint would be at workflow change junction ( 1 person to the 2nd, 1 dept to the 2nd). 6. The constraint process would always be of prime importance in the terms of performance indicators. Constraints, like energy, cannot be destroyed or eliminated completely. But can be made mobile within the system boundaries. A stagnant constraint is an indicator of a bad system design. If a constraint is mobilized within the system, it will strike at several places with reduced and manageable intensity. Ways to manage a constraint: 1. Re-structure the workflow ( including roles and responsibilities) so that the constraint doesn’t stagnate at workflow intersections. 2. Reword new rules that will relax constraint management protocols. 3. The process owners within the entire workflow, must align to restructured and reworded norms till further review. After implementation of the above approach, review the process performance periodically. A min time of 2 months must be given for the new approach to demonstrate its effectiveness. While reviewing, ensure that the constraints have moved to other processes but are manageable. 3.

Risk Matrix Unveiled 🚦 https://lnkd.in/eamDGwP 🚨 Risk Alert: Are you leveraging the power of RPN in your risk assessments? Risk Priority Number (RPN) is your go-to metric for navigating the complex terrain of risk analysis. It's like the GPS for your project's risk management, guiding you to prioritize risks effectively. Here's how it works: Severity (S) ⚠️: How severe would the impact be if the risk materialized? Rate from 1 (least severe) to 10 (catastrophic). Occurrence (O) 🔁: What's the probability of the risk occurring? Score it from 1 (unlikely) to 10 (almost certain). Detection (D) 🔎: Can you catch the risk before it wreaks havoc? This is your chance to assess detection from 1 (easily detected) to 10 (sneaky and elusive). Multiply S, O, and D for the RPN value and let the Risk Priority Matrix guide your action plan. Prioritize with clarity: High (H): Action is needed as soon as possible! Medium (M): Keep an eye on it. Low (L): Monitor, but lower urgency. Remember, a color-coded system will help you visualize the priority: 🔴 Red: Defcon 1 risks! Immediate action is required. 🟡 Yellow: Caution advised, consider action. 🟢 Green: Risks accepted, breathe easy (for now). But watch out for the pitfalls of RPN! No number is too high or too low to ignore. An RPN of 13? That's a no-go in this matrix. And two risks with the same RPN might not be equally threatening. Always remember, there's no one-size-fits-all RPN. Your company's risk appetite and the maturity of your product or process are key to defining what's acceptable. 🔗 Connect the dots in your risk management strategy and lead your projects to success with confidence. #RiskManagement #ProjectManagement #RPN #RiskAssessment #SafetyFirst #ContinuousImprovement #QualityControl #ProcessOptimization Sharpen your decision-making skills and navigate risk like a pro! 🚀🎲 Source: Manickavasagam Natarajan

Every business needs to adapt and change to an ever evolving environment. Whether its new regulations, organizational changes, new business processes, new equipment, change is always difficult to manage and can lead to business interruption. What are the most challenging changes you face? I'd like to learn more and discuss how we can reduce or eliminate this risk from your business. Please feel free to send me a private message to discuss. www.visiumkms.com

Identifying and Managing Project Risks All projects have risks and it’s important to recognize these risks and to develop an effective risk mitigation strategy that addresses them. Project risks fall into three categories: Known Risks Those risk elements that are apparent from an analysis of the RFP, your proposed approach and the contract Terms and Conditions ·     Schedule ·     Technical requirements ·     Assumptions in solutions and/or pricing    Predictable Risks Those risk elements that experience tells us have a real probability of occurring and you must have a plan to resolve them if they occur ·     Late customer approval of key deliverables ·     Delay in invoice processing ·     Personnel turnover Unpredictable Risks Those risk elements that could happen, but the likelihood or timing of these events cannot be predicted in advance ·     Changes in key customer personnel ·     Subpar equipment and/or personnel performance Risk mitigation approaches that are effective in addressing these risks are like medical approaches for treating ailments, e.g. Preemptive Risk Mitigation Approaches (Preventive care, e.g. vaccine) ·      You recognize the potential risk, and you take action to reduce its probability of occurrence ·     These risks and risk mitigation approaches are included in your proposal ·      As an example, you might identify a back-up plan to segments of your proposed approach in case something goes wrong  Indirect Risk Mitigation Approaches (Attacks symptom, but not the disease, e.g. aspirin) ·      Something has gone wrong that threatens contract performance and you must do something quickly to survive in the near term until a solution to the real problem is identified ·     It is important to recognize these mitigation approaches do not address the actual problem itself. They are only necessary short term, stop gap solutions ·      One such example is the use of a management reserve to address a cost overrun  Direct Risk Mitigation Approaches (Attacks the risk itself, e.g. radiation to attack cancer) ·     Like preemptive risk mitigation approaches, these risk mitigation approaches are employed when the original plan fails to produce the desired results ·      For example, if you are behind schedule, you might add additional staff to the project or you might replace underperforming personnel Every successful federal government proposal identifies contract performance risks and has an approach to mitigate them. By doing so, you alert the proposal evaluators of these risks and may differentiate yourself from your competitors if they fail to address them. To learn more about how to address project risks in your proposal go to https://lnkd.in/eH5rwPNp

Single Point of Failure. I was doing some #businessprocessmapping for a client over the last two months and found myself trying to redesign some processes such that they have a single point of failure. That’s an aggressive term for what is actually a system constraint – borrowing from the #TheoryofConstraints. What I was looking to do was optimise and manage that single point in every sub-system. The idea was to automatically prioritise where to look should there be a failure in the system. If we shift the opportunities of failure closer to the single point then we have fewer points to optimise and manage – ideally, we just have the one point in the system. It then allows us to put mitigation plans in place around that single point. This redesign worked beautifully because we started to see a system failure before it happened. The symptoms started showing upstream and pointed to only one place to look. We began to mitigate knowing that there were just a small set of variables that were leading to the failure and required managing. We were able to keep the sub-system flowing by only needing to manage the single point of failure. Granted it required some capable eyes to see the failure coming in good time. I haven’t yet seen any cons of this idea. Next step is to introduce a ‘Poka-Yoke’ element at one of the points in a single sub-system to see what overall efficiency impact it has on the entire system. On paper it should result in higher overall quality of product and service. #systemsdesign #projectmanagement

Predetermined Change Control Plan (PCCP). I made a mindmap to wrap my head round key points in the recently-published FDA final guidance on PCCP, together with thoughts on how LLM-based AIaMD in particular might be affected, and how we might react under UK & EU regulations. The exercise highlighted to me that the PCCP is itself quite some document; it relates closely to the Intended Use Statement (IUS), always the first submission document that we create with our clients as "Modifications included in a PCCP must maintain the device within the device’s intended use, and as applicable, must allow the device to remain substantially equivalent to the predicate device. "; that design change control needs, in the change impact analysis, the point of whether a proposed change is in scope of the PCCP or out of scope, requiring resubmission like a Special 510(k); and that proposed changes to the PCCP itself (let alone IUS) require a resubmission to the FDA (makes sense). Let's see how that pans out in the UK, as PCCP is mentioned in the public consultation, and in the EU (I haven't opened the consultation questionnaire yet, I must admit, to see if & how PCCP may be mentioned) - can anyone enlighten me please on the EU position, or that of Team-NB or any other such body?