Generally,
constraints affect the dates, violates the network logic and one of the reasons
for negative floats or irrationality on the schedule. But again this is based
on your project requirements and these constraints could help you to provide a
complete control of a project however no more than 10% of a project’s activity
should be constrained.
Constraints
other than contractual ones are generally not used since they impose specific
start and or finish dates and in some instances completely OVERRIDE the logic
that is contained in the schedule. The idea is to let the logic determine the
dates as opposed to using constraints to do this.
Early
constraints (e.g. Must Start/Finish On or After) are a typically a shortcut to
represent the outcome of related work that the scheduler is excluding from the
schedule logic. This is justified only for interfacing work that - in total,
including its initiation - is clearly outside the scope of the project
scheduled (e.g. contractual access restrictions, customer-furnished
info/eqpt/permits.) Using early constraints for in-scope work (or for external
work that depends on in-scope work) removes that work from logical schedule
analysis, overrides the logically-derived scheduled (early) dates of the
constrained activities and their successors, and jeopardizes the validity of
the entire logical model of the project including float calculations.
Late
constraints (e.g. Must Start/Finish On or Before) are typically imposed to
represent external obligations or commitments – aka “deadlines.” Such
commitments can be imposed by contract (e.g. completion milestones) or by some
other governing document (e.g. Project Charter, Board Instruction, Executive
Tantrum, etc.) Late constraints can override the logically-derived (late) dates
for the constrained activities and their predecessors, thereby complicating the
interpretation of Total Float and identification of the “Critical Path.” Where
multiple late constraints are applied in a network of related activities, Total
Float becomes unreliable as an indicator of driving logic; then other methods
of logical analysis must be used.
Other
constraint types (Start/Finish On, or Mandatory Start/Finish) are even more
restrictive with respect to driving logic flow – they are rarely if ever
justified.
It is true
that ALL constraints affect total float computations but so do the calendars
being used, the remaining durations, the logic, the lags, the TIMES etc. So I
would re-iterate that this clause was included in the scheduling specifications
because constraints impose specific start and or finish dates and in some
instances completely OVERRIDE the logic that is contained in the schedule.
