Meetings are very common in construction projects. Without them, it is challenging to coordinate multiple people, disciplines, and/or organizations. The primary purpose of registering meetings appears to be ensuring traceability and providing a reference. There is no strict requirement for how meetings should be modeled in Relatics.
This article outlines some common practices for modeling meetings in Relatics. Additionally, it provides guidance on maintaining the traceability of meetings.
Basic meetings on projects
The basics
This model pattern visualizes the minimum structure required for managing meetings. It allows users to manage meetings at the most basic level.
With this model, users can create meetings, define their metadata, and add attendees.
Meeting organizer
In addition to adding attendees, it can be useful to specify the organizer of the meeting.
This enhances traceability and provides greater insight.
Typification
Meeting typification is something we encounter frequently. By assigning a type to a meeting, information can be presented to users in a more structured way. For example, this allows users to filter the meeting list by type. Common examples of meeting types include stakeholder meetings, management meetings, and technical meetings.
When modeling meeting typifications, it is important to consider both the reusability of meetings and the end-user experience. For instance, recurring meetings—such as stakeholder meetings—often follow a consistent setup. These meetings may also involve the same project team members from a specific discipline. In such cases, reusing meetings via the copy-paste functionality can be an effective approach.
Basic typification
If a simple tagging mechanism is sufficient for typifying a meeting, this model works well. A list property called Type is added to the meeting and can include any type you define.
However, with this approach, it is not possible to create relationships to or from the meeting type. Additionally, the user can select only one type, and the types will not appear in the menu.
Type based meetings
From an end-user perspective, a different approach is often preferred. In this case, the primary way to access a meeting is through its meeting type.
In this model, meetings are derived from their meeting type. This approach provides users with a menu item Meeting Type. Within a selected type, users can create one or more meetings.
If the Meeting element is made hierarchical, the meeting types will be displayed as a tree structure, enhancing user-friendliness. This approach also improves reusability. For example, you can create a template meeting within a meeting type, pre-filled with data that frequently applies to recurring meetings, such as weekly meetings of that type. From there, users can simply copy and paste the template to quickly set up a new meeting, saving time on configuration.
Agenda
To prepare a meeting effectively, agenda items are often used to provide structure and make the meeting more goal-oriented.
Basic agenda
This commonly used model incorporates an agenda through the use of agenda items. Each agenda item includes the necessary information to initiate discussions on its specific subject.
In most cases, the derived element Agenda Item is set as an inner element, ensuring it does not appear in the type menu.
Properties to consider
It is not uncommon for agenda items to remain undiscussed in a meeting due to time constraints or other reasons. To address this, a property like Discussed Y-N is often used. This serves primarily for traceability, allowing users to track which agenda items were discussed and which were not.
Additionally, meeting minutes can be associated with each agenda item. When combined, the minutes from all agenda items in the same meeting will form the complete meeting minutes.
Relations to consider
It is quite possible that the user who prepares and populates the meeting in Relatics is not the same person who introduces the agenda item(s). Therefore, it can be helpful to select a person to indicate who introduced each agenda item. This makes it explicit, ensuring that users can easily identify and contact the right person when reviewing past meetings.
For convenience, it can be helpful to select an element that represents the main subject of the agenda item. In this example, it’s an object, but it could be any element that is relevant to the agenda.
Tip: When a meeting is copied for reuse, all its agenda items are copied as well. This allows you to include one or more agenda items that will appear in every meeting, making them part of a “template” meeting.
Allocation
Allocating meetings can be a useful practice for distributing responsibilities and/or ownership.
Meeting allocation can be approached in various ways. Below are some common practices for allocation:
Internal or external
When it’s important to allocate a meeting as either internal or external, simply adding a (list) property will suffice.
Discipline
To provide more clarity about the allocation, this model can be helpful.
With this model, the user can select one or more disciplines to which the meeting can be assigned.
Depending on the discipline model, it is possible to see which company and/or person is indirectly assigned to the meeting.
Tip: With this setup, it is also possible to hide or show meetings based on the rights of the logged-in user.
For example, a contractor’s user may not need to see all the meetings of the client.
See also: Role-based access within a workspace
Taking notes
It is common for a meeting to have its own notes, separate from the agenda items. Users can store various types of information in these notes that may not be suitable for an agenda item. A note can also include information from other referenced files.
Actions
Meetings often result in outstanding actions. Depending on how actions need to be managed, here are two possible approaches:
Stand-alone actions
In this case, the action is modeled as a stand-alone element.
This approach is useful for generic action management. When actions are managed centrally, it allows users to manage the entire list of actions and easily link them to various elements.
Note: This action supports both multiple incoming and outgoing relations.
Derived actions
An action can also be modeled as a derived element originating from the meeting. In this approach, all actions created in the meeting are tied to that specific meeting.
Note: If the action is set as an inner derived element, it will only support a singular outgoing relation and no incoming relations.
Actions typically have an executor and several metadata fields to ensure thoroughness. This ensures that there is always someone responsible for each action.
See also:
Report
It is common for meetings to need documentation and reporting to higher management or third parties. The report functionality helps in this regard by generating a comprehensive report of the meeting, including all its relations and data.
For more information on Relatics Reports, see also:
