Activity Dependencies | Adroit Consultants, LLC

Evaluating Activity Logic Relationships: A New Perspective

Posted on March 25, 2019March 27, 2019 by Adroit

Project schedules are among the key project artifacts that are used as a basis for project control. They are one of the most effective ways that a project team can use to coordinate their activities. Project schedules play a key role in making such coordination and to facilitate achieving a project’s time objectives. However, project schedules can play this role only if they are prepared in a reasonable manner. The reasonableness of project schedules can be evaluated from various perspectives including consistency, clarity, completeness, and feasibility of construction plans.

The following are some of the main considerations that need to be given to developing project schedules to ensure they are reasonable:

The schedule is complete and entails all the activities that are needed to successfully implement the scope of work
Proper logical relationships (including finish-to-start, start-to-start-, start-to-finish, or finish-to-finish relationships along with proper lag and lead values) are used in creating the project network
An appropriate combination and choosing of activity relationships (including mandatory, preferential, and scenario-based relationships) are created to define activity dependencies
The schedule accounts for the technical, physical, and technological constraints of performing the work
The schedule meets proper contractual milestones, identifies all interim and ultimate contractual deliverables, and satisfies time and resource constraints outlined in the contract
The schedule is clear, reasonable, and complete
Different sections of the schedule are consistent in terms of the timeline, work priorities, and work sequence

As noted above, activity dependencies are among the key main considerations in developing well-prepared schedules. A project network not only contains project activities but also defines activity dependencies (also known as activity ties or activity relationships). A variety of activity dependencies exists, and activity relationships are categorized in different ways.

Activity dependencies can be categorized based on the nature of dependencies that exist between project activities. From this perspective, activity dependencies are often categorized into the following two types of dependencies:

Mandatory dependency (also known as hard logic): This relationship represents a dependency that is necessary or inherent in the nature of the work.
Discretionary dependency (also known as soft, preferred, or preferential logic): This type of dependency represents preferential logic that is used to establish a desired sequence of work despite alternative sequences that are acceptable.

It is important to note, however, that mandatory and discretionary relationships are not the only activity relationships that are used in project schedules. To better identify activity dependencies, it is suggested that activity dependencies are further categorized as shown in Figure 1.

Figure 1. Activity relationship types

As this figure shows, mandatary relationships can further be broken down into the following three types:

Imposed relationships: Imposed relationships are those relationships that need to be built into a project schedule to satisfy legal, regulatory or contractual requirements. An example includes a contractually-imposed requirement that mandates using a phased approach (where a portion of work has to be implemented after another portion) in completing certain elements of work.
Physical relationships: This relationship represents a dependency that has to be established between two or more activities due to the nature of the work. An example of dependencies that are inherent in the nature of the work is the need to place a foundation first before erecting a column atop the foundation.
Safety relationships: This relationship represents a dependency that has to be established between two or more activities to ensure safety considerations are accounted for in sequencing project activities. An example of a safety relationship is the need to avoid concurrent logic in scheduling two activities that cannot be undertaken simultaneously because of safety concerns (e.g., a crew that cannot work on the second floor of a building because of the ongoing work on the first floor).

Sometimes, project scheduling professionals use scenario-based relationships to define dependencies between project activities. The current article uses the term scenario-based to characterize these relationships because depending on the implementation strategy chosen to execute a project, scenario-based relationships may or may not be used in defining work sequences. Resource relationships are examples of scenario-based relationships. Resource relationships are often added to the project schedule due to resource management concerns (e.g., resource constraints).

For example, if a contractor needs to implement two non-causally-related activities, each of which requiring a crane, the contractor may decide to add a finish-to-start relationship between the two activities if the contractor has only one crane in its possession. In this example, the two activities are not causally related; however, based on the scenario described, the contractor has established a relationship between these two activities to satisfy its resource constraint. If the contractor had two cranes in its possession, defining a dependency between the two activities was unnecessary because as noted above, the activities are presumably not causally linked. Therefore, it is reasonable to recognize the above-referenced activity relationship as a scenario-based relationship because these relationships may or may not be used depending on the implementation scenario or strategy used.

Not all scenario-based relationships are resource relationships; therefore, in Figure 1, scenario-based relationships are broken down into the two main types of resource relationships and others. An example of other scenario based dependencies includes a dependency that is established between two activities based on an assumed what-if scenario to manage a likely change in the project scope of work. This relationship may or may not be required to be established depending on whether the change occurs or not.

The last category of activity relationships is improper relationships that consist of redundant, incorrect logic, and logic loops. Incorrect logic relationships can further be categorized into errors, missing logic, out-of-sequence, and improper use of lags and leads. These relationships will be described in greater depth in a future article.

Planning and scheduling professionals need to make informed decisions in selecting and using the right relationship type. In general, it is suggested that only mandatory relationships are used in developing project schedules unless the use of discretionary or scenario-based relationships is justified. Similarly, the use of preferential relationships may not be appropriate in demonstrating that a schedule follows a reasonable logic. It is recommended that, instead of resource constraints, planning and scheduling professionals use resource leveling techniques to ensure the schedule is not bounded by too many dependencies that could have otherwise been accounted for.

Assessing activity relationships is critical in preparing or investigating time extension requests or delay assessments because a proper delay analysis has to be based on a reasonable schedule. A delay analysis based on a project schedule that contains questionable activity relationships is defective. Project planning and scheduling, forensic scheduling experts, and claim management professionals need to ensure project schedules are free of improper relationships. Otherwise, the schedule will not be reliable or reasonable and it may not serve its purpose.

Author: Dr. Amin Terouhid, PE, PMP, PSP | Principal Consultant

If you are interested to find out more about the main considerations in developing or evaluating project schedules, please contact us. Adroit’s consultants have demonstrated their expertise in developing, updating, constructability review, and forensic evaluation of project schedules and will be able to assist. You may also be interested to read the following articles:

Schedule constructability review, what does it entail?

Schedule constructability review, what does it entail?

Mandatory, Discretionary, Scenario-based, and Improper Activity Relationships: Theoretical and Practical Considerations

Posted on January 16, 2019January 16, 2019 by Adroit

Project networks play important roles in carrying out construction activities in a timely manner, and they are among the key means of communication that project teams use to coordinate their efforts throughout the process of construction. Project networks are also among the key project artifacts that are used for preparing or investigating time-related claims and for determining entitlements to time extensions and/or delay damages. Therefore, it is important to have a more in-depth knowledge of activity dependencies and their types.

Activity dependencies are among the key characteristics and building blocks of project schedules. A project network not only contains project activities but also defines activity dependencies (also known as activity ties or activity relationships). A variety of activity dependencies exists, and activity relationships are categorized in different ways.

The four main types of activity dependencies include Finish-to-Start (FS), Start-to-Start (SS), Start-to-Finish (SF), and Finish-to-Finish (FF). The following briefly describes these relationship types:

Finish-to-Start (FS): The successor activity cannot start unless the predecessor activity finishes.
Start-to-Start (SS): The successor activity cannot start unless the predecessor activity starts.
Start-to-Finish (SF): The successor activity cannot finish unless the predecessor activity starts.
Finish-to-Finish (FF): The successor activity cannot finish unless the predecessor activity finishes.

Activity dependencies can also be categorized based on the nature of dependencies that exist between project activities. From this perspective, activity dependencies are often categorized into the following two types of dependencies:

Mandatory dependency (also known as hard logic): This relationship represents a dependency that is necessary or inherent in the nature of the work.
Discretionary dependency (also known as soft, preferred, or preferential logic): This type of dependency represents preferential logic that is used to establish a desired sequence of work despite alternative sequences that are acceptable.

To better identify activity dependencies, it is suggested that activity dependencies are categorized as shown in Figure 1.

Figure 1. Activity relationship types

As this figure shows, mandatary relationships can further be broken down into the following three types:

Imposed relationships: Imposed relationships are those relationships that need to be built into a project schedule to satisfy legal, regulatory or contractual requirements. An example includes a contractually-imposed requirement that mandates using a phased approach (where a portion of work has to be implemented after another portion) in completing certain elements of work.
Physical relationships: This relationship represents a dependency that has to be established between two or more activities due to the nature of the work. An example of dependencies that are inherent in the nature of the work is the need to place a foundation first before erecting a column atop the foundation.
Safety relationships: This relationship represents a dependency that has to be established between two or more activities to ensure safety considerations are accounted for in sequencing project activities. An example of a safety relationship is the need to avoid concurrent logic in scheduling two activities that cannot be undertaken simultaneously because of safety concerns (e.g., a crew that cannot work on the second floor of a building because of the ongoing work on the first floor).

Sometimes, project scheduling professionals use scenario-based relationships to define dependencies between project activities. The current article uses the term scenario-based to characterize these relationships because depending on the implementation strategy chosen to execute a project, scenario-based relationships may or may not be used in defining work sequences. Resource relationships are examples of scenario-based relationships. Resource relationships are often added to the project schedule due to resource management concerns (e.g., resource constraints).

For example, if a contractor needs to implement two non-causally-related activities, each of which requiring a crane, the contractor may decide to add a finish-to-start relationship between the two activities if the contractor has only one crane in its possession. In this example, the two activities are not causally related; however, based on the scenario described, the contractor has established a relationship between these two activities to satisfy its resource constraint. If the contractor had two cranes in its possession, defining a dependency between the two activities was unnecessary because as noted above, the activities are presumably not causally linked. Therefore, it is reasonable to recognize the above-referenced activity relationship as a scenario-based relationship because these relationships may or may not be used depending on the implementation scenario or strategy used.

Not all scenario-based relationships are resource relationships; therefore, in Figure 1, scenario-based relationships are broken down into the two main types of resource relationships and others. An example of other scenario based dependencies includes a dependency that is established between two activities based on an assumed what-if scenario to manage a likely change in the project scope of work. This relationship may or may not be required to be established depending on whether the change occurs or not.

The last category of activity relationships is improper relationships that consist of redundant, incorrect logic, and logic loops. Incorrect logic relationships can further be categorized into errors, missing logic, out-of-sequence, and improper use of lags and leads. These relationships will be described in greater depth in a future article.

Planning and scheduling professionals need to make informed decisions in selecting and using the right relationship type. In general, it is suggested that only mandatory relationships are used in developing project schedules unless the use of discretionary or scenario-based relationships is justified. Similarly, the use of preferential relationships may not be appropriate in demonstrating that a schedule follows a reasonable logic. It is recommended that, instead of resource constraints, planning and scheduling professionals use resource leveling techniques to ensure the schedule is not bounded by too many dependencies that could have otherwise been accounted for.

Assessing activity relationships is critical in preparing or investigating time extension requests or delay assessments because a proper delay analysis has to be based on a reasonable schedule. A delay analysis based on a project schedule that contains questionable activity relationships is defective. Project planning and scheduling, forensic scheduling experts, and claim management professionals need to ensure project schedules are free of improper relationships (i.e., redundant, incorrect logic, and logic loops). Otherwise, the schedule will not be reliable or reasonable and it may not serve its purpose.

Author: Dr. Amin Terouhid, PE, PMP, PSP | Principal Consultant

Note:

If you are interested to find out more about the main considerations in developing or evaluating project schedules, please contact us. Adroit’s consultants have demonstrated their expertise in developing, updating, constructability review, and forensic evaluation of project schedules and will be able to assist. You may also be interested to read the following articles:

Adverse effects of schedule deficiencies on claim administration

Schedule constructability review, what does it entail?

The Key Issues with Dangling Activities

The Key Issues with Dangling Activities

Posted on October 29, 2018October 31, 2018 by Adroit

Dr. Amin Terouhid, PE, PMP

Dangling activities (also known as dangles) are loosely-tied activities in project schedules. They are activities with either open start dates or open end dates. All activities, except the first activity of a network, need to have a predecessor; otherwise, they will have open start dates. Similarly, all activities, except the last activity of a network, need to have a successor; otherwise, they will have open end dates (also known as open-ended or open-end activities).

As noted above, every project activity and milestone except the first and last ones must have at least one predecessor and one successor. An example of the first activity of a network is the notice to proceed milestone and an example of the last activity of a network is the milestone that represents the project completion date. It is recommended that any project schedule starts with a start milestone and finishes with a finish milestone to ensure proper logical ties can be built into the network.

A project schedule that contains dangling activities has deficiencies because its logic is incomplete. This flaw makes the schedule unreliable and inaccurate because the schedule has not fully developed and some activity dependencies (i.e., logical ties) have not been properly identified. The four main types of activity ties include finish-to-finish (FF), finish-to-start (FS), start-to-start (SS) and start-to-finish (SF).

Here are the main issues with dangling activities:

In the event that a schedule contains a dangling activity, one cannot ensure that the projected start or finish dates accurately represent the planned dates because one or more logical ties are missing. For example, an activity with no predecessor (assuming that the activity is not the first activity of the network) has either been forced to be started or completed on particular dates using activity constraints or has been left fully unrestrained. The downside of the former is that instead of a logical tie, one or more constraints have been added to the schedule preventing the schedule from being flexible due to the use of activity constraints in place of activity ties. Schedules need to remain dynamic to ensure the time impact of a delay or a change to an activity’s duration can properly be transmitted to the rest of the project schedule. The disadvantage of the latter is that leaving the activity fully unrestrained allows the activity to move freely every time that the schedule’s as of date (i.e., data date) is changed.

Similarly, an activity with no successor (assuming that the activity is not the last activity of the network) makes the schedule unreliable because one cannot have confidence in the accuracy of the projected start and finish dates (e.g., the finish date of the network). This shortcoming is present because, in the event of a delay that adversely affects the dangling activity, the impact of this delay does not properly transmit to the rest of the schedule and as such, no activity in the network will be delayed as a result because the dangling activity has presumably no successor. In other words, the schedule will not properly be indicative of the impact of a delayed dangling activity because the network’s logic is incomplete. The same issue may become the case when an activity duration is changed because the time impact of a change to an activity’s duration is not properly transmitted to the rest of the project schedule due to the missing ties. A well-prepared project schedule must provide a full network that projects how the project schedule changes in case of a change to activity durations or in the event of delays.

Another issue with dangling activities may surface when delay claims arise. If a dangling activity is negatively affected by one or more delays, the adverse effect of these delays cannot properly be shown by the schedule. In other words, a schedule with an incomplete logic may not be a reliable tool to show the time impact of delays because the schedule logic is flawed. This deficiency results in underestimating the impact of delays. It is generally accepted that networks are reliable when they are fully developed because in this case, the activity ties define the dependencies between activities and accurately determine the projected start and finish dates.

In sum, every project activity and milestone except the first and last ones must have at least one predecessor and one successor. It is recommended that any project schedule starts with a start milestone and finishes with a finish milestone to ensure proper logical ties can be built into the network. The schedule model must identify all logical relationships to generate a full network. Schedules need to remain dynamic to ensure the time impact of a delay or a change to an activity’s duration can properly be transmitted to the rest of the project schedule. Loosely-tied activities are examples of schedule deficiencies that prevent schedules from properly showing the impact of delays or changes to the schedule on the rest of the network.

If you are in need of schedule development services or would like to monitor and control your schedules in an effective manner, Adroit will be able to assist. For more information, please contact us.