Difference between revisions of "Risk Analysis and Risk Response"
From D4Science Wiki
(→Identified Risks) |
(→Identified Risks) |
||
| Line 87: | Line 87: | ||
!width="350" style="background: #ffdead;" | Countermeasures | !width="350" style="background: #ffdead;" | Countermeasures | ||
|- | |- | ||
| − | | | + | | colspan="7" style="background: #f2f2f2; text-align:center; font-weight:bold; color:#0033CC" | Networking Activities |
|- | |- | ||
| High staff turnover | | High staff turnover | ||
Revision as of 18:14, 3 December 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.
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 | Related Ticket | 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 | The computing and storage resources provided by the project partners represented in SA1 are not made available | 1 | 3 | 5 | - | The required amount of resources can be acquired from external cloud providers like Engineering (E-IIS) or Amazon, thanks to gCube cloud extension |
| Unavailability of on-demand computing and storage resources | The computing and storage resources provided on-demand as cloud resources in SA1 are not made available. Alternatively, the gCube extension to access clouds resources is not operational | 3 | 3 | 5 | - | The required amount of resources will be discussed with the project partners to understand their availability to provide more dedicated nodes |
| Impossible to access resources from other infrastructures | The resources provided by other (data) infrastructures (from the D4ScienceAn e-Infrastructure operated by the D4Science.org initiative. Federation and others) are not reachable and cannot be consumed from the iMarine Data e-InfrastructureAn operational combination of digital technologies (hardware and software), resources (data and services), communications (protocols, access rights and networks), and the people and organizational structures needed to support research efforts and collaboration in the large. | 3 | 3 | 5 | - | The Service Activity teams of both infrastructures establish direct communication to analyse the problem. If required, the defined interoperability solutions are updated and the development teams involved |
| Useless procedures | The identified procedures to manage the Data e-InfrastructureAn operational combination of digital technologies (hardware and software), resources (data and services), communications (protocols, access rights and networks), and the people and organizational structures needed to support research efforts and collaboration in the large., the VREs, and the software release are useless and introduce delays | 2 | 3 | - | -The reasons for the misalignment between procedures and daily practices are analysed and improvements to the current procedures proposed and tested -The advisement from external experts may be established | |
| Unclear or unstable requirements | The requirements and concrete use cases identified by the EA-CoPCommunity of Practice. are not clear or unstable and do not allow the definition of appropriate Virtual Research EnvironmentA ''system'' with the following distinguishing features: ''(i)'' it is a Web-based working environment; ''(ii)'' it is tailored to serve the needs of a Community of Practice; ''(iii)'' it is expected to provide a community of practice with the whole array of commodities needed to accomplish the community’s goal(s); ''(iv)'' it is open and flexible with respect to the overall service offering and lifetime; and ''(v)'' it promotes fine-grained controlled sharing of both intermediate and final research results by guaranteeing ownership, provenance, and attribution. | 3 | 4 | - | More regular and face-to-face meetings between the EA-CoPCommunity of Practice. members and the technical teams are established to promote a clear communication between the two teams and a detailed discussion of the requirements | |
| Low quality of the delivered community tools and gCube common tools | The applications and tools developed by the user communities and/or the gCube common tools are not deployable or are of low quality | 3 | 3 | - | The effort on the development support task (TSA2.4) is intensified to allow a better communication and support to the developers of these applications and tools | |
| Unavailability of data resources | The data resources planned for the different use cases are not delivered and made available by the user communities | 3 | 4 | - | Direct contact with the user communities and increased support is put in place to understand the reasons for the unavailability of the data resources. The policies for data provision may be revised | |
| Limited or unavailable VREVirtual Research Environment. functionality | The identified VREVirtual Research Environment. functionality is not provided or do not satisfied the initial requirements | 2 | 4 | 6 | - | Define very clearly the planned VREVirtual Research Environment. functionality. Push developers to deliver early prototypes and users to provide early feedback |
| Unavailability of build and testing tools | The tools defined to integrate and test the project source code are not made available | 2 | 4 | 7 | - | -Other instances of the same tools are exploited (e.g. an ETICS instance is hosted at CERN and run by EMI project, however Engineering (E-IIS) will also install an instance in its premises) -The usage of other tools is considered |
| 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 | |
