No products in the cart.
MODULE 15: PROJECT MANAGEMENT FOR INFORMATICS INITIATIVES
Section 15.3: Risk Assessment and Mitigation Strategies
A core task for a pharmacist is preventing harm. In project management, this is called risk assessment. Learn how to systematically identify potential project risks (technical, clinical, financial), assess their probability and impact, and develop proactive mitigation plans before they become project-derailing problems.
SECTION 15.3
Risk Assessment and Mitigation Strategies
Applying Your Clinical Foresight to Ensure Project Health and Safety.
15.3.1 The “Why”: The Pharmacist as a Professional Risk Manager
At its core, the practice of pharmacy is the practice of risk management. Every single day, with every prescription, you are actively identifying, assessing, and mitigating risks to patient safety. When you perform a prospective drug utilization review (DUR), you are not merely processing data; you are hunting for risks. Is there a drug-drug interaction? (a clinical risk). Is the dose appropriate for the patient’s renal function? (a toxicity risk). Is this medication affordable for the patient? (an adherence risk). Does the patient understand how to take it correctly? (an educational risk). Your entire clinical skillset is built upon a foundation of proactive foresight—of looking at a seemingly straightforward situation and asking, “What could go wrong here, and what can I do to prevent it?”
This ingrained clinical mindset is the most valuable and transferable skill you bring to informatics project management. A project, like a patient’s medication regimen, has a desired therapeutic outcome. And just like a medication regimen, a project is susceptible to a host of potential adverse events that can jeopardize that outcome. Project risk management is the discipline of applying your pharmacist’s foresight to the health of the project itself. It is the systematic process of identifying potential problems before they occur, assessing their potential severity, and developing a plan to deal with them.
Many people new to project management view this process as negative or pessimistic—a “doom and gloom” exercise. This could not be further from the truth. Professional risk management is an act of profound optimism. It is built on the belief that by anticipating challenges, you can overcome them. It is the practice that separates a project that is constantly in a state of reactive firefighting from one that navigates challenges with control and confidence. An informatics pharmacist who masters risk management is not just a subject matter expert; they become a trusted leader who can be relied upon to deliver projects that are not only clinically sound but also on time, on budget, and on scope, because they have professionally prepared for the inevitable turbulence of any meaningful change initiative.
Retail Pharmacist Analogy: Launching a High-Risk REMS Drug Service
Imagine your pharmacy has been selected to dispense a new, complex specialty medication for a rare disease. This drug has a strict, mandatory Risk Evaluation and Mitigation Strategy (REMS) program required by the FDA due to its significant potential for adverse effects.
Your “project” is to launch this new service safely and successfully. Before the first bottle even arrives, your clinical risk management brain goes into overdrive. You are not just thinking about the dispensing workflow; you are thinking about everything that could possibly go wrong. This is an informal risk identification session:
- Clinical & Safety Risks: “The REMS requires a negative pregnancy test within 7 days of every dispense. Risk: What if we miss this and cause a catastrophic birth defect? The patient needs monthly liver function tests. Risk: What if we dispense without confirming the latest labs are within range?”
- Operational & Workflow Risks: “The documentation for the REMS is extensive and must be submitted to the manufacturer within 24 hours of dispensing. Risk: What if the staff isn’t trained on the specific platform? What if the fax machine fails? Risk: What if our primary pharmacist is sick and the covering pharmacist has never dispensed a REMS drug?”
- Financial Risks: “This drug costs $10,000 per month. Risk: What if we dispense it and the prior authorization is retroactively denied, leading to a massive financial loss? The copay could be thousands. Risk: What if the patient can’t afford it, leading to prescription abandonment and wasted inventory?”
- Technical Risks: “The REMS requires us to log into a specific web portal. Risk: What if that portal is down on the day the patient needs their medication? Risk: What if our pharmacy software doesn’t have a good way to flag these patients for their specific REMS requirements?”
You have just identified a list of threats. Now, you instinctively start planning responses. To mitigate the clinical risk of missing a lab test, you create a mandatory, hard-copy “REMS Dispensing Checklist” that must be physically signed by the pharmacist. To transfer some of the financial risk, you implement a policy that you must have a written confirmation of authorization from the insurance company before ordering the drug. To avoid the risk of an untrained pharmacist dispensing the drug, you limit dispensing to only two certified pharmacists. This entire proactive, defensive, and structured thought process is the essence of project risk management. You are applying it to protect a patient; in informatics, you will apply it to protect a project.
15.3.2 The Formal Risk Management Process: A Pharmacist’s Playbook
While your clinical intuition is a powerful starting point, formal project management provides a structured process to ensure that risk management is thorough, consistent, and documented. This process is a continuous cycle that begins during planning and continues until the project is closed. It transforms risk management from an anxious, informal activity into a clear, professional discipline.
The Continuous Cycle of Project Risk Management
1. Identify Risks
2. Analyze Risks
3. Plan Responses
4. Implement & Monitor
Step 1: Risk Identification – Leaving No Stone Unturned
The goal of risk identification is to create a comprehensive list of potential events that could positively or negatively affect your project. This is not a task to be done alone in a dark room. The most effective risk identification is a collaborative effort that leverages the collective knowledge and experience of your entire project team and key stakeholders. Your job as the project lead is to be the facilitator, to ask probing questions, and to create an environment where people feel safe to voice concerns and potential problems.
Masterclass Table: Techniques for Identifying Project Risks
| Technique | Description | How to Apply It (Informatics Example) |
|---|---|---|
| Brainstorming | A facilitated group session where the project team and stakeholders generate a list of potential risks. The key is to encourage open thinking and defer judgment until all ideas are captured. | You schedule a one-hour “Risk Brainstorming” meeting. You put up a whiteboard and ask a simple question: “Thinking about our goal to implement a new BCMA system, what are you worried about? What could go wrong? What could be a roadblock?” |
| Expert Interviews | Conducting one-on-one interviews with individuals who have experience with similar projects, either within your organization or outside of it. | You have coffee with an informatics pharmacist from a neighboring hospital that implemented the same BCMA system last year. You ask: “What were your biggest ‘gotchas’? What do you wish you had known before you started?” |
| Documentation Review | A thorough review of all project documents created to date, paying special attention to the assumptions, constraints, and dependencies listed in the scope statement. Every assumption is a potential risk if it proves false. | Your scope statement has an assumption: “It is assumed the hospital’s existing Wi-Fi network has sufficient coverage in all medication rooms.” This immediately becomes a risk: “The Wi-Fi network may have dead spots, preventing nurses from scanning medications.” |
| Checklists & Historical Data | Using a pre-existing checklist of common risks for healthcare IT projects, or reviewing the “lessons learned” documents from past projects at your organization. | Your department has a shared drive with files from a CPOE implementation five years ago. You find the “Lessons Learned” document, which states: “We severely underestimated the time needed for provider training, leading to frustration and poor initial adoption.” You add “Inadequate provider training” to your risk list. |
| Root Cause Analysis | A technique for digging deeper into a stated problem to find the underlying cause. A common method is the “5 Whys.” | A stakeholder says they are worried about “user resistance.” You ask: 1. Why? “Because they hate change.” 2. Why? “Because they feel new tech is forced on them.” 3. Why? “Because they aren’t involved in the design.” You’ve identified a deeper, more actionable risk: “Lack of end-user engagement in system design.” |
The Risk Register: Your Central Repository of Truth
As you identify risks, you must document them. The Risk Register is the single, living document that will serve as the repository for all risk management activities throughout the project lifecycle. It starts simple during identification and grows in detail as you move through analysis and response planning.
Initial Risk Register Template
At the identification stage, your risk register can be a simple spreadsheet. The crucial part is to give each risk a unique ID and to phrase the risk statement clearly, often using a “Cause -> Risk -> Effect” structure.
| Risk ID | Date Identified | Identified By | Risk Statement (Cause -> Risk -> Effect) | Category |
|---|---|---|---|---|
| R-001 | 10/18/2025 | You | Due to known gaps in the hospital’s wireless infrastructure (Cause), there is a risk that the BCMA scanners will have intermittent connectivity (Risk), which could lead to nurses reverting to manual documentation overrides and negating the safety benefits of the system (Effect). | Technical |
| R-002 | 10/18/2025 | Nurse Champion | Because the new BCMA handhelds are a different brand than the previous devices (Cause), there is a risk that experienced nurses will find the new workflow clunky and slow (Risk), which could lead to widespread user dissatisfaction and resistance to adoption (Effect). | Clinical/Workflow |
Step 2: Qualitative Risk Analysis – Separating the Monsters from the Mice
A thorough brainstorming session can generate a list of 50, 100, or even more risks. It is impossible and inefficient to develop a detailed mitigation plan for every single one. The purpose of qualitative risk analysis is to rapidly triage and prioritize your list of identified risks. This process allows you to focus your time and energy on the “monsters”—the high-priority threats that pose the greatest danger to your project—while setting aside the “mice” for simple monitoring.
This is a subjective process that involves assessing two key dimensions for each risk: its probability (or likelihood) of occurring, and its potential impact on project objectives if it does occur.
Defining Probability and Impact Scales
To perform this analysis consistently, you must first define scales for probability and impact. These are often tailored to the specific organization or project.
Probability Scale
| Rating | Score | Description |
|---|---|---|
| Very High | 0.9 | Almost certain to occur (>80% chance) |
| High | 0.7 | More likely to occur than not (60-80% chance) |
| Medium | 0.5 | Could occur (~50/50 chance) |
| Low | 0.3 | Unlikely to occur (20-40% chance) |
| Very Low | 0.1 | Highly unlikely to occur (<20% chance) |
Impact Scale (on Project Schedule)
| Rating | Score | Description |
|---|---|---|
| Very High | 0.8 | Causes >20% schedule slippage; catastrophic delay |
| High | 0.4 | Causes 10-20% schedule slippage; major delay |
| Medium | 0.2 | Causes 5-10% schedule slippage; noticeable delay |
| Low | 0.1 | Causes <5% schedule slippage; minor delay |
| Very Low | 0.05 | Negligible impact on schedule |
Note: Separate impact scales would be defined for other objectives like budget and scope/quality.
The Probability-Impact Matrix: Visualizing Priority
Once you’ve assigned a probability and impact rating to each risk, you can plot them on a Probability-Impact Matrix. This simple grid is an incredibly powerful tool for visualizing which risks demand your immediate attention. The risk score is often calculated by multiplying the probability score by the impact score. This score determines the risk’s color and priority.
Probability-Impact Matrix
Very LowLowMediumHighVery High
Low
Medium
High
High
V. High
Low
Medium
Medium
High
High
V. Low
Low
Medium
Medium
High
V. Low
V. Low
Low
Low
Medium
V. Low
V. Low
V. Low
V. Low
Low
Impact
Example Analysis:
For our risk R-001 (Wi-Fi dead spots), you interview the IT team. They confirm the problem is well-known. You rate the Probability as “High” (0.7). The impact on the project would be catastrophic, as it would undermine the entire system, so you rate the Impact as “Very High” (0.8). The risk score is 0.7 * 0.8 = 0.56. This lands squarely in the dark red, “Very High” priority zone. This risk requires an immediate and robust response plan.
Step 3: Plan Risk Responses – Your Proactive Playbook
Once you have prioritized your risks, it’s time to decide what you are going to do about them. For every medium or high-priority risk, you must develop a response strategy. The goal is to create a specific, actionable plan that, if implemented, will alter the risk’s profile—either by reducing the threat or enhancing the opportunity. This is where your problem-solving skills as a pharmacist truly shine.
Masterclass Table: Strategies for Responding to Negative Risks (Threats)
| Strategy | Goal | When to Use It | Informatics Example (BCMA Project) |
|---|---|---|---|
| Avoid | Eliminate the threat or protect the project from its impact. This often involves changing the project plan. | Used for high-impact, high-probability risks where other strategies are ineffective. When the risk is simply too great to accept. | Risk: A new, unproven brand of handheld scanners has a high risk of software bugs. Response: We avoid this risk by changing the project scope to use the hospital’s existing, proven scanner hardware, even though it’s older. |
| Transfer | Shift the responsibility and consequence of the risk to a third party. This does not eliminate the risk, but passes ownership of it. | When the risk is financial or specialized, and another party is better equipped to handle it. Common in contracts and insurance. | Risk: The vendor’s implementation timeline is aggressive, and any delays on their part will delay the whole project. Response: We transfer this risk by including a clause in the vendor contract that specifies financial penalties for each week of delay caused by the vendor. |
| Mitigate | (Most Common Strategy) Take proactive action to reduce the probability of the risk’s occurrence and/or its impact if it does occur. | Used for most moderate-to-high risks. It involves actively working to make the risk less dangerous. | Risk: Widespread nurse dissatisfaction due to a clunky workflow. Response: We mitigate this risk by (1) creating a Nurse Champion advisory group to provide input during the design phase, and (2) scheduling extra “at-the-elbow” support on all units for the first two weeks post-go-live. |
| Accept | Acknowledge the existence of the risk but make no proactive plan to address it. A decision is made to deal with the consequences if it occurs. | Used for low-priority risks (low probability and low impact) where the cost of the response would outweigh the potential harm. | Risk: A key physician stakeholder may miss one of the weekly status meetings due to a clinical emergency. Response: We accept this risk. The impact is low, and we can catch them up via email. We will not reschedule the meeting for one person. |
Finalizing the Risk Register
After this step, your Risk Register is now a powerful project management tool. For each identified risk, it should now contain not only the description and priority, but also a designated Risk Owner (the single person responsible for monitoring the risk and implementing the response) and the detailed Response Plan. This document is no longer just a list of worries; it is a proactive playbook for navigating uncertainty and protecting your project’s success.
