Difference between revisions of "Risk Analysis and Risk Response"
(→Identified Risks) |
(→Identified Risks) |
||
Line 84: | Line 84: | ||
!width="60" style="background: #ffdead;" | Work Package | !width="60" style="background: #ffdead;" | Work Package | ||
!width="60" style="background: #ffdead;" | Ticket No | !width="60" style="background: #ffdead;" | Ticket No | ||
− | !width=" | + | !width="400" style="background: #ffdead;" | Countermeasures |
|- | |- | ||
| colspan="6" style="background: #f2f2f2; text-align:center; font-weight:bold; color:#0033CC" | Networking Activities | | colspan="6" style="background: #f2f2f2; text-align:center; font-weight:bold; color:#0033CC" | Networking Activities | ||
Line 106: | Line 106: | ||
| colspan="6" style="background: #f2f2f2; text-align:center; font-weight:bold; color:#0033CC" | Joint Research Activities | | colspan="6" style="background: #f2f2f2; text-align:center; font-weight:bold; color:#0033CC" | Joint Research Activities | ||
|- | |- | ||
− | | | + | | Foundation Technology becomes obsolete |
− | | | + | | align="center" | 4 |
− | | | + | | align="center" | 3 |
− | | | + | | align="center" | All JRA |
− | | | + | | - |
− | | | + | | gCube services do not deal directly with these underlying facilities. gCore framework was impements to isolate the services from the underlying layers. This layer can be evolved to minimise the impact of the risk over the services |
|} | |} | ||
== Top Identified Risks == | == Top Identified Risks == | ||
=== Risk Resolution === | === Risk Resolution === |
Revision as of 17:16, 28 November 2012
Introduction
The goal of the risk analysis and risk response activity is to provide the consortium with guidelines and instruments for managing the actual and potential risks that can occur during the project's lifetime. The full risk management procedure and methodology is available at DNA1.1.
The contingency planning will be part of the DNA2.4 deliverable and as of type "Other" this page will be used to serve the main content of the deliverable.
Risk Management Methodology
Overview
A risk management methodology is a set of methods and procedures used to identify both the risks the project is subject to as well as the actions to take in order to identify their happening and consequently react to minimise their effect.
The methodology consists of several steps; These are the risk identification, classification, monitoring and resolution.
- Risk identification: It identifies the risks that the different parts of the project (i.e. itsassets like the developed or deployed system) are exposed to and evaluates each risk by attaching qualitive and quantitive attributes to the risk, leading to subsequent quantification of the impact that the risk will have, the probability of occurrence, and the value of the assets
- Risk classification: It identifies the most important risks and promotes in subsequent steps the actions to be taken to safeguard the assets. The prioritization of risks attempts to handle first the risks with greatest impact on the project outcomes and greatest probability of occurrence, and last the risks with lowest impact on the project outcomes and lowest probability of occurrence.
- Risk monitoring: It identifies the procedures to monitor the risks according to the priorities identified in the risk classification phase.
- Risk resolution: It identifies the strategies to reduce the probability of occurrence of a risk or the countermeasure needed to limit its effects.
Risk Evaluation
The evaluation of a risk is performed by identifying the probability of occurrence and the impact for each risk. The probability for a particular source/problem to occur is not a strictly mathematical probability factor. For the majority of the risks there are no formulas or there is not enough experimental data to calculate the probability of occurrence. Thus it is not easily quantifiable. The impact measures the damage that will be caused to the object element in case of occurrence of the risk.
This case of difficult evaluation of the basic metrics of risk evaluation is actually typical in IT project where probabilities are estimated by indirect methods such as “expert” opinions, offers, negotiations etc. In the iMarine case, this activity relies on “expert” opinions that evaluate the risks. Moreover, the terms “probability rank” and “impact rank”, which are more appropriate for the iMarine case, have been adopted. Probability rank liberates the analysis from the strict mathematical terms, which in any case is not objectively useful in this
context, while Impact rank adds a degree of freedom and uses indirect reference to absolute costs of risk appearance. The following table presents the convention defined for risk evaluation.
Probability Rank | Impact Rank | ||
---|---|---|---|
Description | Value | Description | Value |
None | 0 | None | 0 |
Very Low | 1 | Doesn’t affect the activity | 1 |
Low | 2 | Affects the activity but a workaround is not needed | 2 |
Medium | 3 | Affects the activity and it's recommended to put in place a workaround | 3 |
High | 4 | Affects the activity and it's mandatory to put in place a workaround | 4 |
Very High | 5 | Affects the activity that has to be completely rethought | 5 |
Certain | 10 | Blocks the activity | 10 |
Risk Identification
Risk Classification
Risk Monitoring
Risk Resolution
Identified Risks
Description | Risk Probability | Risk Impact | Work Package | Ticket No | Countermeasures |
---|---|---|---|---|---|
Networking Activities | |||||
A small description for the risk | RP | RI | WP | Ticket | Resolution Actions |
Service Activities | |||||
Unavailability of dedicated computing and storage resources | 1 | 3 | 5 | - | The required amount of resources can be acquired from external cloud providers like Engineering (E-IIS) or Amazon, thanks to gCube extension cloud |
Joint Research Activities | |||||
Foundation Technology becomes obsolete | 4 | 3 | All JRA | - | gCube services do not deal directly with these underlying facilities. gCore framework was impements to isolate the services from the underlying layers. This layer can be evolved to minimise the impact of the risk over the services |