Skip to main content
deleted 4 characters in body
Source Link
user246
user246

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.

  1. 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 the 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.

  1. 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.

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.

  1. 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 the 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.

  1. 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.

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.

  1. 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.

  1. 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.

added 13 characters in body
Source Link
user246
user246

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.

  1. 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 the 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.

  1. 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.

IfFor 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.

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.

  1. 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 the 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.

  1. 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.

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.

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.

  1. 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 the 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.

  1. 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.

edited body
Source Link
user246
user246

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.

  1. 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 the 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.

  1. 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.

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 wouldcould be done to prevent another oil spill in the same way.

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.

  1. 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 the 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.

  1. 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.

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 would be done to prevent another oil spill in the same way.

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.

  1. 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 the 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.

  1. 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.

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.

added 9 characters in body
Source Link
user246
user246
Loading
Source Link
user246
user246
Loading