Step 6 Define logic between activities
Clearly defined logic is one of the key criteria in establishing a credible and manageable schedule.
The schedule logic & sequence of work should be realistic and credible for the type of project being planned.
For a schedule to be accurate and robust all activities and milestones must have predecessors and successors except for the first and last activity or milestone in the schedule.
CPM Scheduling software relies on the activities being linked to calculate activity start and finish dates. If an activity’s predecessor is missing, then the start of the activity will default to the current data date unless it is held to a date by a constraint.
a successor is missing, then the late finish date of the activity will default to the latest date of the project and the activity will exhibit a large amount of float which could be inaccurate and misleading.
The only activity without predecessors should be the first activity or milestone, and the only activity without successors should be the last activity or milestone (no open ends).
Types of logic
Most relationship types should be Finish to Start.
Finish to Finish and Start to Start relationships between task dependent activities should be used sparingly.
Start to Finish relationships should not be used.
For planning purposes logic is grouped into two categories:
Physical logic
Physical Logic defines the relationship between activities that must happen in a particular order because of actual real-life physical constraints. A greater proportion of physical logic produces a more manageable schedule.
Sequence logic or Resource logic
Sequence Logic (or Resource logic) defines a preferred sequence of activities. The work described by such activities and logic does not have to occur in the defined sequence and, therefore, is subject to change.
Lags
Lags should be used sparingly as they introduce complexity and ‘hidden’ logic to the schedule that can be easily overlooked. They can also lead to scheduling errors when multiple calendars are used.
Lags should be replaced by breaking activities into smaller tasks with realistic predecessors and successors.
Any lags used should be documented in the Basis of Schedule with justifications explained. This encourages the Planner to think about the use of lags and it makes them visible to other members of the project team who do not have access to a soft copy of the schedule.
Constraints
Constraints should be used sparingly and kept to a minimum. Excessive constraints can introduce complexity and may result in unexpected scheduling results (such as negative float), an incorrect critical path or a critical path that is difficult to understand and interrogate.
Hard constraints (such as Mandatory Constraints) should not be used in most cases. These will hold constrained activities in place, regardless of any logic, and this can result in incorrect float and date calculations.
Situations where use of constraints may be required include:
-
Contract completion dates and separable portions
-
To represent important milestones, such as works area possession / handover dates, or deliverables provided by the Client
-
Establishing a start to a sequence of work in an area defined by logic localized to that area
-
As an alternative to using relationships with long lags where they do not truly represent competent logic
Any constraints should be documented in the Basis of Schedule with justifications explained. This encourages the Planner to think about the use of constraints and it makes them visible to other members of the project team who do not have access to a soft copy of the schedule.
Horizontal and vertical traceability
Logic in a schedule should have both vertical and horizontal traceability.
Vertical traceability ensures that dates, scope, and progress are consistent between the different sections or levels in a schedule. For example, the summary schedule is consistent with the detailed schedule.
Horizontal traceability ensures that interdependencies between activities have been planned in a logical sequence. For example, design activities link to procurement activities which link to construction activities and so on.
Path convergence and merge points
When an activity has many parallel activities as predecessors this is known as path convergence, and it creates a ‘merge point’ or ‘logic hotspot’ which can cause problems in managing a schedule.
Path convergence can affect the achievability of the schedule because the risk of achieving each of the predecessors becomes multiplicative, significantly reducing the probability of achieving the successor activity on time.
As a rule of thumb, the ratio of the number of relationships should be approximately 1.5 to 2 times the number of activities. When this ratio is greater than 2 it may indicate the presence of unnecessary logic and the schedule should be reviewed for ‘merge points’ with any unnecessary logic removed.