Wide usage of schedule constraints is generally discouraged. But what are specific situations when schedule constraints should be avoided and others when constraints are suitable?
Schedule constraints describe important dates in the life of the project that network logic alone does not capture. But constraints both hard and soft should be limited in the schedule, because constraints impede the propagation of schedule updates and/or progress throughout the schedule, i.e. constraint dates do not automatically change and/or update when the schedule has been updated.
Schedules that have many constraints are not dynamic; they generally require tedious manual updates to each constraint date. So wide usage of constraints is not good scheduling practice, and there are situations when constraints are particularly ill-suited or, hopefully, well-suited. You want to consider the appropriateness of constraints in each situation.
This article provides general guidance on the suitability of inserting a constraint into your particular project situation.
Avoid using constraints in the following situations:
- Accounting for temporary availability of project resources – Most scheduling software have resource calendars for specifying availability of project resources. Resource calendars are a more dynamic way to define availability without constraints fixing task related efforts, as per the availability of the assigned work crew.
- Modeling windows of opportunity – Fixing task dates with constraints, again, is a static way of scheduling task dates. If your situation is an office move that takes place over the weekends it would be better to assign the moving task a specific task calendar where the workdays are only Saturday and Sunday. This way if your moving effort slips the related tasks will automatically reschedule to the next available weekend. If moving dates are defined with constraints than they will not automatically update with current schedule progression; you must manually change these constraint dates.
Consider applying constraints in the following situations:
- External dependencies – deliveries are best modeled using a combination milestone and constraint, i.e. a constrained milestone. The milestone marks the delivery event and the constraint specifies the delivery date. This is better than constraining a succeeding task to start no earlier than the delivery date. With the constrained milestone if the delivery is late you know that schedule delays are directly related to the raw material and/or equipment delivery.
- Meetings – Group activities like meetings require an agreed upon date before scheduling. Constrain the meeting date so that it remains fixed despite the ebb and flow of its surrounding task’s start and finish dates.
- Weather – Your river dredging project absolutely must compete before the river freezes in winter, so constrain your river dredging to complete on or before, say, November 22nd. A constraint, however, may not be your best tool. Task calendars may better support weather related windows of opportunity for each year.
- Public events – like meeting participants the public needs notification on when the event will occur. The planned date is publicized and should remain fixed.
- Deliverables – These are contractual dates you agreed upon to provide project related deliverables.
Most scheduling guidelines discourage the wide adaption of constraints. Some guidelines even require constraint dates to be specified in the contract.
Resource calendars and task calendars in place of constraints support a more dynamic schedule. Windows of opportunity are therefore better defined using the scheduling calendar tools. But use constrained milestones to model the delivery of raw materials.
Other constraints are particularly appropriate when participants must be notified of a respective event date, such as meetings or public events. In these situations the event date is fixed despite the impact of schedule updates and/or schedule progression. It also is important to constrain the due date of deliverables, so team members have a fixed deliverable target date to aim for.