Difference between revisions of "Risk Register"

From MAGEEC
Jump to: navigation, search
(Updated Risks)
(Update risks with work packages, sort)
Line 16: Line 16:
 
| High likelihood is as this hasn't been attempted before. Decouple from infrastructure development, allowing parallel development and use appropriate expert staff (Joern Rennecke).
 
| High likelihood is as this hasn't been attempted before. Decouple from infrastructure development, allowing parallel development and use appropriate expert staff (Joern Rennecke).
 
|-
 
|-
| All || Unable to recruit suitable staff
+
| WP5 || Failure to identify viable features (technical issue)
| 3 || 3 || 9
+
| 4 || 3 || 12
| Already mitigated through existing experience and staff from all consortium members. People pipeline from UoB ensures high quality candidates.
+
| Fallback is to use the MILEPOST features. We have started engagement with the MILEPOST team to gain from their experience as much as possible.
 
|-
 
|-
 
| WP1, WP2 || Compiler infrastructure cannot be made generic
 
| WP1, WP2 || Compiler infrastructure cannot be made generic
Line 35: Line 35:
 
| 5 || 2 || 10
 
| 5 || 2 || 10
 
| Regular meetings and prior experience in these fields. Manage interactions/dependencies between work packages and re-visit time allocations as more information arises.
 
| Regular meetings and prior experience in these fields. Manage interactions/dependencies between work packages and re-visit time allocations as more information arises.
 +
|-
 +
| All || Unable to recruit suitable staff
 +
| 3 || 3 || 9
 +
| Already mitigated through existing experience and staff from all consortium members. People pipeline from UoB ensures high quality candidates.
 +
|-
 +
| WP4 || Data Gather phase taking too long due to board reliability
 +
| 3 || 2 || 6
 +
| Exploration of a smaller data set whilst full data gather occurs and redundancy of boards.
 
|-
 
|-
 
| All || Failure of consortium to work together
 
| All || Failure of consortium to work together
Line 40: Line 48:
 
| Consortium has already worked together.
 
| Consortium has already worked together.
 
|-
 
|-
| || Failure to identify viable features (technical issue)
+
| WP3 || Board v4 doesn't work
| 4 || 3 || 12
 
| Fallback is to use the MILEPOST features. We have started engagement with the MILEPOST team to gain from their experience as much as possible.
 
|-
 
| || Board v4 doesn't work
 
 
| 2 || 1 || 2
 
| 2 || 1 || 2
 
| Continue to use existing board. (v4 board is nice to have)
 
| Continue to use existing board. (v4 board is nice to have)
|-
 
| || Data Gather phase taking too long due to board reliability
 
| 3 || 2 || 6
 
| Exploration of a smaller data set whilst full data gather occurs and redundancy of boards.
 
 
|}
 
|}
  
 
[[Category:Planning]]
 
[[Category:Planning]]

Revision as of 08:54, 4 September 2013

The following describes the risks to this project, their likelihood and impact on the project, as well as procedures for mitigating the risk.

For each risk, the likelihood of it occurring is rated on a scale of 1 (very unlikely) to 10 (certain to happen) and the impact of this occurring is rated on a scale of 1 (minor impact), 2 (significant impact), 3 (total wipe out of the project). Risk is calculated as the product of the two numbers.

A risk mitigation strategy is provided when the risk is greater than or equal to 10 or where the impact is 3.

Work Package Description Likelihood Impact Risk Mitigation
WP7 The compiler infrastructure does not work for energy 5 3 15 The system would be reconfigured for speed minimisation based on experience that a) this is possible (MILEPOST) and b) speed is a rough proxy for energy. However, this does not represent as significant advance on current knowledge, but does make it more accessible.
WP9 Compiler energy efficiency optimisation passes yield no measurable benefit 7 2 14 High likelihood is as this hasn't been attempted before. Decouple from infrastructure development, allowing parallel development and use appropriate expert staff (Joern Rennecke).
WP5 Failure to identify viable features (technical issue) 4 3 12 Fallback is to use the MILEPOST features. We have started engagement with the MILEPOST team to gain from their experience as much as possible.
WP1, WP2 Compiler infrastructure cannot be made generic 5 2 10 Ensuring good interface design before building infrastructure. Note that non-fully generic solution still has value.
All Loss of key personnel 5 2 10 Ensure the consortium has multiple people skilled in each area. Note that the area of compiler optimisation (WP8) has one person covering this, but is a smaller part of the project.
WP10 Failure to engage with open source communities. 5 2 10 Early and open discussions with the relevant communities (already started). Appointment of project member (Andrew Back, AB Open) charged with driving this very time consuming activity.
All Milestones not met 5 2 10 Regular meetings and prior experience in these fields. Manage interactions/dependencies between work packages and re-visit time allocations as more information arises.
All Unable to recruit suitable staff 3 3 9 Already mitigated through existing experience and staff from all consortium members. People pipeline from UoB ensures high quality candidates.
WP4 Data Gather phase taking too long due to board reliability 3 2 6 Exploration of a smaller data set whilst full data gather occurs and redundancy of boards.
All Failure of consortium to work together 2 2 4 Consortium has already worked together.
WP3 Board v4 doesn't work 2 1 2 Continue to use existing board. (v4 board is nice to have)