Design patterns

Table of Contents

Work packages

Work packages are commonly incorporated into the Systems Engineering (SE) model of projects to break down tasks, actions, and activities. Work packages are a valuable project management tool that provides better control over the project planning process, costs, inquiries, deliverables, and product and/or process requirements.

Based on observations at projects, the basic model consists of a type element named Work Package, which includes type properties to store the Name, Description, Objective, Start date, and End date.

Typically, the type property Name has a data type of Single line text (to provide a brief title for recognizing the work package), the type property Description has a data type of Text (to provide a more detailed description of the work package), and the type property Objective has a data type of Text (to explain the goal of the work package). Additionally, the type property Start date has a data type of Date (to provide the initialization date of the work package), and the type property End date has a data type of Date (to provide the date when the work package is finished).

Hierarchy

In the context of Systems Engineering (SE), a Work Breakdown Structure (WBS) is particularly valuable because it aligns with the model-based approach to defining and managing complex systems. It ensures that every aspect of the system is accounted for and integrated into the overall project plan, promoting a more streamlined and efficient engineering process.

Breaking down work in the WBS

When a project requires work to be broken down due to its complexity, we often see the introduction of work packages and activities. This model pattern uses recursive work packages to create a tree view in the application.

Each Work package can contain one or more activities, and completing all work packages signifies that the project’s tasks are fully completed.

In Relatics, when a type element has a single relation to itself and is configured as hierarchical in the type element settings, the system automatically visualizes the tree view. This view appears as the first tab at the top of the screen after selecting the menu item.

In this example, we created a hierarchy for Work package. This was achieved by establishing a relation from the Work package type element to itself. This setup allows users to create child work packages directly within the context of a parent work package. To enable this, the type element Work Package must be set as a derived element.

Note that, to configure the Work Package type element as derived from itself, the relation from Work Package to Work Package must be a single relation rather than a multi-relation.

Lifecycle

When tracking work packages over time, it is common to add a Status property to the model with the data type set to List. Examples of list values include Actual and Rejected. This helps filter out work packages that are no longer relevant.

If some work packages are expected to become irrelevant to the project over time, it is helpful to configure the Status property as a Lifecycle property for the Work Package type element. Additionally, by enabling the Auto archive setting and selecting relevant archive values (e.g., Rejected), only relevant work packages will be displayed in the views by default.

TIP: Be cautious when setting a lifecycle property for the Work Package type element, especially when combined with a hierarchy. Using Auto archive with a hierarchy can be problematic, as it becomes difficult to interpret child work packages of an archived parent work package. Therefore, it is advisable to use a lifecycle property only when there is no hierarchy or breakdown structure.

Responsibility

Person approach

A common challenge we observe is that when work packages are ready for progression, a lack of assigned responsibility often leads to no one taking charge. Establishing relations to individuals in Relatics ensures clear responsibility and allows those individuals to track their tasks.

In this setup, each work package can have a designated responsible person. For work packages that include multiple activities, different individuals can be assigned to specific activities. This setup enables the responsible person for the work package to delegate tasks to their colleagues.

TIP: Implement the User link functionality in combination with My to-do definitions! This combination allows users to access all relevant information through their personal dashboard or the to-do button in the type element’s overview page ribbon.

Finetuning via disciplines

In large, complex projects, we often observe a trend toward fine-tuning information, particularly when it involves assigning responsibilities to individuals. Initially, the responsibility for a significant number of work packages and activities is often broadly assigned to disciplines rather than directly to individuals.

This approach is typically used at the early stages of a project when specific responsibilities are not yet fully defined. Disciplines such as Engineering or Project Management are used as placeholders. This ensures that only individuals related to the discipline responsible for the work package can later be assigned to its associated activities. It is particularly useful when detailed information about individual assignments is not yet available.

In some cases, projects choose not to use the discipline concept. Instead, a type element like Role is implemented to define responsibilities.

TIP: Utilize the Circular dependency setting on a relation as a quality rule! This filters the results in the selection dialog to the results related to the quality rule. For example, you could create a rule for the relationship between an Activity and a Person:Only display individuals who belong to the discipline responsible for the work package associated with this activity”.

This approach simplifies the assignment process and ensures that only relevant individuals are included in the selection.

Planning and control

Once work packages are created and their activities are specified, work needs to be planned. As the project progresses through its lifecycle phases, the nature of the work evolves. A common first step during planning is to associate the work packages with their intended outputs. In this example, we use Objects as outputs to be realized by the work packages. However, depending on the project, outputs could also include Documents or Deliverables.

As with assigning responsibilities, planning often begins with a rough outline that becomes more detailed over time. Early in the project, work packages are roughly assigned to phases, providing a high-level overview of when outputs should be realized. This phase-based approach serves as a foundation for more precise planning, including specific dates and detailed schedules.

By associating work packages with phases, project teams can gain an overview of the broader timeline. As planning progresses, specific properties like start and end dates and status properties enable more detailed scheduling and tracking of the progress of work packages and their activities.

External sources

In complex projects, multiple software tools are often used to manage different aspects of the project. When Relatics is used as a single central platform, all disciplines are connected, and information is semantically linked. However, when multiple tools are involved, information is often “owned” by these external tools. For instance, work packages may be managed in a specialized planning tool like Primavera or a similar application.

In such cases, work packages in Relatics are treated as external elements. Through integrations, Relatics can synchronize and display information managed in these external tools. When an element is designated as external, it cannot be configured as a derived or inner-derived element. Unlike the hierarchical model pattern discussed in the chapter “Breaking down work in the Work Breakdown Structure”, the is part of relation is configured as a single standard relation. Since work packages are created and maintained in an external tool, there is no need to create them in Relatics.

External elements are visually distinguished in the Type graphview by an additional icon that signifies their external status. Similarly, if activities are also managed in an external planning tool, their ownership should shift to that tool. In such a scenario, the type element for activities should also be changed from derived to standard to reflect this integration.

When an integration is created at the environment level, an interface for the type element can be set up within the project workspace by selecting the Application Integration menu item and then clicking New Interface.

Note that only elements with ownership set to External will appear in the pop-up.

Relatics is the leading Model-Based Systems Engineering (MBSE) software application for construction projects. It is the comprehensive tool that gives professionals access to all project information and offers insight into the growing number of dependencies between all disciplines in today’s projects.

The aim of this article, part of a series of articles, is to provide you with basic knowledge about Systems Engineering elements and its application within the Relatics 6 software. Should you wish to proceed with Relatics 6 on your own projects and require assistance, please do not hesitate to contact us. Our consultants are ready to provide you with the support you need. If you miss an SE pattern in this series, please let us know.

Pioneers in Systems Engineering [book]
Insights from 50 professionals from the Dutch construction industry.

Download our free whitepaper with 7 success factors for implementing Systems Engineering on your project.

Download our free whitepaper to discover why construction projects still struggle with failure costs.

Request a demo

Fill in our form and one of our colleagues will contact you as soon as possible to schedule a demo.

Please enable JavaScript in your browser to complete this form.
Please enable JavaScript in your browser to complete this form.

Download the whitepaper

Please enable JavaScript in your browser to complete this form.
Addresss

Get in touch

Fill in our form and one of the Relatics members will contact you as soon as possible. Do you prefer contact by phone? Please call us at +31 180 413 047.
Please enable JavaScript in your browser to complete this form.