Meetings

Construction projects often include meetings in their Systems Engineering (SE) model to discuss ideas, findings, comments, constraints, or dependencies identified for various elements in the model. Some projects keep track of a generic list of meetings that address various subjects from the SE model (e.g., Actions, Requirements, Interfaces, Changes, Permits). This is practical when it is common to discuss topics from different elements during the same meeting. In contrast, other projects prefer to keep track of dedicated meetings for certain elements in the SE model. This is preferred when specific needs exist for each type of meeting (i.e., differences in type properties and type relations in the SE model). The added value of adding meetings to the SE model is that it helps to make decisions explicit and makes it traceable for related elements regarding the origin of the result of the decision.

Based on observations at projects, the basic model consists of a type element named Meeting. Typically, the type element Meeting includes type properties to store the name and date:

• the type property Name has a data type of Single line text (to contain a brief title for identifying the meeting);
• the type property Date has a data type of Date (to indicate when the meeting is planned or was held).

In the model, a type relation, has attendee, is created between the type elements Meeting and Person. In most cases, the cardinality of this relation is set to Multi as the concept of a meeting is that multiple people discuss various topics with each other. This type relation helps to know whom to contact if more information is needed on topics discussed during a particular meeting.

Absentees

Some projects want to explicitly track which people were absent during a meeting. Typically, these people were initially planned as attendees. During the meeting, people are switched from present to absent. This type relation helps to know which people need to be informed after the meeting about the discussed topics.

In the model, a type relation, has absentee, is created between the type elements Meeting and Person. In most cases, the relation’s cardinality is set to Multi. Like the type relation, has attendee, multiple persons can be absent during a meeting.

Attendance with additional information

In some cases, projects want to provide more context to the attendance of specific persons at a meeting. For example, a reason for being absent during a meeting helps the reader to understand the situation.

In the model, for the type element, Meeting, a middle type element, Attendance, is created. Typically, the cardinality of the middle type element is set to Multi, as a meeting can be attended by multiple persons. Additionally, the setting Act as inner element is enabled for the derived type element. Since most users are not interested in seeing a complete attendance overview for all persons, Attendance is usually considered an inner type element. The Target relation is set to the type relation, concerns, between the type elements Attendance and Person. As a result, Attendance can only exist for a combination of a meeting and a person. In most cases, the setting, Enforce uniqueness on origin-target combinations, is enabled. This keeps the model simple, as only one attendance can be added for each unique combination of a meeting and a person.

Typically, the type element Attendance includes type properties to store the status and remark:

• the type property Status has a data type of List (to store if the person was part of the meeting or not). Examples of typical list values include Present and Absent;
• the type property Remark has a data type of Text (to store an optional comment on the attendance status).

Scope

It is common practice for projects to prepare an agenda for each meeting. Whereas a basic agenda supports a mostly textual agenda, a more advanced agenda keeps track of relations to various subjects that are also part of the SE model (e.g., Interface, Permit, Requirement, Risk, Stakeholder).

Meeting with agenda property

A basic SE model supports a single agenda text in which all agenda items are described (e.g., using a bulleted list). The main advantage is that it concerns an accessible solution. The disadvantage is that it does not harness the power of the SE model, as various elements from the SE model are often subject to the meeting. As a result, the subjects need to be redundantly described in the agenda text which is suboptimal.

Using this model pattern the type element Meeting typically includes a type property to store the agenda:

• the type property Agenda has a data type of Text (to describe the agenda items as part of a single text).

Agenda Items

A more advanced model used by many projects involves the creation of separate agenda items for a meeting. Each agenda item can contain a descriptive text and/or a relation to another element from the SE model. The advantage is that a user can easily navigate to an element that is subject to a meeting to learn more about the corresponding element. Another advantage is that, from the perspective of the elements that are subject of the meeting, it can be traced back in which meetings it was discussed.

In the model, a derived type element Agenda Item is created for the type element Meeting. Typically, the cardinality of Agenda Item is set to Multi as multiple agenda items can be discussed during a meeting. Typically, the type element Agenda Item includes type properties to store values for the name and description:

• the type property Name has a data type of Single line text (to provide a brief title to quickly identify an agenda item);
• the type property Description has a data type of Text (to contain a full description of what needs to be discussed regarding the meeting item).

Further, the model consists of two type relations:

• a type relation, is created by, is created between the type elements Agenda Item and Person. In practice, the cardinality of this type relation is set to Single, as individual users typically create their own agenda items;
• a type relation, has subject, is created between the type element Agenda Item and various type elemens from the model (e.g. Interface, Permit, Requirement, Risk, and Stakeholder). In practice, the cardinality of the type relation is set to Multi because the subject of a meeting item may involve multiple elements. Finally, it is useful to set the range of the type relation to Collection when the meaning of the type relation (e.g. has subject) is the same for the various type elements within the context of the agenda item. As a result, all subjects will be shown in the same column or table.

TIP: By setting the type element Person as the Type of elements to link with users (optional) and enabling the option Element linked to current user as default to element for the type relation, agenda items created by users are automatically linked to the corresponding person connected to the logged-in user.

TIP: Using the relatable elements view, a user can create new subject elements directly from the perspective of an agenda item.

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 meeting, it is advised to set the range of the type relation to Standard and use distinct role names for each type relation.

Categorization

Several types of meetings are held in projects, depending on the disciplines involved and the topics discussed. Often the SE model of projects supports different types of meetings to categorize meetings or to support unique needs for certain types of meetings.

Category property

One way that projects categorize meetings is by assigning a certain type (e.g. Interface, Permit, Risk, Stakeholder). The advantage is that meetings can be easily filtered, while all the meetings can still be found in the same table. Another advantage is that the way of working is uniform, as the same SE model applies to each meeting.

Typically, the type element Meeting includes a type property to store the category:

• the type property Category has a data type of List (to classify the meeting). Examples of typical list values include internal versus external (e.g., Internal, External) or supported processes in the project (e.g. Interface, Permit, Risk, Stakeholder).

Category element

Another way projects categorize meetings is by making them part of a meeting category (e.g. Interface, Permit, Risk, Stakeholder). The difference is that meetings are uniquely created within a category. The advantage is that meetings can be shown in a tree view when made hierarchical.

In the model, a derived type element Meeting is created for the type element Meeting Category. Typically, the cardinality of Meeting is set to Multi, as multiple meetings can be held for the same category. Optionally, the setting Hierarchical can be enabled. As a result, a tree view is presented that groups meetings per meeting category.

Disciplines

Instead of using fixed categories, some projects decide to relate their meetings to one or more disciplines from the model. The advantage is that it provides the flexibility to either assign a meeting to a single discipline or to multiple disciplines. From the perspective of a discipline, it can be easily traced which historical meetings were held and which future meetings are planned.

In the model, a type relation, is held for, is created between the type elements Meeting and Discipline. In most cases, the relation’s cardinality is set to Multi. This allows a meeting to be related to one or more disciplines.

TIP: Use the circular dependency feature to ensure the correct person is assigned as an attendee for the meeting relative to the person’s discipline related to the corresponding meeting. The circular dependency generates warnings when the related persons do not match the discipline related to the meeting.

Dedicated meetings

If the process for various types of meetings is significantly different, projects usually prefer to include separate type elements in the model for each type of meeting. The advantage is that the model for each type of meeting can be customized to support the specific needs (e.g. different type properties and type relations can be used in the SE model). As a result, each discipline can work with different meetings that are tailored to their specific needs.

In the model, different type elements are used for each type of meeting (e.g., Interface Meeting, Permit Meeting, Risk Meeting, Stakeholder Meeting). In the example, differences in type properties and type relations are used to address the specific needs of the involved disciplines.

Lifecycle

Often, projects keep track of a meeting’s status, to help plan future meetings and to quickly find historical meetings. In some cases, projects also keep track of individual agenda items during a meeting to ensure that, eventually, every agenda item is handled or replanned.

Meeting

When monitoring the handling of meetings over time, adding a type property Status to the model with the data type List is often beneficial. Examples of typical list values include New, Planned, Closed, and Cancelled. This makes it easier for users to filter out irrelevant meetings. In most cases, the list value New is set as the Default. As a result, every newly created meeting will be automatically assigned the status value New.

