Construction projects commonly include actions in their Systems Engineering (SE) model to follow up on issues, findings, comments, or ideas identified by different project disciplines. To keep track of the actions, actions are often related to other type elements in the SE model, such as system requirements, stakeholder requirements, interfaces, permits, stakeholders, etc. In contrast, actions can also be created autonomously as generic actions unrelated to any other type element. In practice, actions are managed by means such as assigning a responsible person, a status, a deadline, and a priority.
Based on observations at projects, the basic model consists of a type element named Action. Typically, the type element Action 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 recognizing the action);
- the type property Description has a data type of Text (to provide more details on the action).
Scope
In many cases, actions describe a subject that is part of the SE model. For example, system requirements, stakeholder requirements, interfaces, permits, stakeholders, and other type elements can be the subject of an action. In other cases, actions can be the subject of other type elements in the SE model. For example, an action can be the subject of a meeting.
Other type elements as the subject of actions
When analyzing elements in the SE model, a user can be triggered to create an action for them. For example, when studying an incomplete system requirement, a user may decide to create an action describing an improvement and relating the action to the corresponding system requirement. As a result, the related actions provide traceability from the perspective of the elements.
In the model, a type relation, has subject, is created between the type element Action and another set of type elements. In practice, the cardinality of the type relation is set to Multi because the subject of an action may involve multiple elements. Finally, it may be 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 action.
TIP: Using the relatable elements view, a user can create actions directly from the perspective of an element whose type element is related to the type element Action.
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 an action, it is advised to set the range of the type relation to Standard and use distinct role names for each type relation.
Actions as the subject of agenda items
In contrast, actions can also be the subject of other elements in the SE model. For example, actions can be the subject of agenda items in project meetings. Either actions are related to agenda items in advance when the meeting is planned, or actions are created during the meeting for agenda items as a result of a discussion.
In the model, a type relation, has subject, is created between the type elements Agenda Item and Action. In most cases, the cardinality of this relation is set to Multi. This gives project members the flexibility to relate no actions, a single action, or multiple actions that are the subject of a meeting’s agenda item.
Categorization
Depending on the project’s processes, some projects use a generic list of actions that address various subjects from different disciplines. In contrast, other projects use a dedicated list of actions for specific disciplines.
Dedicated actions
One way projects categorize actions is by creating a dedicated type element in the SE model for a certain discipline (i.e. to support another type element in the model). The main advantage of this approach is that custom needs can be supported by using different properties and relations. Another advantage is that with roles, there is more fine-grained control of who can create or update the actions.
For example, in the model for the type element Interface, a project may decide to add a derived type element, Interface Action, to support actions that are dedicated to interfaces. Typically, the cardinality of Interface Action is set to Multi to allow users to create multiple actions for an interface.
The derived type element Interface Action can have its own set of type properties, for example, to store the description and a comment:
- the type property Description has a data type of Text (to provide a full explanation of the action);
- the type property Comment has a data type of Text (to provide additional thoughts on the action).
Actions with categories
Another pattern involves using a type property to allow project users to categorize actions that are part of a generic list. The main advantage of this approach is flexibility, as you can easily toggle the category of an existing action at a later time. This model pattern is ideal when all actions, regardless of the discipline, follow a similar process and have a similar set of properties and relations.
In the model, a type property, Category, is created for the type element Action:
- the type property Category has a data type of List (to classify the action). The list values can, for example, correspond to the various disciplines of the project or the names of relevant type elements of the SE model.
Lifecycle
When monitoring the handling of actions over time, adding a type property Status to the model with the data type List is often beneficial. Examples of typical list values include Open, In progress, Closed, and Cancelled. This makes it easier for users to filter out irrelevant actions. In most cases, the list value Open is set as the Default. As a result, every newly created action will be automatically assigned the status value Open.
If some actions 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., Closed, Cancelled), only relevant actions will be displayed by default in the views.
Responsibility
When multiple disciplines or persons are involved in handling actions, it is common to include responsibility in the SE model. This helps clarify who is responsible for taking the lead in handling or delegating actions.
Responsible persons
In most cases, projects make project members responsible for actions. This allows users to filter the actions for which they are responsible easily. Sometimes, a project considers using a project role instead of a person to assign responsibility, anticipating future changes in the project’s workforce. However, a major disadvantage of using a project role is that it becomes much harder to track exactly which person was responsible for an action at a specific time in the past. Therefore, it is recommended that responsibility for an action be assigned directly to a person.
In the model, a type relation, has responsible, is created between the type elements Action 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 action ensures clarity about who the point of contact is to follow up on the action.
TIP: When the Life cycle property (e.g. the type property Status) for the type element Action is enabled, actions can be highlighted as personal tasks with My to-dos. For the type element Action, certain list values for the type property Status can be set as To-do definitions (e.g., Open, In progress). As a result, users can quickly filter actions in the actions overview and highlight personal actions on the workspace start page.
Actionees
Sometimes, projects distinguish which person is primarily responsible for an action and which person or persons are assigned to handle it. This is especially true when actions can be delegated to others, and when actions can be handled multiple times by different persons.
In the model, a type relation, has actionee, is created between the type elements Action and Person. In most cases, the cardinality of this relation is set to Multi. While the has responsible relation ensures clarity of which person is accountable for achieving the result, the actual handling of the action is delegated to other persons.
Source
An action’s origin can be an element that is or becomes part of the SE model. For example, an existing issue can lead to the creation of a new action, or a newly received email triggers the creation of an attachment or document along with the creation of a new action. Referencing an action to its source attributes to its traceability.
Documents
A common way to track the origin of an action is to link it to documents stored in a Document Management System (DMS). This enhances the action’s traceability, allowing users to verify its existence and access more detailed information.
Typically, in the model, a type relation, has source, is established between the type elements Action and Document. In most cases, the cardinality of the relation is set to Multi since multiple files can be the source of an action 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.
Attachments
Alternatively, when a DMS is not (yet) available for the project, related files can be stored in Relatics.
In the model, for the type element Action, a derived type element, Attachment, is created. Typically, the cardinality of the derived type element is set to Multi, as multiple files can be attached over time. 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 attachments regardless of the actions, an attachment is generally considered an inner type element.
Typically, the type element Attachment includes type properties to store the file and description:
- the type property File has the data type of Attachment (to upload the actual file);
- the type property Description has the data type of Text (to store an optional comment or note about the attached file).
Issues
When a project keeps track of issues, it sometimes considers storing actions separately. In the process, actions are created whenever an issue needs to be handled. From the perspective of the action, it is traceable what the reason is for creating the action. From the perspective of the issue, it is clear how the issue has been handled. Although the separation of actions and issues seems right from the process perspective, in practice, it does not always work. Often it is simpler to primarily keep track of issues in the SE model and use type properties or a derived type element for the type element Issue to keep track of how the issue is handled.
In the model, a type relation, handles, is created between the type elements Action and Issue. In most cases, the cardinality of this relation is set to Multi. Reusing an action for multiple issues is not necessarily wrong. However, in practice, it does not happen that often that actions are created that solve multiple issues.
Control
When the number of actions starts to grow, projects commonly want to focus on the most important actions and control their timely handling.
Priority
Projects often consider prioritizing actions based on their importance relative to other actions, such as using a prioritization technique to tag actions based on a predefined set of values.
In the model, a type property, Priority, is created for the type element Action:
- the type property Priority has a data type of List (to decide on the importance of the action). Popular list values include Standard and High. In most cases, the list value Standard is set as the Default. As a result, every newly created action will be automatically assigned the priority value Standard. Only in cases of high importance will a user set the value manually to High.
Other, more fine-grained sets of list values, such as Low, Medium, and High, can be considered for the priority. However, the downside is that a more advanced set of list values can defeat its purpose. In practice, projects experience the most simple prioritization techniques to be most effective.
Deadline
Another way to control the timeliness of actions being handled is to assign deadlines to actions. Sorting actions in a table based on the deadline provides an alternative way to prioritize actions.
In the model, a type property, Deadline, is created for the type element Action:
- the type property Deadline has a data type of Date (to indicate the due date of the action).
Notes
The model is often updated to support notes on actions. Notes are typically used to store internal comments, thoughts, suggestions, or ideas from users regarding an action.
Notes property
One way that projects consider adding notes to actions 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 Action 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 notes to actions 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 Action. Typically, the cardinality of Note is set to Multi to allow users to create multiple notes for an action. 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 actions, 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.
