¶ Risk Management
¶ Introduction
"Risks are a threat to project success because they have negative effects on the project cost, schedule and technical performance, but appropriate practices of controlling risks can also present new opportunities with positive impact. The objective of project risk management is to identify, assess, reduce, accept, and control space project risks in a systematic, proactive, comprehensive and cost effective manner, taking into account the project’s technical and programmatic constraints. Risk is considered tradable against the conventional known project resources within the management, programmatic (e.g. cost, schedule) and technical (e.g. mass, power, dependability, safety) domains. The overall risk management in a project is an iterative process throughout the project life cycle, with iterations being determined by the project progress through the different project phases, and by changes to a given project baseline influencing project resources."
"Known project practices for dealing with project risks, such as system and engineering analyses, analyses of safety, critical items, dependability, critical path, and cost, are an integral part of project risk management. Ranking of risks according to their criticality for project success, allowing management attention to be directed to the essential issues, is a major objective of risk management."
ECSS‐M‐ST‐80C: Risk management (Introduction)
This article deals with how to address these risks from the beginning of a project, how to track them with periodic reviews, and advice on how to formulate mitigations for risks which should overall lower the severity for your project and your team.
¶ Risk assessment
As stated above, project risks envelop everything from personal safety, to technical failures, to budget overruns. Anything and everything that could have a negative impact on your project’s success that you can think of or that experience, your peers, or your predecessors have taught you should be marked down in your risk assessment table.
Again, this is a cyclical element of systems engineering that can be improved upon every year. More importantly than helping out those who will come after you, holding a correct and up to date risk assessment table should guide where you set some of your priorities in term of design and testing. Identifying the troublesome areas early on and addressing them by design is a good way to eliminate certain risks.
To assess these risks, we recommend using a 1 to 5 impact and probability level scoring system based on an approach developped in NASA SE Handbooks. This scoring allows you to identify the relative severity of each risk at the various phases of the project. A description of how these
levels can be chosen is presented in the two criteria tables below:
¶ Probability Criteria
¶ Impact Criteria
¶ Risk Severity
Once these two numbers are known the resulting severity can be calculated by referencing the impact and probability levels on the following table. Note that this table is asymmetric because it is assumed that a risk with a high probability but a low impact on the mission is much less severe than a mission critical failure that is unlikely to happen.
The goal of this color code is to visually be able to quickly identify the problem points and set priorities to what needs to be dealt with first. The goal of you and your team leaders is to make these risk levels drop. As a rule of thumb, if something is still in “red” on the risk assessment table, it’s generally a NO-GO for your mission. Once the table is established, you can design certain elements to limit the risk, plan tests to later assess actual risk, make measurements to estimate probability of failure, and in general set precautions to limit the severity of all your risks. This is risk mitigation and shall be addressed next.
¶ Risk Mitigation
Initial risk assessment sets a baseline for your project risk levels, and as stated before, your job is to reduce this initial severity, ideally until all your subsystems are in the “green”. Risk mitigation is the process of reducing this severity. Any action, test, design, or concept that has applicable and precise steps should be referenced in your risk assessment table under “mitigation”. This is so that later on when reviewing your project or your design you can find some justification for your decisions as the mitigation column will justify many of your team’s actions all in the aims of reducing risk severity. The following table gives you some examples risks that were assessed and mitigated during the ERT’s project Bella Lui II (PM Severity = post-mitigation risk severity re-evaluation).
Notice here that the criteria are not presented so it is not clear which criteria made the severity drop. Mitigations can either focus on reducing risk impact or risk probability in order to reduce the severity. For example, the risk of a mechanical failure might have a high impact on nominal operations but if through extensive testing you can demonstrate that the failure is unlikely, this would result in the severity being greatly reduced.
Here are a few simple examples of mitigation:
- Preventive ones, where, by design, the technical failure cannot happen because the system is designed your assemblies such a way that the risk is no longer an issue.
- Assurance of low probability through extensive testing.
- Redundancies are also often used to reduce risk level.
- Simply accepting the risk level.
Another interesting method of risk mitigation is through your operations. This is often more specific to personnel risk, but examples of other situations can be found. The use of COO and CSO checks throughout your operations can be vital to the health of your crew and to mission success. Be certain to rehearse these types of operational procedures through tests and mock operations with all-hands-on-deck. This is even more relevant when it comes to handling hazardous materials or when safety protections are needed to complete operations. We recommend using very visual pictograms throughout your documentation to make these safety measures as clear as possible. Again, practice and training are key here.
¶ Ressources
This article is (very) inspired by the SE Student Handbook (written by Bella Lui II SEs Christopher Hémon and César Toussaint). See in particular Section 5.
SE Student Handbook