Permits

When construction projects seek to monitor the permit-issuing process closely, permits are often integrated into their Systems Engineering (SE) model. One of the major benefits commonly experienced is the traceability of objects and activities subject to a permit and the requirements derived from it.

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

• The type property Reference number has a Single line text data type (to store the identification number of the permit provided by the competent authority).
• The type property Name has a Single line text data type (to contain a brief title for identifying the permit).

The basic model further consists of one type relation:

• A type relation, has competent authority, is created between the type elements Permit and Organization. This relation specifies which organization grants the permit. In most projects, the cardinality for this relation is set to Single. This prevents ambiguity and ensures a permit is traceable to only one competent authority.

Scope

In many cases, permits describe a subject by referring to an applicable law and to other elements from the SE model (e.g., objects and activities).

Applicable law

Different laws can apply depending on the type of project. The advantage of tagging each permit to the applicable law is that it is easy for users to filter permits with a similar subject quickly.

In the model, the type element Permit includes a type property to store the applicable law:

• The type property Applicable law has a List data type (to tag it to a law from a preset list).

Other type elements as the subject of permits

In many cases, permits describe aspects of a project that are part of the SE model. Elements commonly used as the subject of a permit include objects and activities. For example, a building permit for constructing, modifying, or demolishing a bridge can be related to the object Bridge. Another example is an activity, Excavating, related to an environmental and planning permit. The advantage is that it is traceable from the perspective of other elements, such as objects and activities, which permits are involved.

In the model, a type relation, must be granted for, is created between the type element Permit and another type element (e.g., Object, Activity). In practice, the cardinality of the type relation is set to Multi as multiple elements can be the subject of a permit. Finally, it may be helpful to set the range of the type relation to Collection when the meaning of the type relation (i.e., must be granted for) is the same for the various type elements within the permit context.

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

Categorization

Projects sometimes distinguish permits into several categories (e.g., environmental permit, water permit, building permit). This helps to filter out similar permits quickly.

In the model, the type element Permit includes a type property to store the category:

• The type property Category has a List data type (to classify the permit). Examples of typical list values include Environmental permit, Water permit, Building permit, and others.

Planning

Most projects keep track of various permit dates that resemble certain key milestones. This helps them take action each time a milestone date is nearing.

In the model, the type element Permit includes type properties to store the application date, valid from date, and valid to date:

• The type property Application date has a Date data type (to store when the permit was requested at the competent authority).
• The type property Valid from date has a Date data type (to store from which moment in time the permit is granted).
• The type property Valid to date has a Date data type (to store until which moment in time the permit is granted).

Lifecycle

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

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

Responsibility

Often, responsibility for permits is added to the SE model when multiple persons or organizations are involved in tracking permit progress and following up on related actions.

Organizations

For some projects, multiple organizations are involved in the permit process. For example, a project subdivided into subprojects that each focus on a different scope and have to collaborate on interfaces, or contractor projects that involve subcontractors. In these cases, it is worthwhile to decide on which organization is responsible for each permit.

In the model, a type relation, has holder, is created between the type elements Permit and Organization. In most cases, the cardinality of this relation is set to Single. This ensures that organizations do not feel unaccountable when multiple organizations are involved.

Persons

For other projects that do not involve multiple organizations but have an advanced permit process, multiple people can be involved. In these cases, it is worthwhile to make individual persons responsible for a permit.

In the model, a type relation, has responsible, is created between the type elements Permit and Person. In most cases, the cardinality of this relation is set to Single. This ensures that individuals do not feel unaccountable when multiple persons are involved.

NOTE: Sometimes, a project considers assigning responsibility using a project role instead of a person in anticipation of future changes in the project’s workforce. However, a significant disadvantage of using a project role is that it becomes much more challenging to track exactly which person was responsible for a permit at a specific time in the past. Therefore, it is recommended that responsibility for a permit be assigned directly to a person instead of a project role.

Source

Various files and documents are typically used as correspondence regarding permits. Examples include documentation from which the permits have been derived or emails that contain correspondence regarding the permits. Referencing the actual file or documents helps users quickly access more detailed information about the permit.

Single file uniquely stored for a permit

Sometimes a document is only relevant in a single context. For example, an email that addresses a specific permit has been received. If the file is specific to a single context, it can be directly uploaded 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 permit is expected, projects often use properties to allow files to be uploaded for a permit.

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

• The type property Attachment has an Attachment data type (to contain a file).

Multiple files uniquely stored for a permit

