Step 6: Define Logic Between Activities

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 and sequence of work should be realistic and credible for the type of project being planned.

The Rule: No Open Ends

For a schedule to be accurate and robust, all activities and milestones must have predecessors and successors — except for the very first and last activity or milestone.

• If an activity's predecessor is missing, its start will default to the current data date unless held by a constraint.
• If a successor is missing, the late finish date of the activity defaults to the latest date of the project — giving the activity a large, inaccurate, and misleading amount of float.
• 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.

Types of Logic Relationships

Physical Logic vs. Sequence Logic

Physical Logic — defines relationships between activities that must happen in a particular order due to real physical constraints. A greater proportion of physical logic produces a more manageable and defensible schedule.

• Sequence Logic (Resource Logic) — defines a preferred sequence of activities. This work does not have to occur in the defined sequence and is therefore subject to change.

Lags

Lags should be used sparingly. They introduce complexity and 'hidden' logic that can be easily overlooked and can lead to scheduling errors when multiple calendars are used.

• Where possible, replace lags 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 carefully about their use and makes them visible to the project team.

Constraints

Constraints should be used sparingly. Excessive constraints can introduce complexity and may result in 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. They hold constrained activities in place regardless of logic, resulting in incorrect float and date calculations.

• Situations where constraints may be required:
  • Contract completion dates and separable portions.
  • Important milestones — works area possession/handover dates, or Client-supplied deliverables.
  • Establishing a start to a sequence of work in an area defined by localised logic.
  • As an alternative to long lags where they do not truly represent credible logic.
• Any constraints should be documented in the Basis of Schedule with justifications explained.

Horizontal & Vertical Traceability

• Vertical traceability — ensures dates, scope, and progress are consistent between different sections or levels in a schedule (e.g. the summary schedule is consistent with the detailed schedule).
• Horizontal traceability — ensures interdependencies between activities have been planned in a logical sequence (e.g. design activities link to procurement, which links to construction, and so on).

Path Convergence & Merge Points

When an activity has many parallel activities as predecessors, this is known as path convergence, creating a 'merge point' or 'logic hotspot'.

• Path convergence can affect the achievability of the schedule because the risk of achieving each predecessor 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 exceeds 2, it may indicate unnecessary logic — review for merge points and remove any redundant relationships.