Why I Used To Hate Risk Management (And 3 Ways to Change Your Mind Too)

June 30, 2019

Why I Used To Hate Risk Management (3 ways for mindset shift)-1

I hate Risk Management. There, I said it. And I’m not the only one actually. We’re all thinking it. Risk management is terrible!

It’s confusing and lengthy to get through. You have no real idea if you’ve covered everything or if you need to keep going further. And when you get into probabilities and severities, it feels like you’re just guessing.

Sound like your experience with risk management?

I guess I should clarify something. I used to hate risk management.

That’s because I used to be in a mindset that risk management meant FMEA and that I had to do it all by myself first, before we met as a team to review and discuss. And it seemed to be a never ending argument as opposed to a real discussion.

No one person or place is to blame for that. I’d been taught about FMEAs in college and been part of project teams that could argue for hours about how a harm could never happen with this device (only to find the harm listed in the MAUDE database for a predicate device the next day). It was a mindset that had developed over time and experience.

What changed all of that? ISO 14971.

I know, I know. It’s crazy. How did a standard about risk management completely change my opinion on risk management? (And how did I not know about it before??) I had never sat down and really read the standard. I’d read and followed my company’s SOPs, but hadn’t actually gone back to the source. Once I read and actually experienced risk management through a different lens, I came to enjoy it.

Now, I enjoy risk management and I like helping convert others to a new way of thinking about risk.

Want to enjoy risk management too? Here are 3 things to STOP doing today.


#1: Stop using FMEAs.

FMEAs have a time and place. But that’s not medical device product development risk management. I’ve written before about how confusing FMEAs are and why you should stop using them. When you use FMEAs, risk becomes a disjointed activity. Your application/use risk is in one document, your design risk in another, and your process risk in a third. You can easily lose sight of whether you’ve identified all of the harms. Plus, you’re constantly going back and forth between the documents to make sure you don’t accidentally use the wrong severity or different wording on a harm.

And that’s just the beginning. There are a lot of things to hate about FMEAs.

So what should you do instead? Use the approach in ISO 14971. Define the Hazards, Foreseeable Events, Hazardous Situations, and Harms. It’s a lot more straightforward. More importantly, stop separating out application/use, design, and process! These all belong together, in one place, so you can have a more holistic approach to risk.


#2: Stop thinking about risk so late in the project.

One of the biggest challenges with risk management is that we start it too late. I see so many people (my former self included), who start risk after they’ve already gotten a working prototype and are doing some benchtop testing. At that point, you’ve already made so many design choices related to risk mitigation, that you don’t stand a chance of those risk discussions going well.

Have you tried to identify foreseeable events only to have another team member say, “that can’t happen because I made this feature to prevent that?” That’s how you know you started too late. Now, instead of being able to work as a team to identify what might actually go wrong and the best options to mitigate, you get to argue with the engineer who designed a “fix.” They don’t want to acknowledge that there might be a better solution to the problem and they don’t want to document the foreseeable event, because in their mind it can’t possibly happen.

Imagine if you had started risk at the beginning. You could talk about the foreseeable events that might occur, work as a team to brainstorm different solutions, and get “credit” for risk reduction efforts that the team is doing. And if you have your application/use and design related foreseeable events all in one location, you’re more likely to be able to come up with a solution that address multiple event, as opposed to a single one.


#3: Stop assigning probabilities to events.

ISO 14971 defines risk as the probability of occurrence of harm.

It does not define it as the probability of occurrence of the event!

Yes, there is an appendix that talks about using P1 and P2 to calculate the probability. But the standard uses those to calculate the probability of occurrence of the harm and goes so far as to define it in the terms and definitions section.

At the end of the day, it doesn’t matter how likely any one event is to occur. What matters is how likely a harm is to occur. By focusing on the event, you could reduce the probability of a bunch of different events, but still have a harm that likely to occur. It’s even easier to miss if you don’t follow step 1 and have a disjointed risk approach.

These 3 simple things have completely changed my thoughts on risk management. I used to dread risk meetings. I tried everything I could think of to better organize or prepare for the meetings, but no matter what I tried, it ended in an argument or we made no progress.

As I started to incorporate these 3 simple things in my approach to risk management, everything changed. For the first time, no one was confused about what items fit where. No one was arguing that they’d already mitigated it and didn’t need to include it. No one was dragging their feet on getting it done.

However the most important thing of all, was that our approach to risk management led to better designed AND safer products. At the end of the day, that’s the most important thing of all.

Looking for a Risk Management + Design Control solution to help you bring safer medical devices to market faster with less risk?  Click here to take a quick tour of Greenlight Guru's Medical Device QMS software →


Jesseca Lyons is a Senior Medical Device Guru at Greenlight Guru and a Mechanical Engineer by trade who loves working with cross functional teams, including both engineering and non-engineering disciplines. She’s spent most of her career gathering and defining requirements for new product design and development in the...

Risk Management Software for Medical Devices
See Demo Now
risk software on computer
Search Results for:
    Load More Results