Projects often use dedicated elements in their SE model if numerous files can be attached to a permit. 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 Permit. 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 permits, an Attachment is usually considered an inner type element. Typically, the type element Attachment includes type properties to store the file and description:

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

Source documents reused by permits

In many cases, projects reuse documents in their SE model. For example, multiple permits can be related to the same source document. By relating all permits to the same document, it becomes instantly traceable from the document’s perspective which permits 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 Permit and Document. In most cases, the cardinality of this relation is set to Multi. This allows documents to be reused for multiple permits.

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

• The type property Title has a Single line text data type (to contain a name for identifying the document).
• The type property Hyperlink has a URL data type (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.

Specification

Permits are often the source of requirements (e.g., system requirements and process requirements). Tracking the sources of the requirements supports traceability, helping to justify their existence and obtain additional information from the permits.

The model consists of two type relations:

• A type relation, is derived from, is created between the type elements System Requirement and Permit. In most cases, the cardinality of each relation is set to Multi. This allows permits that cover multiple system requirements to be reused for multiple requirements.
• A type relation, is derived from, is created between the type elements Process Requirement and Permit. In most cases, the cardinality of each relation is set to Multi. Similar to the type relation between System Requirement and Permit, this allows permits that cover multiple process requirements to be reused for multiple requirements.

Control

When multiple persons or organizations specify and control permits, projects often create actions for the permits. These actions help track what is needed and by whom to complete a permit.

Permit-specific actions

It is common practice for projects to keep track of an action list dedicated to permits. The advantage is that the SE model can be tailored to the process of permit actions.

In the model, a derived type element Permit Action is created for the type element Permit. Typically, the cardinality of the Permit Action is set to Multi. This allows multiple actions to be created for a permit.

Typically, the type element Permit Action includes type properties to store the description, comment, and status:

• The type property Description has a Text data type (to contain a complete description of the permit action).
• The type property Comment has a Text data type (to provide additional thoughts, such as those from other disciplines or organizations involved).
• The type property Status has a List data type (to monitor the lifecycle of a permit action). Examples of list values include Open, In Progress, Completed, and Rejected.

In the model, a type relation, has responsible, is created between the type elements Permit Action and Person. In most cases, the cardinality of this relation is set to Single. Allowing only one person to be designated as responsible for the permit action makes it clear who the point of contact for follow-up is.

Generic actions

Alternatively, projects can support generic actions in their SE model. The advantage is that actions can be reused for multiple elements, keeping the overall SE model relatively simple.

In the model, a type relation, has subject, is created between the type element Action and Permit. In practice, the cardinality of the type relation is set to Multi because the subject of an action may involve multiple permits. Finally, it may be helpful 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 (e.g., Interfaces, Systems Requirements).

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

Decision-making

When multiple persons or organizations are involved in tracking the progress of permits and following up on permit actions, meetings are often used to discuss permits and make related decisions.

Permit-specific meetings

Some projects use meetings dedicated to permits. The advantage is that the model for permit meetings can be tailored to the needs to support the permit process (i.e., implement custom type properties and type relations in the SE model).

In the model, a type element, Permit Meeting, is created. Typically, this element includes type properties to store the name and date:

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

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

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

Further, the model consists of three type relations:

• A type relation, has attendee, is created between the type elements Permit 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 permits.
• A type relation, is created by, is created between the type elements Permit Agenda Item and Person. In most cases, 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 elements Permit Agenda Item and Permit. In most cases, the cardinality of the type relation is set to Multi because the subject of a meeting item may involve multiple permits.

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 permits directly from the perspective of an agenda item.

Generic meetings

Other projects use generic meetings in which various subjects are discussed, including permits. The advantage is that users can easily navigate from a meeting to a permit to learn more about the corresponding permit. Another benefit is that, from the perspective of the permits, they can be traced back to see in which meetings they were discussed.

In the model, a type relation, has subject, is created between the type element Agenda Item and Permit. In practice, the cardinality of the type relation is set to Multi because the subject of a meeting may involve multiple permits. Finally, it may be helpful 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 (e.g., Interfaces, Requirements, Risks, Stakeholders, and Systems Requirements).

TIP: Using the relatable elements view, a user can create permits 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.

Notes

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

Notes property

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

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

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

Multiple individual notes

Another way projects add permit 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 Permit. Typically, the cardinality of Note is set to Multi to allow users to create multiple notes for a permit. 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 permits, 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 Text data type (to provide the full details of the note).
• The type property Created on has a Date date type (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.