Difference between revisions of "Risk Register"

From MAGEEC
Jump to: navigation, search
m (Sorting table)
(Updated Risk Register)
Line 11: Line 11:
 
| 9 || 2 || 18
 
| 9 || 2 || 18
 
| Engagement with wider community to identify programs. Committing more resource to developing [http://www.cs.bris.ac.uk/Research/Micro/beebs.jsp BEEBS] and test programs (Bristol). Likelihood updated in Q2, more effort on community involvement will be promoted (Andrew Back). Simon Cook will run monthly phone review of progress.
 
| Engagement with wider community to identify programs. Committing more resource to developing [http://www.cs.bris.ac.uk/Research/Micro/beebs.jsp BEEBS] and test programs (Bristol). Likelihood updated in Q2, more effort on community involvement will be promoted (Andrew Back). Simon Cook will run monthly phone review of progress.
 +
|-
 +
| WP4 || Data Gather phase taking too long due to board reliability
 +
| 6 || 2 || 12
 +
| Exploration of a smaller data set (in terms of number of boards explored) whilst full data gather occurs and redundancy of boards. Updated in Q2 and Q4 to note that problem has occur, supply of v2 boards are mitigating this as is reducing number of boards for initial exploration.
 
|-
 
|-
 
| WP7 || The compiler infrastructure does not work for energy
 
| WP7 || The compiler infrastructure does not work for energy
| 5 || 3 || 15
+
| 4 || 3 || 12
| 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.
+
| 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. Work carried out thoughout this project by the team and James Pallister is increasingly showing that compiling for energy demonstrates benefits.
 +
|-
 +
| All || Milestones not met
 +
| 6 || 2 || 12
 +
| Regular meetings and prior experience in these fields. Manage interactions/dependencies between work packages and re-visit time allocations as more information arises. Likelihood increased in Q2, due to delay of deliverables 2.3, 4.1 and 4.2 and introduction of new deliverable 4.4. Mitigations are listed against specific issues in this risk register and the project plan.
 
|-  
 
|-  
 
| All || Loss of key personnel
 
| All || Loss of key personnel
 
| 5 || 2 || 10
 
| 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.
 
| 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.
 
| 4 || 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. Likelihood reduced in Q2, due to track record so far in attending community events.
 
|-
 
| All || Milestones not met
 
| 6 || 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. Likelihood increased in Q2, due to delay of deliverables 2.3, 4.1 and 4.2 and introduction of new deliverable 4.4. Mitigations are listed against specific issues in this risk register and the project plan.
 
 
|-
 
|-
 
| All || Unable to recruit suitable staff
 
| All || Unable to recruit suitable staff
Line 32: Line 32:
 
| Already mitigated through existing experience and staff from all consortium members. People pipeline from UoB ensures high quality candidates.
 
| 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
+
| WP10 || Failure to engage with open source communities.
| 3 || 2 || 6
+
| 4 || 2 || 8
| Exploration of a smaller data set whilst full data gather occurs and redundancy of boards. Updated in Q2 to note that problem did occur, but new hardware being developed will mitigate.
+
| 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. Likelihood reduced in Q2, due to track record so far in attending community events.
 
|-
 
|-
 
| WP9 || Compiler energy efficiency optimisation passes yield no measurable benefit  
 
| WP9 || Compiler energy efficiency optimisation passes yield no measurable benefit  
Line 53: Line 53:
 
|-
 
|-
 
| WP3 || MAGEEC v2 board doesn't work
 
| WP3 || MAGEEC v2 board doesn't work
| 2 || 1 || 2
+
| 1 || 1 || 1
| Continue to use existing board. (MAGEEC v2 board is nice to have).
+
| Continue to use existing board. (MAGEEC v2 board is nice to have). Lowered in Q4 as we are successfully using v2 boards.
 
|}
 
|}
  
 
[[Category:Planning]]
 
[[Category:Planning]]

Revision as of 09:02, 20 May 2014

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
WP4 Unable to find sufficient benchmark and test programs 9 2 18 Engagement with wider community to identify programs. Committing more resource to developing BEEBS and test programs (Bristol). Likelihood updated in Q2, more effort on community involvement will be promoted (Andrew Back). Simon Cook will run monthly phone review of progress.
WP4 Data Gather phase taking too long due to board reliability 6 2 12 Exploration of a smaller data set (in terms of number of boards explored) whilst full data gather occurs and redundancy of boards. Updated in Q2 and Q4 to note that problem has occur, supply of v2 boards are mitigating this as is reducing number of boards for initial exploration.
WP7 The compiler infrastructure does not work for energy 4 3 12 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. Work carried out thoughout this project by the team and James Pallister is increasingly showing that compiling for energy demonstrates benefits.
All Milestones not met 6 2 12 Regular meetings and prior experience in these fields. Manage interactions/dependencies between work packages and re-visit time allocations as more information arises. Likelihood increased in Q2, due to delay of deliverables 2.3, 4.1 and 4.2 and introduction of new deliverable 4.4. Mitigations are listed against specific issues in this risk register and the project plan.
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.
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.
WP10 Failure to engage with open source communities. 4 2 8 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. Likelihood reduced in Q2, due to track record so far in attending community events.
WP9 Compiler energy efficiency optimisation passes yield no measurable benefit 3 2 6 High likelihood is as this hasn't been attempted before. Decouple from infrastructure development, allowing parallel development and use appropriate expert staff (Joern Rennecke). Likelihood reduced in Q2, now we have concrete measurements for one optimization.
All Failure of consortium to work together 2 2 4 Consortium has already worked together.
WP5 Failure to identify viable features (technical issue) 1 3 3 Fallback is to use the MILEPOST features. We have started engagement with the MILEPOST team to gain from their experience as much as possible. Likelihood reduces in Q2, since we are now using the MILEPOST features. Still some risk that we are unable to use any new features.
WP1, WP2 Compiler infrastructure cannot be made generic 1 2 2 Ensuring good interface design before building infrastructure. Note that non-fully generic solution still has value. Likelihood reduced in Q2, since implementation n progress appears to be completely viable for both GCC and LLVM via clean interfaces.
WP3 MAGEEC v2 board doesn't work 1 1 1 Continue to use existing board. (MAGEEC v2 board is nice to have). Lowered in Q4 as we are successfully using v2 boards.