Risk management is essential for maintaining project control and ensuring successful outcomes, particularly for complex projects with numerous variables. Quantifying risks through structured probability and impact assessments allows project teams to prioritize and address potential challenges. In Relatics, this process is streamlined with tools that enable precise risk quantification, making it easier to identify, evaluate, and manage risks effectively.

Here’s a step-by-step guide on how to apply risk quantification in Relatics v6, using a probability-impact framework to prioritize risks based on their significance.

1. Setting Up Risk Quantification in Relatics

In Relatics, you can define risk factors based on two key criteria:

• Probability: The likelihood of a risk occurring.
• Impact: The extent of the risk’s effect on the project’s objectives (e.g., time, finances, quality, reputation, and environment).

By using Relatics, you can assign numerical values to probability and impact, often on a 5-point scale, to create a quantifiable risk score. This score provides a standardized way to prioritize risks, allowing your team to focus on those most likely to occur and with the highest potential impact.

Example Scales:

• Probability: Very Low (1) to Very High (5)
• Impact (across multiple dimensions, such as):
  • Time Impact (e.g., minor delay vs. significant project extension)
  • Financial Impact (e.g., small unplanned costs vs. major budget overruns)
  • Quality Impact (e.g., minimal rework required vs. extensive quality issues)
  • Reputation Impact (e.g., minor inconvenience vs. severe brand damage)
  • Environmental Impact (e.g., low disturbance vs. long-term contamination)

2. Implementing Risk Attributes in Relatics

To create a risk quantification framework in Relatics:

• Define Probability and Impact Attributes: Set up probability and impact fields for each risk. These attributes allow you to enter values directly into Relatics for every identified risk.
• Assign Values to Risks: Each risk can be assigned a probability and an impact score based on project data or expert judgment. For instance, a high-likelihood risk of 4 and a high-impact financial risk of 5 would yield a critical risk score.
• Calculate Risk Scores: Relatics can calculate an overall risk score by multiplying the probability and impact values. This quantitative score provides a clear indication of the severity of each risk, which you can then use to prioritize risk responses.

Example Calculation:

• Risk: Potential Delay in Project Permits
• Probability: 3 (Medium likelihood)
• Impact on Time: 4 (Significant timeline impact)
• Risk Score = Probability (3) x Impact (4) = 12 (Moderate-High Priority)

3. Prioritizing Risks with a Risk Overview

Relatics allows you to display risk scores visually, often using a risk overview. The overview provides a clear way to see which risks are high priority (High Probability/High Impact) and which are lower priority.

Creating the Risk Overview in Relatics:

• Design the Overview: Define the overview with a filter with the highest scores on top of the list. Next to that use ‘use cases’ to provied overviews with Risks and the mitigating actions.

4. Automating Risk Monitoring and Notifications

Relatics allows you to set up automated notifications and alerts based on risk thresholds. For example, you can configure the system to notify relevant team members when a risk exceeds a specified threshold, ensuring quick action.

• Quality Rules: You can establish Quality Rules in Relatics that monitor risk-related data entries for completeness and accuracy. For instance, a rule might trigger an alert if a risk is entered without a responsible party or assigned mitigation actions.
• Visual Warnings: When a Quality Rule is violated, Relatics provides visual warnings (e.g., a red flag in the risk table), helping teams quickly identify and address incomplete or missing data.

5. Integrating Risk Quantification with Project Data in Relatics

Relatics makes it easy to integrate risk data with other project information, providing a holistic view of how risks interact with project timelines, budgets, and resources. This integration allows teams to:

• See Dependencies: By linking risks to specific project milestones, resources, or objectives, you can visualize dependencies and understand how risks impact various aspects of the project.
• Align with Project Controls: Link risks to quality controls, cost management, and other project elements, ensuring that risk mitigation efforts are aligned with overall project objectives.
• Generate Reports: Relatics provides reporting tools that enable you to create detailed risk reports for stakeholders, showing quantified risk data, prioritization levels, and mitigation status.

6. Applying the Risk Quantification Output for Decision-Making

The quantified risk scores generated in Relatics are invaluable for decision-making, allowing you to:

• Prioritize Mitigation Efforts: Allocate resources based on risk severity, ensuring that high-priority risks receive immediate attention.
• Optimize Resource Allocation: Use risk scores to guide budget allocation, staffing, and scheduling, focusing on areas with the highest potential impact.
• Enhance Stakeholder Communication: Provide stakeholders with quantifiable risk data and prioritized lists, building confidence in the project’s risk management approach.

Conclusion

Applying risk quantification in Relatics enables project teams to approach risk management in a structured, data-driven way. By systematically assessing probability and impact, teams can prioritize risks, allocate resources effectively, and maintain control over potential project challenges. With Relatics’ powerful integration, automation, and visualization tools, your project risk management process becomes not only more reliable but also more transparent and effective.

