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.