Deliverables, often referred to as Products, are used in construction projects to define what a contractor or engineering consultancy firm must deliver to the client. Deliverables and products are primarily concerned with documents (e.g. a project management plan or risk register). Keeping track of deliverables and products helps to maintain an overview of all items to be delivered and, when managed effectively, provides valuable insight into the project’s progress. In Systems Engineering (SE) models of construction projects, the terms deliverable and product are often used interchangeably. For clarity and simplicity, the term deliverable will be used hereafter.
Based on observations at projects, the basic model consists of a type element named Deliverable. Typically, the type element Deliverable includes type properties to store the name and description:
- the type property Name has a data type of Single line text (to contain a brief title for identifying the deliverable);
- the type property Description has a data type Text (to provide more details on the deliverable).
Deliverables and documents share similarities. Whereas deliverables concern a list of products (mainly documents) that are subject to requirements and that have to be developed and delivered to the client by a contractor or engineering consultancy firm at various stages of the project, documents concern any file that is the project’s input or output. In other words, not every document is a deliverable, but most deliverables will become documents over time.
Structure
Deliverables are often structured in work packages. This helps contractors and engineering consultancy firms break down the work of producing the deliverables and providing them to the client.
Work packages with unique deliverables
One way how projects structure deliverables is by creating unique deliverables per work package. The advantage is that work package-specific deliverables can be directly linked to the actual product, for example, a specific document stored in a Document Management System (DMS). This makes it easy to track and verify a particular deliverable.
In the model, for the type element, Work Package, a derived type element, Deliverable, is created. Typically, the cardinality of the derived type element is set to Multi, as multiple deliverables can be part of a work package.
The properties of the deliverable are similar to those described in the model pattern in the introduction.
Work packages with reusable deliverables
Another way projects structure deliverables is by allowing deliverables to be part of multiple work packages. The advantage is that deliverables that need to be produced repeatedly can be reused for multiple work packages.
In the model, a type relation, is grouped in, is created between the type elements Deliverable and Work Package. In most cases, the cardinality of this relation is set to Multi. This allows deliverables to be reused in multiple work packages.
Lifecycle
When monitoring the handling of deliverables over time, adding a type property Status to the model with the data type List is often beneficial. Examples of typical list values include Actual and Rejected. This makes it easier for users to filter out irrelevant deliverables. In most cases, the list value Actual is set as the Default. As a result, every newly created deliverable will be automatically assigned the status value Actual.
If some deliverables are expected to become irrelevant to the project over time, it is advisable to configure the type property Status as a Life cycle property. Optionally, by enabling the Auto archive setting and selecting appropriate archive values (e.g., Rejected), only relevant deliverables will be displayed by default in the views.
Responsibility
Often, a specific person, organization, or discipline is assigned responsibility for creating and providing the deliverable.
Straightforward responsibility for contractors or engineering consultancy firms
A contractor or engineering consultancy firm typically focuses on which person within their organization is responsible for a deliverable.
In the model, a type relation, has responsible, is created between the type elements Deliverable and Person. In most cases, the cardinality of this relation is set to Single. Allowing only one person to be stored as responsible for the deliverable ensures clarity about who the point of contact is to follow up on the deliverable.
Straightforward responsibility for clients
On the other hand, the client is often more concerned with which organization in the project holds responsibility for the deliverable. This represents another extreme of the spectrum compared with the contractors or engineering consultancy firms, but there can also be a combination of these two approaches. For example, when a contractor or engineering consultancy firm collaborates with others on a project, they may need visibility into which organization is responsible for a deliverable or when a deliverable has a shared responsibility.
In the model, a type relation, has responsible, is created between the type elements Deliverable and Organization. In most cases, the cardinality of this relation is set to Single. Allowing only one organization to be stored as responsible for the deliverable ensures clarity about the point of contact to follow up on the deliverable.
A detailed organizational approach
As a starting point for this detailed organizational approach, it is assumed that a deliverable serves as the output of a work package. As an SE 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 individual persons fulfilling those roles.
When creating and fine-tuning a project where deliverables are produced as outputs of a work package, responsibility typically lies with a discipline rather than an individual. As multiple persons can have the same discipline, there is a risk that no one will act as the involved persons are looking at each other. Therefore, clearly defining responsibilities is essential for ensuring the successful completion of deliverables. An idea is to use the established responsibility of a discipline for a work package to identify the appropriate individual person to take responsibility for the deliverable.
TIP: Use the circular dependency feature to ensure the correct person is assigned responsibility for the deliverable relative to the person’s discipline related to the corresponding work package. The circular dependency generates warnings when the related deliverables, persons, disciplines, and work packages do not commonly match.
Source
Often, deliverables are the output of engineering or construction activities (e.g., designing, excavating, pouring concrete, etc.) in the form of documents that have to be provided to the client.
Deliverables that are the output of multiple activities
Keeping track of deliverables per activity helps projects ensure that nothing is overlooked when performing the activities and producing and providing the supported deliverables. In some cases, deliverables are created as an output of multiple combined activities. For example, when the deliverable is part of the same scope (e.g., a certain work package) and addresses multiple activities within the same scope.
In the model, a type relation, is output of, is created between the type element Deliverable and Activity. In practice, the cardinality of the type relation is set to Multi to allow generic deliverables to be reused.
TIP: Use the circular dependency feature to ensure that deliverables can only be the output of an activity for shared work packages.
Deliverables that are the output of unique activities
In other cases, deliverables are always uniquely created for activities within the same scope (e.g., a specific work package). The advantage is that the deliverables can be directly linked to an actual activity in a specific work package, for example, a specific document stored in a Document Management System (DMS). This makes it easy to track and verify an activity-specific deliverable.
In the model, a type relation, is output of, is created between the type element Deliverable and Activity. In practice, the cardinality of the type relation is set to Single to ensure that deliverables are unique for an activity in the context of a work package. An advantage of using a relation as opposed to making the type element, Deliverable, a derived type element is that deliverables can already be created when there is no activity yet. This provides more flexibility to the project.
Specification
Deliverables provided by the contractor or engineering consultancy firm commonly have to meet the client’s requirements. These can range from content requirements to formatting and layout requirements.
Requirements that can specify multiple deliverables
Client projects and engineering consultancy firms’ projects, in which the SE processes mostly focus on the left-hand side of the V-model, typically experience requirements to play a central role in their SE model. Therefore, in many cases, deliverable requirements are assigned the ownership of the specification. In the SE model, this is translated into a type relation that is directed from the type element Deliverable Requirement to the type element Deliverable.
In the model, a type relation, specifies, is created between the type elements Deliverable Requirement and Deliverable. In most cases, the cardinality of this relation is set to Multi. This allows generically formulated requirements to be reused for multiple deliverables.
Requirements that uniquely specify a single deliverable
A variant on the above model pattern concerns an SE model in which each deliverable requirement is uniquely defined to always specify a single deliverable. An advantage is that all the information related to the requirement (e.g. verifications) can directly be interpreted to be relevant for the deliverable, which can make it easier to understand the requirement.
In the model, a type relation, specifies, is created between the type elements Deliverable Requirement and Deliverable. In most cases, the cardinality of this relation is set to Single. This allows unique requirements that specifically address a single deliverable to be applied to the corresponding deliverable.
Deliverables that can be specified by multiple requirements
On the contrary, contractors’ projects, in which the SE processes focus, for the most part, on the right-hand side of the V-model, are inclined to give deliverables (as opposed to requirements) a more central position in their SE model. In the SE model, the ownership is reflected by the direction of the specification relation that points from the type element Deliverable to the type element Deliverable Requirement.
In the model, a type relation, is specified by, is created between the type elements Deliverable and Deliverable Requirement. In most cases, the cardinality of this relation is set to Multi. This allows generically formulated deliverables to be reused for multiple requirements.
Compliance
It is common practice for contractors’ projects and engineering consultancy firms’ projects to verify deliverables specified by the client. In some cases, clients also perform verifications for the requirements specified for deliverables. For example, they can track and check the verifications in their own SE model. Evaluations and reviews are synonyms used for verifications.
Verifications of requirements that can specify multiple deliverables
Client projects and engineering consultancy firms’ projects primarily verify the deliverable requirements, to be more specific, in the context of the deliverable. As their SE processes mainly focus on the left-hand side of the V-model, the deliverable requirements play a central role in the SE model and are typically the owners of the relation to the deliverables. Consequently, the deliverable requirements are also the primary owners of the verifications. The deliverables specified by the verifications can be considered the subject of the verification.
In the model, for the type element, Deliverable Requirement, a middle type element, Verification, is created. Typically, the cardinality of the middle type element is set to Multi, as multiple verifications can be made for a deliverable requirement over time (e.g., to perform verifications in different phases). The Target relation is set to the type relation, verifies, between the type elements Verification and Deliverable. As a result, verifications can only exist for combinations of a deliverable requirement and a deliverable.
Typically, the type element Verification includes type properties to store the phase, method, result, and explanation:
- the type property Phase has a data type of List (to contain a predefined set of phases in which the verification needs to take place). Examples of typical list values include Basic Design, Detailed Design, and Realization;
- the type property Method has a data type of List (to contain a predefined set of methods that need to be used to verify the deliverable requirement). Examples of typical list values include Document inspection and Audit;
- the type property Result has a data type of List (to contain the outcome of the verification). Examples of typical list values include Compliant and Non-compliant;
- The type property Explanation has a data type Text (to provide additional comments on the result, for example, in case the verification is non-compliant).
In the model, a type relation, has evidence, is created between the type elements Verification and Document. This helps a user refer to a document, for example, that is stored in a Document Management System (DMS) and contains evidence that backs up the result of the verification. In most cases, the cardinality of this relation is set to Multi. This allows multiple documents to be related as the evidence of a verification.
TIP: Set the feature Existence of middle element for the type element, Verification, to Required for each relation of and select the type relation, specifies, between the type elements Deliverable Requirement and Deliverable. As a result, a user can only create verifications when there is at least one specification relation between a deliverable requirement and a requirement. In many cases, there is no meaning in creating verifications for a requirement when the requirement is not applied.
TIP: Use the feature Criteria for allowed To elements and set the feature Criterion type to Circular dependency to restrict that a verification matches a unique combination of a deliverable requirement and a deliverable. In most cases, it is desirable that only the specified deliverables are taken into account.
Verifications of requirements that uniquely specify a single deliverable
Consequently, when requirements are uniquely created for each deliverable, it is common to create requirement-specific verifications in the SE model. In this way, each verification resembles a unique combination of a deliverable and a deliverable requirement.
In the model, for the type element, Deliverable Requirement, a derived type element, Verification, is created. Typically, the cardinality of the derived type element is set to Multi, as multiple verifications can be made for a unique combination of a deliverable requirement and a deliverable over time (e.g., to perform verifications in different phases).
The properties and relations of the verification are similar to verifications, as described for the model patterns above.
Verifications of deliverables that can be specified by multiple requirements
On the contrary, contractors’ projects primarily verify the deliverables. With SE processes mainly focusing on the right-hand side of the V-model, the deliverables play a central role in the SE model and are, therefore, typically the owners of the relation to the deliverable requirements and the primary owners of the verification.
In the model, for the type element, Deliverable, a middle type element, Verification, is created. Typically, the cardinality of the middle type element is set to Multi, as multiple verifications can be made for a deliverable over time (e.g., to perform verifications in different phases). The Target relation is set to the type relation verifies between the type elements Verification and Deliverable Requirement. As a result, verifications can only exist for combinations of a deliverable and a deliverable requirement.
The properties and relations of the verification are similar to verifications, as described in the model pattern above.
