Risk Management.xlsx

	A	B	C	D
1	Instructions		Categories of Risk - these are examples of the sorts of risks that might fall into each category
2	Use this information to help you populate the Risk Management tab. The team and guide should discuss whether any additional information needs to be included. Beginning with the Systems Level Design Review, this document should be actively managed by the team, and discussed at each design review throughout MSD I and MSD II. As you approach the end of MSD II, your overall level of risk should approach, if not reach, 0.		Technical	Scope creep, components don't work as expected, team members lack the skills necessary to do the work, as-fabricated parts differ from design, flawed assumptions
3			Resource	Schedule (e.g.: parts don't come in on time, machine shop is busy), personnel (e.g.: team member gets sick, travels for an interview), cost (e.g.: components cost more than expected, fabrication must be outsourced), facilities (e.g.: specialized piece of equipment fails, lose access to lab)
4			Safety	Injury to team, injury to end user, damage to equipment
5			Environmental	Team must dispose of significant excess material, design requires hazardou materials, selecting a low-cost component that could lead to shorter life and the need for additional purchases, design requires purchase of consummable items for end user
6			Social	Design choices cause harm to a team member or end user based on social issues (e.g.: loss of confidentiality, contradicts local cultures and customs)
7
8	Likelihood scale	Severity scale	“Importance Score” (Likelihood x Severity) – use this to guide your preference for a risk management strategy
9	1 - This cause is unlikely to happen	1 - The impact on the project is very minor. We will still meet deliverables on time and within budget, but it will cause extra work.	Prevent	Action will be taken to prevent the cause(s) from occurring in the first place.
10	3 - This cause could conceivably happen	3 - The impact on the project is noticeable. We will deliver reduced functionality, go over budget, or fail to meet some of our requirements.	Reduce	Action will be taken to reduce the likelihood of the cause and/or the severity of the effect on the project, should the cause occur
11	9 - This cause is very likely to happen	9 - The impact on the project is severe. We will not be able to deliver, or what we deliver will not meet the customer's needs.	Transfer	Action will be taken to transfer the risk to something else. Insurance is an example of this. You purchase an insurance policy that contractually binds an insurance company to pay for your loss in the event of accident. This transfers the financial consequences of the accident to someone else. Your car is still a wreck, of course.
12			Accept	Low importance risks may not justify any action at all. If they happen, you simply accept the consequences.
13
14			Risks to satisfying the engineering specs and deliverables. Link to ER and call out.
15			Go back to Use case, find where it can fail
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100