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