What is the difference between risk analysis and risk mitigation?

Question

What is the difference between risk analysis and risk mitigation and when(before coding or after coding?) and by whom(QA/analyst/developer?) should they be performed in the Software Development Life Cycle?

Opinions, links or document templates would be helpful.

---

EDIT If I follow meade's comment:

"According to Tom DeMarco - Risk Management is Project Management for adults "

does that mean some parts of the traditional SDLC do not need to be followed? Which parts? ie. what aspects of typical SDLC does risk management replace? No need for as many MS project drills?

Answer 1

Risk Analysis is the planning process where you identify the types, probability and severity of the risks that might happen on a project. Typically a Project Manager would build this with input from the engineers and quality teams.

Risk Mitigation is the plan for what to do about the risks identified by Risk Analysis. This can include a combination of plans to either:

A) Risk avoidance: minimize the potential for those risks to materialize (by not doing the risky thing, i.e. by buying an off-the-shelf component or software package);

B) Mitigation of the consequences: minimize the severity of risks if they do occur (have a contingency plan, add extra time and/or budget, do full back-ups etc); and/or

C) Risk acceptance: be ready to deal with risks when they occur (a low probability or low impact of the risk compared to the cost of management might not be worth doing anything about them, if you're the sole developer and there is a probability of being hit by an asteroid it just might be worth simply accepting the risk).

D) Risk transfer: let someone else bear the risk for you, someone who can handle it better, i.e. an insurance company or outsourced provider.

The plan is usually coordinated by the project manager and implemented by just about everyone on the team.

Risk analysis, risk mitigation and risk monitoring make up the process of risk management. And as with pretty much any process it is a continuous activity, meaning it needs to be performed throughout the project.

Answer 2

Risk analysis typically is looking to see what might go wrong. Risk mitigation is what are the steps to take in the event that something goes wrong.

Both of these should be done at the beginning. Typically they are done to see if completing the project is beneficial to the business. (risk vs reward)

Answer 3

Risk Analysis = What Risks are we taking based on current workflow or sequence of activity. May be technical or may not be. It can also be said as, what are the risks ( with probability) that a set of problems will arise based on a scenario.

Risk Mitigation = It is a set of systematically deduced steps to follow to make sure the after effects of the risk are kept at minimum. Unidentified risks are hard to mitigate.

Answer 4

Typically risk analysis is determining whether there is a risk, what impacts it would have, how likely it is to occur and when it's likely to occur. Risk mitigation is attempting to reduce or remove the risk entirely and there are various means to do that.

Risks should be constantly reviewed throughout the project life-cycle as they're likely to increase in risk (e.g. you're dependent on a 3rd party component that won't be delivered for 3 months, not a huge risk at the start but if you're coming up to the 3 month mark and not hearing anything from the supplier it's a much more significant risk), or even decrease or disappear naturally.

Who actually analyses and mitigates the risk depends largely on who is most appropriate. If it's related to software it may be the case that a software developer is assigned to monitor, report and act on it (as in the above example). Of course having said that it might equally be the Project Manager or someone doing Project Quality Assurance.

The general rule is analyse often, monitor continuously, and assign the best person to reduce risk.

Answer 5

This is something that goes on during the course of the project. At a minimum it must be done for each iteration (which are hopefully a few weeks). Also note that methodologies and practices have several measures that are meant to mitigate a whole range of risks related to software development.

Answer 6

I agree with DeMarco's statement: "Risk Management is Project Management for adults". As a PM, we do what we do for reasons of good governance and risk management. Without them a project is just a bunch of people doing stuff.

Risk Management doesn't replace any part of the SDLC or a typical methodology. It's the reason why you do all the boring scheduling, registers and documentation. You do these things to reduce the impact of negative risks and hopefully capitalise on any opportunities (ie: positive risks).

On templates for risk registers, your organisation needs to set the standards depending on their risk appetite. The following describes a pretty simple process;

1) First you identify each risk in a Risk Register which is just a list in Excel.

2) Next you judge each risks' impact and probability.

3) The combination of impact and likelihood then describe the level of risk (see the first matrix table)

4) You use this risk level (low to extreme) to help frame your approach. In my example the level of governance prescribed is specified by the company. (see the second table)

5) From that you, or someone else would then decide what response to take for each risk in your register as per @JohnFx answer. If you are the PM and it's a Low risk.. then "acceptance" might be the right approach. The concept of Risk Management and Governance is that you write this down and clearly communicate it to your stakeholders. Then you all know the why and what you are doing.

I regularly discuss only the top 5 risks with sponsors and the team, however the whole Risk Register should be reviewed semi regularly throughout the project. Don't just chuck it in a drawer. It's meant to be a communication tool of why you made certain decisions and took certain actions, and should be kept up to date.

NB: These are qualitative risk assessment techniques, there are more advanced quantitative techniques .. but just because they are more complicated it doesn't mean they are better. They have their place depending on appetite, budget and capability.