If some meetings 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., Cancelled), only relevant meetings will be displayed by default in the views.

Agenda items

When agenda items are part of meetings in the SE model, projects occasionally decide to keep track of their status during the meeting. The advantage is that both during and after the meeting, it is clear which agenda items have been discussed and which have not. This helps, for example, to replan non-discussed agenda items in a future meeting.

Typically, the type element Agenda Item includes a type property to store the status:

• the type property Status has a data type of List (to keep track of the life cycle of the agenda item). Examples of typical list values include Open, Partially discussed, Discussed, and Postponed).

Source

Various files and documents are typically involved while referring to the source of a meeting or a specific agenda item. Complementary to elements from the SE model that are related as a subject to agenda items, these files, and documents provide additional context information.

Single file uniquely stored for a meeting

Sometimes a document is only relevant in a single context. For example, an email has been received that addresses a specific meeting. If the file is specific to a single context, it can be decided to upload the document directly into Relatics. In these cases, the advantage of storing the file directly in Relatics outweighs the benefit of storing the file in a central Document Management System (DMS) or network drive. If only a maximum of one document per meeting is expected, projects often use properties to allow files to be uploaded for a meeting.

Typically, in the model, the type element Meeting includes a type property to store an attached file:

• the type property Attachment has a data type of Attachment (to contain a file that is the source of a meeting).

Single file uniquely stored for an agenda item

Similar to meetings, projects can decide to store a unique file at the level of the agenda item. An advantage is that files can be stored specifically for the subject they address. This makes it easier to find the corresponding file during the meeting.

Similar to the model described above, the type element Agenda Item includes a type property Attachment with a data type of Attachment.

Multiple files uniquely stored for a meeting

Projects often use dedicated elements in their SE model if numerous files can be attached to a meeting. In addition to storing multiple documents, another advantage is that other metadata (e.g., a description) can be stored to complement the uploaded file.

In the model, a derived type element Attachment is created for the type element Meeting. Typically, the cardinality of Attachment is set to Multi as multiple files can be added. 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 attachments for all meetings, an Attachment is usually considered an inner type element. Typically, the type element Attachment includes type properties to store values for the file and description:

• the type property File has a data type of Attachment (to upload a file);
• the type property Description has a data type of Text (to contain an optional comment regarding the uploaded file).

Multiple files uniquely stored for an agenda item

Similar to meetings, projects can decide to store multiple unique files on the level of the agenda item. An advantage is that files can be explicitly stored for the agenda item they address. A potential disadvantage is that the model becomes slightly more difficult when both multiple attachments and multiple subjects can be related to individual agenda items, as there is no connection between the subjects and the attachments.

Similar to the model described above, the type element, Agenda Item, includes a derived type element Attachment with type properties File (datatype is set to Attachment) and Description (datatype is set to Text).

Source documents reused by meetings

In many cases, projects reuse documents in their SE model. For example, multiple meetings can be related to the same source document. By relating all meetings to the same document, it becomes instantly traceable from the document’s perspective, which meetings are applicable. In many projects, reused documents are stored in a centralized DMS or network drive that supports advanced file and document management.

In the model, a type relation, has source, is created between the type elements Meeting and Document. In most cases, the cardinality of this relation is set to Multi. This allows documents to be reused for multiple meetings.

Typically, in the model, the type element Document includes type properties to store a title and a hyperlink:

• the type property Title has a data type of Single line text (to contain a name for identifying the document);
• the type property Hyperlink has a data type of URL (to refer to the location of an external file). The advantage is that a user can click on the hyperlink to view the file stored in a DMS, shared network drive, or online resource directly.

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 (e.g. SharePoint).

Source documents reused by agenda items

Similar to meetings, projects can decide to relate source documents to the level of the agenda item. An advantage is that source documents can be reused for agenda items and that, from the perspective of the document, it is easily traceable what all referenced agenda items are. A potential disadvantage is that the model becomes slightly more difficult when both multiple documents and multiple subjects can be related to individual agenda items.

Similar to the model described above, a type relation, has source, is created between the type elements Agenda Item and Document.

Result

Decisions during meetings can lead to new actions. Often, projects decide to explicitly make actions part of the SE model to control meetings. As a result, projects can keep track of the process of following up on the actions.

Dedicated meeting actions

If the project meeting process only supports actions relevant to the meeting itself, projects may consider keeping track of dedicated meeting actions in the SE model. An advantage is that meeting actions can be modelled with specific properties and relations that match the meeting process.

In the model, a derived type element Meeting Action is created for the type element Meeting. Typically, the cardinality of Meeting Action is set to Multi as multiple actions can be added. Usually the type element Meeting Action includes type properties to store values for the name and description:

• the type property Name has a data type of Single line text (to contain a brief title for recognizing the action);
• the type property Description has a data type of Text (to provide more details on the action).

Dedicated agenda item actions

Similar to meetings, projects can decide to keep track of actions at the level of the agenda item. An advantage is that actions can be explicitly related to the agenda item they address. A potential disadvantage is that the model becomes slightly more difficult when both multiple actions and multiple subjects can be related to individual agenda items, as there is no connection between the subjects and the actions.

Similar to the model described above, the type element, Agenda Item, includes a derived type element Agenda Item Action with type properties Name (datatype is set to Single line text) and Description (datatype is set to Text).

Reusable meeting actions

In many cases, projects reuse actions in their SE model. For example, other elements can be related as the subject to an action (e.g., interfaces, permits, requirements, and stakeholders). An advantage is that from the perspective of an action, it becomes instantly traceable which meetings or other elements from the SE model are relevant for the action. This meaningful information provides context that helps users better understand the action.

In the model, a type relation, is result of, is created between the type elements Meeting and Action. In most cases, the cardinality of this relation is set to Multi. This allows actions to be reused for multiple meetings.

TIP: Using the relatable elements view, a user can create new actions directly from the perspective of a meeting.

Reusable agenda item actions

Similar to meetings, projects can decide to relate actions to the level of the agenda item. An advantage is that actions can be reused for agenda items. From the perspective of the action, it is easily traceable what all referenced agenda items are. A potential disadvantage is that the model becomes slightly more difficult when both multiple actions and multiple subjects can be related to individual agenda items, as there is no connection between the subjects and the actions.

Similar to the model described above, a type relation, is result of, is created between the type elements Action and Agenda Item.

TIP: Using the relatable elements view, a user can create new actions directly from the perspective of an agenda item.

Notes

The model is often updated to support notes on meetings. Notes are typically used to store internal comments, thoughts, suggestions, or ideas from users regarding a meeting.

Notes property

One way that projects consider adding meeting notes is by collecting all notes as part of one text. The advantage is that it concerns an accessible solution. The disadvantage is that it becomes difficult to track which persons add which notes at what moment.

Typically, the type element Meeting includes a type property to store the notes:

• the type property Notes has a data type of Text (to describe the notes as part of a single text).

Multiple individual notes

Another way projects add meeting notes is by keeping track of multiple individual notes in the form of a log. The advantage is that additional properties and relations can be stored for each individual note, which helps to better understand when and by whom a note was created.

In the model, a derived type element Note is created for the type element Meeting. Typically, the cardinality of Note is set to Multi to allow users to create multiple notes for a meeting. Additionally, the setting Act as inner element is enabled for the derived type element. Since most users are not interested in seeing a full overview of notes for all meetings, a note is usually considered an inner type element. Typically, the type element Note includes type properties to store the description and creation date:

• the type property Description has a data type of Text (to provide the full details of the note);
• the type property Created on has a date type of Date (to provide the date when the note was created).

TIP: By setting the default value of the type property Created on to Current project date, newly created notes are automatically assigned the current date, as defined by the project’s local time zone.

Finally, a type relation, is created by, is established between the type elements Note and Person. In practice, the cardinality of this type relation is set to Single, as individual users typically create their own notes.

TIP: By setting the type element Person as the Type of elements to link with users (optional) and enabling the option Element linked to current user as default to element for the type relation, notes created by users are automatically linked to the corresponding person connected to the logged-in user.