Deliverables, often referred to as Products, are used to define what the (sub-)contractor must deliver to the client. They help maintain an overview of all items to be delivered and, when managed effectively, provide valuable insight into the project’s progress. There is often a strong connection between deliverables, work packages, and activities.
A starting point
Adding deliverables to your project enables you to structure both the work to be completed and the work to be delivered. It assists in planning the entire project.
Breaking down the work for the project can initially be done in a simple manner, serving as the starting point for managing deliverables.
Ensuring quality standards
When deliverables or products are provided to the client, both the client and the contractor expect them to meet high-quality standards. To ensure this quality, requirements are often established to define these standards.
In this context, there are various options to ensure the quality standards of deliverables or products. Depending on your organization’s role within the project, you may choose to adjust the direction of the relationship between the requirement and the deliverable. It ultimately comes down to perspective. In some cases, requirements form the core of the project, whereas for contractors, the deliverable often takes center stage. This may lead to a need to adjust the direction of the relationship.
The next step in ensuring the quality of deliverables or products is to verify whether the items to be delivered meet the established requirements. In the model patterns for verifications [@@URL Verifications@@], we provide further insights into our experiences with verifications between requirements and a third type element.
Including deliverables in the Work Breakdown Structure
In the context of MBSE, a Work Breakdown Structure (WBS) is particularly valuable as 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, enabling a more streamlined and efficient engineering process. Incorporating deliverables into the WBS provides a comprehensive list of tasks required for each product or deliverable to be handed over to a specific party within the project.
Output for the work
Based on our experience, we often observe that deliverables are the output of work packages or, in some cases, even individual activities.
In this case, we would like to highlight the possibility of a deliverable or product being the output of a specific task. In the model pattern, we see a deliverable as the output of either a work package OR an activity. This is achieved through a collection relation between the type elements. If a work package OR an activity is related within the collection relation, the cardinality should be set to single. Of course, this is not the only approach. Depending on the level of detail in the WBS within your project, you may also consider a deliverable as the output of either of the two.
Depending on the level of detail, for example, when the deliverable is only the output of a single work package, you might consider making the deliverable a derived element of that work package. In the article on work packages, we share our experiences where activities are part of a work package. Similarly, you can envision that deliverables can be part of a comparable structure.
Responsibility
Deliverables or products provided by the (sub-)contractor are crucial to the project’s success. In such cases, we often observe that a specific party, person, or discipline is assigned responsibility for creating and delivering the deliverable or product. Below, we will elaborate further on the distinctions between assigning responsibilities.
Straightforward responsibility Contractor versus Client
As a critical type element in projects, we want to highlight both perspectives of the project. While a contractor typically focuses on who within their organization is responsible for a deliverable, the client is often more concerned with which organization in the project holds responsibility for the deliverable. These represent two extremes of the spectrum, but there can also be a combination of these two approaches. For example, when a contractor collaborates with other contractors on a project, they may need visibility into which organization is responsible for a deliverable or when a deliverable has shared responsibility.
Contractor
Client
A detailed organizational approach
For this detailed organizational approach, we assume that a deliverable serves as the output of a work package as a starting point. As an MBSE model becomes more detailed, responsibilities often span multiple levels, reflecting the hierarchical structure of an organization. For example, an organization might be composed of disciplines, which in turn include roles, with individuals fulfilling those roles. In this example, we have focused on a potential way to detail the organizational structure.
When creating and fine-tuning a project where deliverables are produced as outputs of a work package, we often find that responsibility typically lies with a discipline rather than an individual. Between us, when multiple people share responsibility, it often results in no one feeling fully accountable. Therefore, clearly defining responsibilities is essential for ensuring the successful completion of deliverables. In this example, we demonstrate a common approach: using the established responsibility of a discipline for a work package to identify the appropriate individual to take responsibility for the deliverable.
TIP: Use the circular dependency functionality in Relatics to ensure the correct person is assigned responsibility for the deliverable. In this example, a person is part of a discipline that is responsible for the work package producing the deliverable as its output.
This circular dependency generates warnings if the user ignores the dependency, creating a state where the relationships no longer form a cycle.
TIP: Try combining the user link functionality with to-do definitions. This integration allows users to easily access all relevant information through their personal dashboard or the to-do button in the type element overview.