Het bericht Risk quantification with Relatics v6 verscheen eerst op Flix consultancy.

The RISMAN method is a well-regarded approach in risk management that focuses on systematically identifying, analyzing, and controlling risks. It highlights two critical factors:

1. Probability – the likelihood of a risk event occurring.
2. Impact – the potential effect on project objectives, such as cost, time, quality, or safety, if the risk event occurs.

By assigning a numerical score to both probability and impact, the RISMAN method allows project teams to calculate a risk score for each identified risk. This score helps the team understand which risks are more significant and require immediate attention, as well as which ones can be monitored with lower priority.

Using the Risk Scores to Prioritize

After calculating risk scores using the probability and impact values, the scores can be plotted on a risk matrix. This matrix helps to visually prioritize risks into categories such as:

• Very High Probability & High Impact (e.g., a highly likely and severe budget overrun) should be top priority, requiring immediate mitigation.
• Medium Probability & Medium Impact (e.g., moderate quality issue with a fair chance of occurring) should be monitored and managed with proactive measures.
• Low Probability & Low Impact (e.g., minor environmental effect with low likelihood) might require basic monitoring but minimal intervention.

This quantification and prioritization enable the project team to focus resources where they are most needed, ensuring that high-impact, high-probability risks are managed efficiently and proactively. By using the RISMAN method, the team not only safeguards project goals but also enhances overall project resilience by creating a structured, prioritized risk management strategy.

Probability Scores (5-Point Scale)

1. Very Low (1) – 0–20% chance of occurring
2. Low (2) – 21–40% chance of occurring
3. Medium (3) – 41–60% chance of occurring
4. High (4) – 61–80% chance of occurring
5. Very High (5) – 81–100% chance of occurring

Impact Examples by Category

1. Time Impact

• Low Impact: Delays due to minor issues, such as a short weather-related delay, extending the project timeline by 1–2 days.
• Medium Impact: Moderate delay due to supplier delays, adding 1–2 weeks to the project.
• High Impact: Significant delay due to a key resource shortage, potentially adding 1–2 months to the timeline.

2. Finance Impact

• Low Impact: Small unanticipated expense due to minor repair costs, increasing the budget by 1%.
• Medium Impact: Unexpected currency fluctuation causing moderate project cost overruns, increasing costs by 10%.
• High Impact: Critical budget overrun due to substantial redesign requirements, pushing costs up by 25% or more.

3. Quality Impact

• Low Impact: Minor quality issue that can be resolved with minimal rework, affecting less than 5% of output.
• Medium Impact: Moderate quality concern, such as a design flaw that affects 20% of the project, requiring significant but manageable rework.
• High Impact: Major quality defect impacting core functionality, risking the usability of 50% or more of the final product.

4. Reputation Impact

• Low Impact: Minor delay in communication with stakeholders, causing brief inconvenience with negligible long-term impact.
• Medium Impact: Moderate issue, such as a delay in delivery, leading to customer complaints and affecting reputation for a few months.
• High Impact: Severe incident, such as a significant product failure in the market, potentially damaging the brand for years.

5. Environmental Impact

• Low Impact: Minor environmental effect, such as increased noise levels during construction, which is easily mitigated with temporary solutions.
• Medium Impact: Moderate impact, such as a chemical spill that requires cleanup and additional regulatory checks but has limited long-term effects.
• High Impact: Significant environmental impact, such as large-scale soil or water contamination, resulting in long-term environmental remediation efforts.

Het bericht RISMAN – Adding quantifications to Risks verscheen eerst op Flix consultancy.

In Relatics v6, you can assign Quality Rules to your model to ensure the integrity of your project data is consistently verified. When a quality rule is violated, the system displays a visual warning at the top of the table, alerting users to any incomplete or incorrect information. This feature helps your project team stay informed about missing data, such as an action without an assigned responsible person or without a specified deadline.

Het bericht Relatics feature: Quality Rules verscheen eerst op Flix consultancy.

The draft state in Relatics v6 is incredibly useful for managing the evolution of data, such as a requirement text in complex projects. Here’s why it plays a critical role:

1. Collaboration and Iteration: During a project, data often requires input from multiple stakeholders (engineers, managers, regulators). Keeping a requirement text in draft state allows everyone to contribute, propose changes, and refine the content without impacting the project’s overall workflow. This ensures all feedback is incorporated before the data is locked.
2. Error Prevention: Implementing premature or incomplete data can lead to costly mistakes. For instance, a partially reviewed requirement text may contain gaps or errors, potentially causing delays or rework. The draft state acts as a quality control measure, preventing unapproved data from being used in execution.
3. Version Control and Transparency: The draft state clearly signals to all team members that the data is still in progress. This avoids confusion between incomplete and finalized documents, ensuring that only reviewed and validated information is acted upon. It provides a transparent workflow where everyone knows the status of the data.
4. Controlled Data Sharing: Keeping a requirement text in draft ensures that sensitive or incomplete information is not shared prematurely with external parties, such as contractors. This reduces the risk of miscommunication or the use of outdated requirements.

For example, in a complex infrastructure project, a requirement text outlining safety standards for bridge construction may initially be in draft state. This indicates the text is still under review and subject to changes by engineers and safety officers. While in draft, the requirement is not yet approved or visible to external contractors. Once all stakeholders have reviewed and validated the content, the requirement text is finalized, published, and shared for execution, ensuring accuracy and compliance.

Lets add draft state to text in Requirements Element. Look into the video:

Het bericht Draft state on data in Relatics v6 verscheen eerst op Flix consultancy.

Introduction to Hierarchical Derived Elements in Relatics
In complex engineering and construction projects, organizing data and managing relationships between different components is essential. Tools like Relatics v6 provide a powerful way to manage these relationships using Hierarchical Derived Type Elements. This feature allows users to define parent-child relationships between elements within a system, enabling the breakdown of complex structures into manageable parts.

What Are Hierarchical Derived Type Elements?

Hierarchical Derived Type Elements are used to define logic between different types of elements or within the same element. They allow users to create parent-child relationships within a hierarchy, providing a clear organizational structure. There are two primary configurations in Relatics v6 for hierarchical-derived elements:

1. Parent-Child Relationships Between Different Elements: In this configuration, a parent element has child elements that are of a different type. For example, a Work Package (the parent) may contain several Activities (the children), representing specific tasks required to complete the work package. These elements are linked to one another in a clear hierarchy, allowing for better management and visibility of related tasks.
2. Recursive Relationships Within the Same Element: This configuration involves an element acting as a parent and a child within the same element type. An example is a Work Breakdown Structure (WBS) or System Breakdown Structure (SBS), where an element like “Activity” can have sub-activities, further breaking down tasks. In this setup, an element (e.g., “Activity”) can be recursively linked to itself, forming a multi-level structure. This is useful for creating detailed breakdowns of a system, where each level can be explored further to reveal smaller components.

Benefits of Hierarchical Derived Elements in Relatics

1. Structured Data Management: By utilizing hierarchical-derived elements, Relatics enables users to organize large datasets in a logical, tree-like structure. This structure allows for the systematic breakdown of complex systems into smaller, manageable components, making it easier to track and manage the flow of tasks or elements.
2. Efficient Task Tracking: With hierarchical derived elements, the relationship between parent elements (such as Work Packages) and their child elements (such as Activities) is automatically maintained. This ensures that tasks are derived in a way that simplifies workflow management, improving efficiency. For example, as activities are completed, the system can automatically update the status of the associated work package.
3. Consistency and Data Integrity: The dynamic nature of hierarchical-derived elements ensures that data remains consistent across the system. When changes are made to a parent element, the related child elements are automatically updated, ensuring that the hierarchy remains accurate and that the data within the system is reliable.
4. Tree View Representation: Relatics v6 offers a tree view for hierarchical-derived elements, providing users with a visual representation of the relationships between different elements. This makes it easy to understand the hierarchy and navigate through different levels of the structure.

Real-World Applications of Hierarchical Derived Elements in Relatics

1. Work Package and Activity Management: One of the most common uses of hierarchical-derived elements in Relatics v6 is to manage the relationship between Work Packages and Activities. Work Packages often represent larger tasks or deliverables in a project, while Activities are the individual tasks required to complete them. By setting up a hierarchical structure, Activities are derived from their associated Work Package, ensuring a clear link between the two and improving overall project tracking.

1. System Breakdown Structures (SBS): Hierarchical-derived elements are also useful in defining System Breakdown Structures (SBS). For example, in a construction project, the main element “Building Structure” could have child elements like “Foundation,” “Walls,” and “Roof.” One of these child elements, such as “Walls,” can further be broken down into sub-elements like “Exterior Walls” and “Interior Walls.” This recursive hierarchy allows users to dive deeper into the project structure, revealing increasingly detailed components of the system.

Instruction for breakdown structures (Trees)

1. Create a hierarchical-derived type element
2. Create a standard type element.
3. Create a type relation of single cardinality originating from the just-created type element and set the to-element to this same type element.
4. In the Type graphview, click on the just-created type element.
5. In the toolbox, click on Edit.
6. On the tab Advanced, change the field Configuration to Derived.
7. On the tab Advanced, change the field Origin relation to the desired relation. The checkbox for Hierarchical is automatically active.
8. Click on Update.

Het bericht Creating derived elements with parent-child & breakdown structures in Relatics v6 verscheen eerst op Flix consultancy.

