Risk Analysis and Risk Response
| |
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.
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
| 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
| Risk | Description | Risk Probability | Risk Impact | Work Package | Ticket No | Countermeasures |
|---|---|---|---|---|---|---|
| Networking Activities | ||||||
| High staff turnover | Given the complexity of the iMarine environment, skilled staff may leave the project for longer-term and higher paying positions within industry The vierual nature of the organisation may increase the probability of this risk |
2 | 3 | All | - | -Project management should verify training plans for the younger researchers/developers to ensure that they continuously evolve within the project. -Plan two or three occasions per year where all project staff can get together. -Consider staff satisfaction review across the project |
| Lack of organisational coherence | Could be caused by one or more specific anderlying reasons ranging from communication difficulties at one or another of the member organisations | 2 | 3 | All | - | - Minimise the risk occuring by implementing a project structure in which the key main stakeholders are identified at this point in time -Ensure the consensual values within the project, the effective use of communications technology and the frequent planning control and review. |
| Serious disputes between consortium members | 2 | 3 | All | - | -Aim to minimise the chances of disputes occuring by ensuring regular and clear communication between consortium members -Work package leaders should aim to follow an attitude of openess and trust, wehrever possible | |
| Multi-disciplinary nature of the consortium may lead to disciplines working in silos | Lack of communication, limited understanding of the needs and difficulties in testing/feedback | 2 | 3 | All | - | -Work package leaders must ensure reglar presence at the quarterly face-to-face meetings of the PEB in order to prevent "silo" work packages -Regular communication thourgh virtual means will prevent isolation |
| EA-CoPCommunity of Practice. technologies becomes obsolete | The CoPCommunity of Practice. employs a wide variety of technologies, often released many years ago. They may need to change them to become a viable partner. | 4 | 2 | All | - | -The gCube services do not depend on these external facilities. If software needs upgrade, this is beyond the project scope. However, the data infrastructure may offer solutions. |
| EA-CoPCommunity of Practice. Software is not released on time | This risk is very common in any project with a collaborative plan of development activities. Late delivery only affects EA-CoPCommunity of Practice. activities. | 3 | 3 | All | - | -The Agile development approach provides opportunities to assess the direction of the ongoing activities, and mitigate the impact -Appropriate boards within the project will continuously monitor this risk and take corrective actions |
| Multi-disciplinary nature of the consortium may lead to disciplines working in silos | Lack of communication, limited understanding of the needs and difficulties in testing/feedback | 2 | 3 | All | - | -Work package leaders must ensure reglar presence at the quarterly face-to-face meetings of the PEB in order to prevent "silo" work packages -Regular communication thourgh virtual means will prevent isolation |
| Lack of motivation and/or participation in the Virtual and the Project Events | Recruiting both appropriate speakers and participants to attend this event involve skilled staff with experience in developing marketing and promotional strategies as well as a vast network database of competent names which focus on benefits of the individual attending. | 3 | 3 | All | - | -The iMarine partners boast high-level networks specific contacts which will be contacted according to the specific event organised. The partners have proved over the last 2 years are able to obtain active participation from key experts in the field. The involvement of the existing CoPCommunity of Practice. community and its related contact network will also help mitigate this risk |
| Project software is not delivered on time or misses specifications | NA3 translates the EA-CoPCommunity of Practice. in development goals that cannot be achieved by JRA for any reason | 3 | 3 | All | - | -Representatives of JRA will be included in the NA3 work package by assuring the feasibility of the goals according to JRA requirements and effort. |
| Difficulty increasing users’ participation to engage in iMarine training activities | To accelerate the adoption of the e-infrastructure governance model, to create awareness of the services provided, etc., users‟ participation must increase. | 3 | 3 | All | - | -The introduction of virtual tools is a proven mechanism for engaging and involving users in training activities reducing costs and the learning-implementation process as users may have their individual timeframe to complete courses |
| Expected co-funding / collaboration is not achieved | The projects supporting external applications development are delayed or cancelled, and the in-kind inputs from partners are not delivered as promised.The risk is medium since the core parts of the use cases are designed to be tackled with project funds or external funding sources already approved. |
3 | 2 | All | - | -The iMarine Board will mostly have to face priority settings, so efforts will be reported on areas where resources are guaranteed -The Steering Board should make decisions in the best interest of the EA-CoPCommunity of Practice. |
| EA-CoPCommunity of Practice. Policy expectations are too diverse for being consistently developed for iMarine | Too many expectations are formulated, the opinions of different members are too strongly diverging on the solutions. The risk is real but has been minimized by attempting to being together actors of the EA-CoPCommunity of Practice. which share common interests and standards | 3 | 4 | All | - | -The iMarine Board will create clusters of common interest in order to facilitate negotiation; it will also have flexible strategies for the development of policies, bottom-up or top down or a mixture of both depending on the complexity. It will be aware that progress on policies will be uneven depending on the topics |
| 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 | |
