Blog
November 18, 2021
If you’re in a regulated industry, you or your team has likely had to use Failure Mode and Effects Analysis (FMEA) for compliance. But because of the way regulated industries have to balance between the world of very strict quality standards and also high-velocity Agile processes, traditional FMEA has to evolve in order to meet the challenges that are arising in this new reality.
Rather than use FMEA steps to mitigate risk, you can fold the essence of FMEA into a more modern, holistic risk management plan to protect users, stakeholders, and your business from the gaps that traditional FMEA leaves behind.
How to Do FMEA Risk Assessment Without Leaving Gaps
Going through the process of risk analysis as FMEA steps outline is still valuable. An Agile risk management strategy should still include risk analysis. However, you also need to ensure that risk mitigation happens in the right way at the right time.
The key to this is thorough, detailed work on the front end so that the testing team understands the complete impact of a risk. They also need to understand the definition of done. And having traceability will ensure that everything is tested completely and at the right step in the production lifecycle.
FMEA Steps Redefined
Here is our list of recommended steps to conduct risk analysis and mitigation as part of a successful risk management strategy.
1. Collect the Requirements for Each Functionality, and Tie Them to Your Business Objectives
The person or team in charge of defining requirements needs to have an in-depth understanding of the product, its functionality, and the purpose of each functionality. They also need to know how to align requirements with the user journey and business strategy. All of this is critical information when conducting a risk analysis.
Remember that when you define your requirements, you also must articulate the definition of done. This is essential to Business Acceptance Testing. Do not leave room for misinterpretation from the testers. They need a very clear and detailed understanding of each requirement.
2. In a Standalone Document, Define the Risk(s) and Impact of Each Risk for the First Requirement
For every requirement, you will ask yourself what could go wrong. For example, if you’re building a motorcycle, one of your product requirements is a headlight. What does failure mean for that headlight? What could cause the headlight to fail? How does that impact the user? The business? The rest of the machine?
3. Assign a Risk Priority to Each Potential Failure
If the headlight fails during operation at night, the user’s life is at stake. If your company is at fault for the failure, your business could also be in grave danger. This is a very severe risk that must be mitigated early in production. Consider both the business risk and the safety risk when assigning priorities.
4. Define How to Prevent or Mitigate Every Potential Failure
This provides the information for all the positive and negative testing that must happen. Headlight failure, for example, could occur within the light itself. It could result from some connection failure, battery failure, or other failure within the motorcycle. In every instance, you need to define exactly how the components should work, and exactly what failure looks like.
In other words, define in detail what a positive test case looks like, and what a negative test case looks like. For the headlamp itself, when connected to power, it should turn on at [x] lumens. If that happens, it passes. If it does not illuminate at all, it fails. What happens if it illuminates, but is not as bright as specified? All possibilities must be articulated.
Again, you must be CRYSTAL CLEAR on what needs to be tested, and the definition of done. With remote and siloed teams being so common, it is more important than ever to give testers exact parameters and descriptions. (Find best practices for writing test cases here >>)
5. Repeat Steps 2-4 for Every Requirement
Spending the time to be thorough at the beginning of the product lifecycle will prevent costly backtracking and also keep you compliant.
6. Use a Traceability Tool to Tie Your Risk Analysis and Mitigation to Your Requirements
This will protect your workflow. Using a tool like Perforce ALM (formerly Helix ALM) allows you to fix a workflow against security groups, meaning a tester has to work within that flow. If there’s an exception for a test case within a specific requirement, for example, the tester cannot move forward without addressing it.
Perforce ALM’s end-to-end traceability also ties your testing and issues management to your requirements — which not only keeps production on schedule but also makes proving compliance much easier.
Learn More About Perforce ALM
In this on-demand video series, our expert walks through the top features in Perforce ALM that help teams to plan, track, and test development projects.
Additional Resources
Risk management and optimized testing are vital parts of the product lifecycle. To learn more about best practices in testing and risk management, watch our on-demand webinar Why Risk Management and Optimized Testing is Crucial in Product Development.
WATCH THE VIDEO NOW