Imagine you have two pieces of information, like a requirement for a product (let’s call it a “Requirement”) and the product itself (an “Object”). You might want to show how the requirement connects to the product—this is a simple relationship. But sometimes, this relationship needs extra details or context to make the connection more meaningful. This is where the concept of a “middle element” comes into play.

What is a Middle Element?

A middle element is a special piece of information that sits between two other pieces of information, providing more clarity about their relationship. It doesn’t just say, “these two are connected”; it helps explain how or why they are connected.

An Example

Let’s say you want to verify that a specific requirement is met by a product. In this case, the middle element could be something called “Verification.” Instead of directly linking the “Requirement” to the “Object” (the product), we introduce “Verification” as a bridge. This middle element carries extra details, like the result of the verification process. Now, the relationship is richer because we know not just that the requirement and product are linked, but that there’s a verification process between them, and we can even include more information about how that verification was done or the outcome.

Another Example

Consider two objects that need to work together. Instead of just saying “Object A” is connected to “Object B,” you can use a middle element called “Interface.” This element explains how the two objects interact or communicate with each other. So, “Interface” becomes the bridge, carrying details about how the connection works.

Adding More Information to the Middle Element

Just like other pieces of information, middle elements can be enriched with additional properties. For example, the “Verification” middle element might have a property like “Result” that specifies whether the verification was successful or not. Similarly, you can also define relationships between the middle element and other types of information. For instance, you might say, “Verification” is connected to a “Method” that explains how the verification was done.

Why Is This Important?

Using middle elements helps make relationships between pieces of information more detailed and meaningful. Instead of a simple connection, you can add context, explanations, and results, which provides a fuller picture of how different pieces of information are related.

In summary, a middle element is like an enhanced connection between two pieces of information. It enriches relationships by adding important details that can clarify or explain the link between two elements. Whether you’re verifying a requirement or showing how two objects interact, middle elements make the relationship clearer and more informative.

An example in our training:

Het bericht Middle element in Relatics V6 verscheen eerst op Flix consultancy.

A derived type element is a special type element that is distinguished by the fact that these elements depend on an element of another type element. A derived element has no right to exist without a relation to an origin element.

Create a new derived type element

When a new derived type element is created, the software creates a type element and a type relation where the to-element is the type element from which the action originates.

1. In the workspace menu, click on  Type graphview.
2. In the model, click on the type element to which a new derived type element should be added.
3. In the toolbox, click on New derived element. As a result, the dialog New derived element – Origin is opened.
4. Enter the settings conforming to the purpose of the derived element.
5. Click on Create. As a result, the dialog is closed and the new derived type element is created.

Note:

• In the type list, a derived type element appears indented below the origin type element.

Exercise:

Attempt to add “Comments” as Inner Elements to Requirements and publish the changes.

Engage in a hands-on experience by adding comments to one of the requirements to observe the desired result.

Typically, inner elements remain hidden and are not visible under the main elements tab unless we enable them by clicking on “Show Inner Elements”.

Het bericht Derived type element verscheen eerst op Flix consultancy.

Key Features of a Relation:

• Entities: The things or concepts being related, like a person, a document, or a requirement in a system.
• Direction: Indicates the flow of the relationship, showing which entity is the “owner” or initiator of the relation and which is the “target”. For example, in “Person A manages Project B”, Person A is the owner, and Project B is the target.
• Role: Describes the nature of the relation, often using a verb or meaningful label (e.g., “has”, “manages”, “belongs to”) that defines the relationship between entities.

In semantic databases like Relatics, relations are critical for linking data in a meaningful way, enabling queries and reasoning across the connected data points.

Example:

• The hasResponsible relation helps the project team easily identify which team member is responsible for handling any issues or irregularities related to a specific requirement. This way, if a problem arises, they know exactly who to contact.
• The hasSource relation is used to record where a particular requirement originated from. For example, if the requirement came from a specific document, this relation will show which document was the source.

Het bericht Creating relations between elements verscheen eerst op Flix consultancy.

Update a type property

1. In the workspace menu, click on Type graphview.
2. In the model, click on V in the label of the type element name.
3. Click on the name of the property.
4. In the toolbox, click on Edit. As a result, the dialog Type property settings is opened.
5. In the dialog Type property settings, update the settings of the type property.
6. Click on Update. As a result, the dialog is closed, and the type property is updated.

Notes:

• Double-clicking the type property is another way to open the dialog Type property settings.
• As an alternative to the Type graphview, a type property can be updated using the detail view.

Het bericht Renaming or updating properties in Relatics v6 verscheen eerst op Flix consultancy.

You are able to organise the left side menu by clicking the three dots and re-organise to your project need. You can even add sections that will appear as grouping option in your menu.

With the grouping possibility you can create project specific overviews that resemble the project organisation and structure.

Het bericht Organise your main menu in Relatics v6 verscheen eerst op Flix consultancy.