Work packages are commonly used in projects to break down tasks, actions, and activities. They are a valuable project management tool that provides better control over the project planning process, costs, inquiries, deliverables, and product and/or process requirements.
Minimalistic Work Packages
Work packages allow users to outline the tasks to be completed, providing insight into the planning and progress of the work within the project. This can be done in a simple yet effective manner, by introducing date properties which enable work packages to be planned over time.
Additionally, work packages can bridge the gap between Relatics and a planning tool. The Power User can sort the work package view by start dates to create a clear overview of tasks scheduled over time.
Work Breakdown Structure (WBS)
In the context of MBSE, a 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 Work Breakdown Structure
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 the 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, as shown in the settings image.
Important: 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.
See also:
- Create a hierarchical derived type element
- Tree view for hierarchical models
- Position derived elements in a tree
Work Package 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 relationships 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.
See also: Summary of type element settings
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 settings 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.
See also: Set quality rules for relations
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 on “New Interface”. Note that only elements with ownership set to “External” will appear in the pop-up.
See also:
