Risk Management and Configuration Management

[alimary15]

Hello everyone.

Has anyone experience or advice on how to perform Risk Management when dealing with configuration management problems ?

I have a medical device which might comprise of several small " apps", instruments and platforms. The configuration can be chosen by the costumer. What is done so far is a Risk Analysis at the level of the single component, but no analysis is done looking at the complete package or interaction between components.

I am trying to establish a process that would allow to perform also Risk Analysis on the complete System ( the final b?ndle of apps and components that the costumer will get ). However I am facing the isssue of how to maintain the risk Analysis, and more in General the risk Management file when dealing with different versioning of the components/apps.

Has anyone any piece of advice or experience to share?

Thanks

 

[Wes Bucey]

Hello everyone.

Has anyone experience or advice on how to perform Risk Management when dealing with configuration management problems ?

I have a medical device which might comprise of several small " apps", instruments and platforms. The configuration can be chosen by the costumer. What is done so far is a Risk Analysis at the level of the single component, but no analysis is done looking at the complete package or interaction between components.

I am trying to establish a process that would allow to perform also Risk Analysis on the complete System ( the final b?ndle of apps and components that the costumer will get ). However I am facing the isssue of how to maintain the risk Analysis, and more in General the risk Management file when dealing with different versioning of the components/apps.

Has anyone any piece of advice or experience to share?

Thanks

You may be slightly off base in your understanding of "configuration management." In the generally accepted understanding of "configuration management" in the quality profession, we are referring to keeping obsolete versions of a design or product from being accidentally confused with current versions.

In your description, you are essentially dealing with different models of a current product and even the same model with different accessories. Think of an automobile for an analogy. A customer may order a car identical to his neighbor's except for color. The fact that one is blue and the other is red does not make one obsolete.

The problem is with the specialized jargon of the quality profession where one word "configuration" has a specific meaning different from a general dictionary definition.

In terms of risk management, we are on firmer ground. Still using the concept of an automobile as the analogy, there are some combinations of accessories on an automobile which may not interact well or even cause a dangerous risk. If, for example, we add air conditioning to a car, generally, we need to upgrade the electrical and engine cooling system to compensate for the extra load. If we put a high speed, powerful engine in, we probably need to upgrade the tires and braking system. If we put a high quality sound system in, we don't stint on the quality of the speakers, without making for an unhappy customer.

In terms of risk assessment, you could deal with the possible permutations of " apps", instruments and platforms similarly to auto manufacturers, since, I presume, you do not deliver the entire range of " apps", instruments and platforms to the customer for him to connect them together, but that he chooses from a catalog which of them, in what combination, he wants and your organization then delivers the completed assemblage, much as a car dealer delivers the model with the ordered accessories, color, etc. There may be as many as a hundred possible permutations. If each has unique risk factors, those are combined with the general risk factors of the basic device and the total risks are assigned to each particular permutation.

 

[alimary15]

You may be slightly off base in your understanding of "configuration management." In the generally accepted understanding of "configuration management" in the quality profession, we are referring to keeping obsolete versions of a design or product from being accidentally confused with current versions.

In your description, you are essentially dealing with different models of a current product and even the same model with different accessories. Think of an automobile for an analogy. A customer may order a car identical to his neighbor's except for color. The fact that one is blue and the other is red does not make one obsolete.

The problem is with the specialized jargon of the quality profession where one word "configuration" has a specific meaning different from a general dictionary definition.

In terms of risk management, we are on firmer ground. Still using the concept of an automobile as the analogy, there are some combinations of accessories on an automobile which may not interact well or even cause a dangerous risk. If, for example, we add air conditioning to a car, generally, we need to upgrade the electrical and engine cooling system to compensate for the extra load. If we put a high speed, powerful engine in, we probably need to upgrade the tires and braking system. If we put a high quality sound system in, we don't stint on the quality of the speakers, without making for an unhappy customer.

In terms of risk assessment, you could deal with the possible permutations of " apps", instruments and platforms similarly to auto manufacturers, since, I presume, you do not deliver the entire range of " apps", instruments and platforms to the customer for him to connect them together, but that he chooses from a catalog which of them, in what combination, he wants and your organization then delivers the completed assemblage, much as a car dealer delivers the model with the ordered accessories, color, etc. There may be as many as a hundred possible permutations. If each has unique risk factors, those are combined with the general risk factors of the basic device and the total risks are assigned to each particular permutation.

Thanks so much for your answer! It was very explanatory. So, getting back with configuration management, how would you deal with risks that are identified in v.1 of the product and then a v.2 of the product comes out? Are the risks from v.1 becoming part of the inherent design of the product for v.2? Do I start a risk analysis from scratch from v2? or do I need to keep all the risks identified in v.1 also in the risk analysis of v.2?

This topic is very confusing and I would really appreciate some help!

Thanks

 

[Wes Bucey]

Thanks so much for your answer! It was very explanatory. So, getting back with configuration management, how would you deal with risks that are identified in v.1 of the product and then a v.2 of the product comes out? Are the risks from v.1 becoming part of the inherent design of the product for v.2? Do I start a risk analysis from scratch from v2? or do I need to keep all the risks identified in v.1 also in the risk analysis of v.2?

This topic is very confusing and I would really appreciate some help!

Thanks

I sympathize with your confusion. Sticking to the auto analogy, everything about the risk assessment really requires an engineer's eye and training. Some seemingly silly things can cause a chain of consequences.

One example:
If we change to larger, higher quality tires because we increase the engine size, does that affect the odometer and speedometer readings?

In the quality profession, we use a process called Failure Mode and Effects Analysis (FMEA) as a starting point for most risk analysis. In its simplest form, FMEA asks:

1. What can possibly function differently from our plan if we change this detail?
2. If it functions differently, does that have a good or bad outcome for the user?
3. Does it affect the cost?
4. Does it affect the useful life?
5. Does it affect others (neighbors? environment? sales? reputation?)
6. Putting all things in balance, is this a worthwhile change to make?

In general, trying to take a shortcut by eliminating the steps in the FMEA may mean an unintended consequence occurs which can be a costly misstep for the organization.