Risk management is often applied in projects to monitor and control unwanted events that could negatively impact a project or organization’s outcomes. Projects often incorporate risks into their Systems Engineering (SE) model to identify these unwanted events and enable mitigation of potential consequences, reducing costs associated with failure. In SE models of projects, the terms risk and hazard are often used to support similar processes. For clarity and simplicity, the term risk will be used hereafter.
Based on observations at projects, the basic model consists of a type element named Risk, which includes type properties to store the name, description, priority, cause, and consequence.
Typically, the type property Name has the data type of Single line text (to contain a brief title for identifying the risk), and the type property Description has a data type of Text (to contain the full text describing the risk). The type property Priority has a data type of List (to indicate the level of importance), with values such as Low, Medium, and High. Finally, the type property Cause has a data type of Text (to contain a description of the cause of which the risk is the result), and the type property Consequence has a date type of Text (to contain a description of the result when the risk is affected).
Lifecycle
When monitoring risk handling over time, it is often beneficial to add a Status property to the model with the data type List. Examples of list values include Actual and Rejected. This makes it easier to filter out irrelevant risks.
If some risks are expected to become irrelevant to the project over time, it is advisable to configure the Status property as a Life cycle property for the type element Risk. This can be done by setting the Life cycle property of the type element Risk to the type property Status. Furthermore, by enabling the Auto archive setting and selecting appropriate archive values (e.g., Rejected), only relevant risks will be displayed by default in the views.
Allocation
This model pattern provides a simple yet comprehensive allocation functionality for risk allocation. In this example, it combines allocation within project parties and allocation to project-related information. The risk allocation with regard to parties is captured in a property called Allocation.
It is common to see this allocation property having values such as Client, Contractor, and Client & Contractor. For risk allocation, we often use a property called Endogenous/Exogenous, or, in this example, we have used the property Type with the values Endogenous and Exogenous.
TIP: Assigning risks to a person enables the power user to set up the My to-do functionality for the end user. By navigating to the type element settings of Risk and clicking on the Advanced tab, the lifecycle of the element can be defined. In this case, we used the Status property because the user is required to assess the risk when the status value is Identified. After setting the lifecycle property, the to-do definition can be created with the lifecycle value set to Identified and the type relation to Person.
Note that the My to-do functionality only works when a person in Relatics is linked to an existing user!
Cause(s) and consequence(s)
When managing risks in a project, it is common to also register the causes and effects of those risks. This provides users with insight into the context of the risk and helps visualize the quantification as well as the counter-/control measures that need to be implemented.
Multiple causes and/or multiple consequences model pattern
Having Cause and Consequence as properties of a Risk allows for the management of a single cause and a single consequence for each risk. However, when a risk can have multiple causes and/or consequences, it may be more suitable to use the inner derived element model pattern. One advantage of using inner derived elements is that additional properties and/or relations can be added to expand the context.
A combination of properties and inner derived elements is also possible. For example, if a risk has only one cause but could have multiple consequences, the cause could be a property of the risk, while the consequences could be modeled as inner derived elements.
If you want to include the causes and/or consequences in your menu structure, consider configuring them as derived elements instead of inner derived elements. To visualize multiple (inner) derived elements, create use cases in the overview.
Control Measures
Control measures provide a step-by-step approach to mitigating risks. Once all control measures are completed, the risk priority should be reduced from its initial level.
In-detail controlling
Controlling risks can be done in great detail. When Control Measures are more generic to an Object, actions can be created to plan specific tasks. This approach also provides a good opportunity to link actions to a project planning tool or a detailed planning report from Relatics.
Configuring the Control measures as an inner element, with Action as inner elements of the Control measure, allows the user to create both generic measures and specific actions directly within the context of a risk. In this setup, Control measure and Action are linked to an Object, though this can be any type of element to which the Risk is assigned.
TIP: If there is a relation from a Risk to an Object (or another type of element that is also related to your control measures and/or actions), consider configuring a circular dependency criterion on the relation between the Control measure/Action and the Object type element. This ensures that only the objects related to the risk can be selected for the control measures/actions.
The model pattern can be simplified based on the project’s needs. For example, if detailed control measures and actions are not required, actions can be omitted, and control measures can serve as the central element for managing the risk. It may also be worth considering moving the deadline from the actions to the control measures.
In this example, you could categorize control measure types, such as preventive and corrective measures. Depending on the project’s needs, you can decide whether to use the typifying property.
Control measures
By configuring Control measure as an inner element, you can create multiple control measures directly from the element.
It is common to see that control measures are applied sequentially in the mitigation of a risk.
Keep control of your control measures model pattern
Creating control measures and assigning them to individuals allows you to track progress on your risks. This also enables a person to view their responsibilities within the risk management framework.
If you prefer not to link individuals directly to control measures for any reason, you might consider relating an element for Roles instead.
TIP: Use the My to-do functionality in the type element settings to manage a person’s responsibilities!
Quantification
Quantifying your risks provides insight into the level at which the risk needs to be addressed. Quantification scores help a project prioritize risks based on factors like time and cost. Additionally, they assist in comparing risks to determine whether control measures effectively reduce risks across the overall project.
Detailed quantifications model pattern
This quantification model pattern allows you to distinguish between the Initial Quantification and the Rest Quantification at the end of a process, such as implementing control measures.
The scores for both the initial and subsequent quantifications can be calculated using a calculated property. Create a Number property and select the Calculated configuration. Based on our experience, the following formula is often used:
{Chance#Factor} * ({Money#Factor} + {Time#Factor} + {Quality#Factor} + {Safety#Factor} + {Environment#Factor} + {Reputation#Factor})
Instead of having a single rest quantification, you might want to consider quantifying multiple times throughout your risk management process. You could create an inner derived element called Quantification, which includes a status property with values such as Actual, Superseded, and Rest. This approach allows you to track all historical quantifications.
Keep in mind that this will display all quantifications when queried in a view. You may want to apply filters to show specific statuses by default in a particular view.
Score formula model pattern
By using a calculated Score property in combination with all List properties, you can enable Relatics to calculate the total score automatically. In this example, we have used the single inner derived element Initial Quantification. Ensure that all properties are set as List properties. Create a new attribute for the list values and enter values that Relatics can calculate.
Next, create a Number property and select the configuration as Calculated. In this case, the following formula can be used:
{Chance#Factor} * ({Money#Factor} + {Time#Factor} + {Quality#Factor} + {Safety#Factor} + {Environment#Factor} + {Reputation#Factor})
