Activity constraints: Limiting the degrees of freedom of project activities

Activity constraints can be imposed when there is a need to control the start or finish of an activity in a project schedule. In this article, three types of commonly used activity constraints will be discussed along the following dimensions:

  • Constraint types
  • Constraint hardness
  • Switching from constraint hardness

Constraint types

Activity constraints can be used to control the degrees of freedom in a project schedule and can be generally classified in three classes. Each type has a start and a finish version, as follows:
  • Ready dates imply earliest start or finish times on activities and hence force the activity to start/finish no earlier than the defined time instance. These constraints are known as ready start time (RST) or ready finish time (RFT).
  • Due dates imply latest start/finish times on activities and force activities to start/finish no later than a predefined time instance. These constraints are referred to as due start time (DST) or due finish time (DFT).
  • Locked dates imply a fixed time instance and force the activity to start/finish on a predefined time instance, known as locked start time (LST) or locked finish time (LFT).
Figure 1 displays a project with three activities and with ready times and a due date. This picture will be used to illustrate the effect of shifting activity 1 further in time. This effect will depend on the hardness of the three constraints, as explained below.

Figure 1. An example project with activity constraints and a manual forward shift

Constraint hardness

The use of activity constraints increases the project manager’s control of the project schedule but leads to a flexibility decrease for the project scheduling algorithm of the software tool. Although it can be generally recommended to restrict the use of activity constraints to prevent the construction of a rigid project schedule, there are four ways to handle constraints in a project schedule, varying the degree of constraint hardness. These hardness options influence the result of user interventions (e.g. a manual activity shift in time, adding a constraint or precedence relation, changing an activity duration, etc.) or software interventions (e.g. rescheduling the baseline schedule, update of tracking information, etc.) on the project schedule. The four constraint hardness modes are as follows:
  • Hard constraint mode: All activity constraints and the precedence relations between activities need to be satisfied at all times. When manual activity shifts lead to constraint and/or precedence violations, the software tool will automatically return to the previous schedule and undo the infeasible user intervention.
  • Moderate constraint mode: All activity constraints need to be satisfied at all times. When user interventions lead to constraint violations, the precedence relations will be overruled by allowing a certain degree of overlap between project activities. Consequently, a moderate activity constraint has a higher priority than a precedence relation between two activities.
  • Soft constraint mode: Activity constraints can be violated due to user interventions at any time. However, the software tool will try to prevent the total number of constraint violations by searching for the best possible schedule to satisfy constraints to the best possible extent. 
  • Forward constraint mode: Activity constraints are only satisfied in one direction and are treated as forward activity constraints. Consequently, all activity ready times are explicitly taken into account, while locked times and due dates are often ignored: locked times are treated as ready times, which will only be satisfied unless it is not possible due to predecessor activities while due dates are completely ignored and will possibly be violated by user or software interventions at any time.

Figure 2. The impact of a shift in activity 1 of figure 1 depends on the hardness of the activity constraints

Figure 2 shows that the impact of a shift in activity 1 of figure 1 is different for each of the four types of the hardness of the activity constraints. Note that the activity shift for both the moderate and the soft constraint modes result in a violation of the original project schedule logic. More precisely, while the moderate constraint mode resolves conflicts between activity constraints by allowing overlaps between activities (i.e. violation of the original precedence relations), the soft mode tries to construct a project schedule where the constraint violations are minimized. In the example of figure 2, the soft mode constructs a baseline schedule without activity overlaps but leads to a violation of the due date constraint of the third activity.

Switching from constraint hardness 

Changing the constraint hardness for a current schedule might lead to unexpected activity shifts, complete schedule changes or infeasible schedule solutions and therefore need to be done with care. Since the hard constraint mode is the most strict constraint hardness, switching to this mode can lead to three possibilities:
  • The switch can be done without any changes and the constraint hardness is set to the hard mode.
  • The switch is not possible with the start times of the current schedule due to constraint conflicts, but leads to no constraint conflicts when every activity is set to its earliest possible start (known as an Earliest Start Schedule (ESS)). In this case, the user has the choice to either undo the constraint hardness mode switch or to switch to an ESS.
  • The switch is neither possible with the start times of the current schedule nor with the ESS: undo the constraint mode switch.






© OR-AS. PM Knowledge Center is made by OR-AS bvba Contact us at info@or-as.beVisit us at www.or-as.beFollow us at @ORASTalks