With environmental dynamics constantly causing changes, construction projects often decide to include changes in their Systems Engineering (SE) model. This helps clarify the project’s scope and assess the changes’ impact. As a result, changes can lead to modifications of specifications (e.g., requirements) or changes in the design (e.g., objects). Often, processes between the client and contractor support the formal communication on changes. For example, a contractor can submit proposed changes to the client through a change request (also referred to as a variation request or a variation order request), which must be reviewed and approved by the client. Changes accepted by the client are shared through a change order (also called a variation order), which officially amends the contract. In SE models of projects, the terms change and variation are often used to support similar processes. For clarity and simplicity, the term change will be used hereafter.
Based on observations at projects, the basic model consists of a type element named Change. Typically, the type element Change includes type properties to store the name and description:
- The type property Name has a Single line text data type (to contain a brief title for identifying the change).
- The type property Description has a Text data type (to provide a more detailed description of the change).
Scope
Most changes target elements from the SE model. Depending on the ambition level, projects implement different design patterns in their model to keep track of the elements subject to changes and the type of modification they are concerned about.
Changes describing modifications of type elements
Most projects support processes in which changes can lead to the modification (also referred to as alteration) of various type elements from the SE model, such as requirements, objects, and documents. When analyzing elements in the SE model, a user can be triggered to create a change for them. For example, when you realize that a requirement specified in the original contract needs to be altered. As a result, the related changes provide traceability from the perspective of the elements.
In the model, a type relation, modifies, is created between the type element Change and another set of type elements, e.g. Requirement. In practice, the cardinality of the type relation is set to Multi because multiple elements can be the subject of a change. Finally, it may be useful to set the range of the type relation to Collection when the meaning of the type relation (e.g., modifies) is the same for the various type elements within the context of the change.
TIP: By using the relatable elements view, a user can create changes directly from the perspective of an element whose type element is related to the type element Change.
NOTE: Setting the range of the type relation to Collection only supports five type elements. When more than five type elements are the subject of a change, it is advised to set the range of the type relation to Standard and use distinct role names for each type relation.
Changes describing different types of modifications for type elements
Projects sometimes want to describe the type of modification for some type elements of the SE model that are subject to change. The advantage is that this allows users to filter the different types of modifications more easily. In practice, this is mainly applied to requirements. As a result of a change, it is described whether requirements are (planned to be) added, updated, or removed.
In the model, a type relation, adds, is created between the type elements Change and Requirement. In practice, the Cardinality of the type relation is set to Multi. As a result of a change, multiple requirements can be added. Similarly, a type relation, updates, is added to the model between the type elements Change and Requirement to describe updated requirements, and a type relation, removes, is added to the model between the type elements Change and Requirement to describe omitted requirements.
Changes with more detailed modifications of type elements
When projects want to track modifications of certain individual elements in more detail, they can decide to include modifications as dedicated elements to the SE model. The advantage is that modifications of individual elements (e.g., requirements) can be described in more detail in the context of the overall change. This not only answers what has changed (e.g., which requirements) but also indicates how and why the change was made in more detail.
In the model, a middle type element Modification is created for the type element Change. Typically, the cardinality of Modification is set to Multi to allow users to create multiple modifications as part of a change. The target relation of Modification is set to Requirement. As a result, modifications can only be created for combinations of a Change and a Requirement. Typically, the type element Modification includes type properties to store the category, remark, and status:
- The type property Category has a List data type (to classify the type of modification). Examples of typical list values include Addition, Update, and Removal.
- The type property Remark has a Text data type (to contain an optional comment on the modification).
- The type property Status has a List data type (to indicate the lifecycle of the modification). Examples of typical list values include Actual and Rejected.
TIP: The compare mode can be used as a complementary tool for identifying and validating modifications stored explicitly in the model.
Lifecycle
When monitoring the handling of changes over time, adding a type property Status to the model with the List data type is often beneficial. Examples of typical list values include Proposed, Approved, and Rejected. This makes it easier for users to filter out irrelevant changes. In most cases, the list value Proposed is set as the Default. As a result, every newly created change will be automatically assigned the status value Proposed.
If some changes 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 changes will be displayed by default in the views.
Source
Changes can result from other elements in the SE model. For example, organizations, nonconformities, and documents are in practice related to changes by projects as the origin.
Organizations
In basic change management processes of projects, the initiator of a change is tracked. In most cases, this concerns organizations, although it can also concern persons, depending on the project processes. As a result, it is traceable where a change originates from.
In the model, a type relation, is initiated by, is created between the type element Change and Organization. In practice, the cardinality of the type relation is set to Single. This enforces multiple changes to be made when multiple organizations suggest similar changes. This optimally supports traceability as the original input can be matched to the corresponding organization.
Nonconformities
A nonconformity may indicate that updating the design has disadvantages that outweigh the advantages. In such cases, projects can propose updating the requirements through a formal change process. Most projects use a structured change management process, where nonconformities serve as one of the inputs.
In the model, a type relation, is result of, is created between the type element Change and Nonconformity. In practice, the cardinality of the type relation is set to Multi, allowing broadly applicable changes to be linked to multiple nonconformities.
Documents
Documents describing a change (e.g. an email, a textual file, a spreadsheet, etc.) are often made part of the SE model. This enhances the traceability of a change, allowing users to verify its existence and access more detailed information.
In the model, a type relation, has source, is created between the type element Change and Document. In practice, the cardinality of the type relation is set to Multi since multiple files can be the source of a change over time.
TIP: By setting the ownership of the type element Document to External application, you can work with external data. In this example, the set of documents in Relatics can be automatically synchronized with the list of documents in the project’s DMS.
Result
Often, projects analyze the consequences of a change in the change management process. The impact of a change is described in various categories (e.g., financial, time, quality, safety, risk, and environment).
Impact with quantifications
It is common for projects to quantify and qualify the impacts of changes for various categories. This allows users to compare various changes per impact category.
In the model, a derived type element Impact is created for the type element Change. Typically, the cardinality of Impact is set to Single as each category is assigned one value. Additionally, the setting Act as inner element is enabled for the derived type element. Since most users are not interested in seeing a complete overview of impacts for all changes, an Impact is usually considered an inner type element. Typically, the type element Impact includes type properties to store values for various categories:
- The type property Financial has a Number data type (to quantify the change financially).
- The type property Time has a Number data type (to quantify the lead time in days, weeks, months, etc.).
- The type property Quality has a List data type (to qualify the impact of the change on the specifications based on a predefined set of list values).
- The type property Safety has a List data type (to qualify the effect of the change on the safety based on a predefined set of list values).
- The type property Risk has a List data type (to qualify the impact of the change on the risks based on a predefined set of list values).
- The type property Environment has a List data type (to qualify the effect of the change on the environment based on a predefined set of list values).
Impact with qualifications and explanations
A more advanced SE model pattern used by projects contains additional explanations of the quantifications. These qualitative explanations help answer the why question next to the what question answered by the (semi)quantifications regarding the impact of the change.
In the model, a derived type element is created for the type element Change for each of the categories: Financial Impact, Time Impact, Quality Impact, Safety Impact, Risk Impact, and Environmental Impact. Typically, the cardinality of each of the derived type elements is set to Single as each category is assigned only one value and explanation. Additionally, the setting Act as inner element is enabled for the derived type element as most users are not interested in seeing a complete overview of impacts for all changes.
Typically, each of the derived type elements includes type properties to store a quantification and explanation:
- The type property Quantification has a Number or List data type (to quantify or quantify the change of the corresponding category).
- The type property Explanation has a Text data type (to describe in full text the rationale of the provided quantification).
Communication
Projects tend to organize changes (e.g. in change requests, change orders, or change notices) so they can be effectively communicated to other parties.
Change requests
It is common practice for contractors to propose changes to a client through a change request (also known as variation request or variation order request). The client reviews and approves the change request, and when accepted, the changes become part of a change order, which officially amends the contract.
A type relation, is requested in, is created between the type element Change and Change Request. In practice, the cardinality of the type relation is set to Multi as changes can be submitted in multiple change requests over time.
Change orders
As described above, change orders (also known as variation orders) can result from the client’s approval of change requests sent by contractors. Alternatively, during the project’s lifecycle, clients can also identify changes to the original contract themselves, which are directly shared with contractors through change orders.
A type relation, is ordered by, is created between the type element Change and Change Order. In practice, the cardinality of the type relation is set to Multi as changes can be shared in multiple change orders over time.
Change notices
Sometimes, contractors use change notices (also known as variation notices) to formally notify the client that potential changes to the original contract are to be expected. This proactive form of communication helps to mitigate possible future costs.
A type relation, is noticed in, is created between the type element Change and Change Notice. In practice, the cardinality of the type relation is set to Multi because changes can be communicated in multiple change notices over time.
