Risk Management in Software Quality?

Question

All who are working in Software Industry know that Risk Management is vital part of the Software Quality too. Even for non-IT industry Risk management is equally important, as the Risk might have high impact on the cost, quality, delivery, people and other areas.

But when I read about this topic (as I already searched a lot for this) I am not able to satisfy myself with the information. I have some questions and doubts related to this topic.

1. Some link says that Risk Management should be part of Test Plan and some lays emphasis on it inclusion in Project Plan, I think it is not right to write same risk at two places and tracking them down at two different locations will increase effort. So, which plan should actually contain Risk Management, or it should be completely a separate document?

Multiple times I hear about the term Risk Mitigation and Risk Contingency plans, during Risk Management.

2. What actually Risk Mitigation and Contingency are (few examples will really be helpful for me)?
3. Sometimes, I found that only Mitigation plan is more used and known to persons, but not enough information is there on Contingency plan. Why is that so?
4. Whose responsibility is to define Mitigation and Contingency plan? As in our project anybody goes to the Risk register and write something in it. But there should be some industry level standards on who should define which plan. What are those standards and guidelines?
5. Most of the time, the person defining the Risk also covers the Risk in the Mitigation plan. I think this should not be allowed. Do you agree?
6. Both Risk Management and Incident Management are same or different? If different then what line differentiates between them?

Answer 1

I'm going to skip answering the parts of the question that do not make sense or are primarily opinion based.

1. So, which plan should actually contain Risk Management, or it should be completely a separate document?

Most software organizations don't do this at all or are not formal about it, so you can probably do whatever you want. If you think it actually matters, you need to consult someone in your organization, or your customer, or your contract with your customer, or the standards document that your contract with your customer refers to.

2. What actually Risk Mitigation and Contingency are (few examples will really be helpful for me)?

The difference is subtle. You have a plan for something -- call it Plan A -- and you are concerned about Something Going Wrong. You mitigate a risk by taking measures that will lower the impact if Something Goes Wrong. A contingency is a Plan B, an alternative you can use if Something Goes Wrong that makes Plan A impossible.

Here's an example. Let's say you are planning for a deployment of a new release this weekend. This release has some new features that are really complicated, and it's possible some of them might have serious bugs. A mitigation plan might be to pay the entire development team to be on site this weekend in case something goes wrong. A contingency plan might be to roll back to the previous release until the bugs can be fixed and tested.

Note the distinctions between the plans in the example. With the mitigation plan, we take measures to make Plan A successful even if something goes wrong. With the contingency plan, we have a Plan B for when Plan A fails. Also, the mitigation plan calls for doing something extra (besides planning) before or during Plan A, whereas the contingency plan does not necessarily call for doing anything extra unless Plan A fails.

There's nothing to prevent you from having a mitigation plan and a contingency plan. The real point, I think, is that there are different ways to plan for risk.

6. Both Risk Management and Incident Management are same or different? If different then what line differentiates between them?

Risk management is about keeping things working when things go wrong. Incident management is about investigating why something went wrong and figuring out how to prevent it from happening again.

You make a risk management plan before the bad thing happens. You perform incident management after the bad thing happens.

For example, if you are a responsible oil company, and your risk is an oil spill, your risk management plan might be to buy oil spill insurance. (This would be a mitigation plan to prevent you from going out of business in case you are forced to pay a large sum of money to clean up the damage.) For the oil company, incident management would mean determining why the oil was spilled and what could be done to prevent another oil spill in the same way.

Answer 2

Coming to this from the safety critical side of the industry I would say that your Risk Management Plan should start with a Corporate level Risk Management Policy that states how you are going to manage the risk aspects of all of your work, for example how risks are categorized, what documentation, testing policies, etc., must be in place and what type of people can sign off on which types or levels of risk - this will normally site various specifications such as DO-178B. This document would normally detail the companies policy regarding various contingencies including things like liability insurance to minimize financial exposure, required staff backgrounds and qualifications, sub-contracting policies, etc.

The company would normally be expected to maintain an Incident Register in which any actual, or near, problems with the companies products. This should be reviewed on a regular basis and every time that there is a new major or serious incident and is used to check if any of the policies or procedures need to be reviewed or changed.

Each project would normally then have a Risk Management Plan which specifies for that project what steps are to be taken and possibly specific contingency planning for that project and a Risk Register which is used to record any possible risks that are raised at any point and the actions taken to mitigate the specific risks, i.e. to ensure either that they don't occur or that the impact is minimized if they do.

The Risk Management Plan should dictate that:

• the developers address each risk identified in the Risk Register and how they document the actions that they have taken to mitigate each identified risk.
• the Test Plan documents how to test to ensure that each risk identified in the Risk Register, possibly other than those that have been rated as very improbably and with minimal impact, has been successfully addressed by the developer and the documentation needed to record that detail.

Don't forget that developers, test designers and testers all have a professional duty of care to ensure that if there is a risk, that they can reasonably anticipate, whether it is in the risk register or not, that impacts the users, or others, safety they should ensure that it is both added to the risk register and tested against to ensure that it has been successfully mitigated against, i.e.: Just because you have an insurance policy in case something goes wrong it doesn't mean that you can ignore the possibility.

Different industries and different countries have different standards to ensure that this documentation is all done correctly, for the aviation software industry DO-178C is most commonly used.

Just some of the applicable standards:

• DO-178C Avionics software
• ARP4761 (Safety assessment process)
• ARP4754 (System development process)
• DO-248B (Final Report for clarification of DO-178B)
• DO-254 (similar to DO-178B, but for hardware)
• IEC 61508 Functional Safety of Electrical/Electronic/Programmable Electronic Safety-related Systems
• ISO/IEC 12207 (software life cycle process development standard) ED-153 (Guidelines for ANS software safety assurance) Modified_condition/decision_coverage DO-178B Aerospace