Date Constraints

Ideally, relationship logic, the durations of activities, and resource availability determine the planned early and late start dates of all activities within the schedule network. However, in some cases it may be necessary to override the calculated start or finish dates of activities by imposing calendar restrictions on when an activity can begin or end. Such restrictions are referred to as date constraints. Constraints can be placed on an activity’s start or finish date and can limit the movement of an activity to the past or future or both. Because constraints override network logic and restrict how planned dates respond to actual accomplished effort or resource availability, they should be used only when necessary and only if they are justified in the schedule documentation. Generally, constraints are used to demonstrate an external event’s effect on the schedule. For example, constraints may be used to show the expected availability of a production line.

“Not earlier than” constraints affect the forward pass of the schedule and thus may delay a program by pushing some activities’ start dates later than their predecessors dictate. These types of constraints are also known as “past-limiting” in that they prevent activities from starting or finishing earlier than planned but allow them to slip into the future if predecessor activities are delayed.12

  • Start no earlier than (SNET): schedules an activity to start on or after a certain date even if its predecessors start or finish earlier. That is, SNET constraints prevent an activity from beginning before a certain date. SNET constraints are also called start on or after constraints.

  • Finish no earlier than (FNET): schedules an activity to finish on or after a certain date. That is, FNET constraints prevent an activity from finishing before a certain date. FNET constraints are also called finish on or after constraints.

“Not later than” constraints affect the backward pass of the schedule and thus may unrealistically accelerate a project. These types of constraints are also known as “future-limiting” in that they prevent activities from starting or finishing later than planned but allow them to be accomplished earlier.

  • Start no later than (SNLT): schedules an activity to start on or before a certain date. That is, SNLT constraints prevent an activity from starting any later than a certain date. SNLT constraints are also called start on or before constraints.

  • Finish no later than (FNLT): schedules an activity to finish on or before a certain date. That is, FNLT constraints prevent an activity from finishing after a certain date. FNLT constraints are also called finish on or before constraints.

“Must” or “mandatory” constraints affect both the forward pass and the backward pass of a schedule, forcing activities to occur on dates regardless of network logic. These types of constraints prevent activities from starting or finishing on any day other than the date assigned.

  • Must start on (MSON): schedules an activity to start on a certain date. That is, MSON constraints prevent an activity from starting any earlier or later than a certain date, thereby overriding network logic. MSON constraints are also called mandatory start constraints.

  • Must finish on (MFON): schedules an activity to finish on a certain date. That is, MFON constraints prevent an activity from finishing any earlier or later than a certain date, thereby overriding network logic. MFON constraints are also called mandatory finish constraints.

Date constraints are often categorized as either soft (also referred to as moderate or one-sided) or hard (also referred to as inflexible), depending on how they restrict the ability of the activity to accelerate or slip according to the established network logic.13 Soft constraints include SNET and FNET constraints. These are called soft because while they restrict an activity from starting or finishing early, depending on network logic, they allow the activity to start or finish later than planned. In this respect, these constraints allow delays to permeate the schedule and, given available float, possibly affect the program’s end date.

Hard constraints include SNLT, FNLT, MSON, and MFON constraints. SNLT and FNLT constraints prevent activities from starting or finishing later than planned, essentially restricting the ability of any predecessor delays to affect their start and finish dates. While these types of constraint allow activities to start and finish earlier than planned, the acceleration of activities is not usually as big a concern to program management as the delay of activities.

Mandatory start and finish constraints are the most rigid because they do not allow an activity to either take advantage of time savings by predecessor activities or slip in response to delayed predecessors or longer-than-scheduled durations. By setting the early and late dates of an activity equal to each other, a mandatory start or finish constraint immediately eliminates all float associated with the activity and renders activities static in time; successors might start on the next day, even though unconstrained logic would not permit it.

  1. We use date constraint names consistent with September 2013 DOD data exchange instructions supplementing the United Nations Center for Trade Facilitation and E-business (UN/CEFACT) XML schema 09B. These names may differ depending on the scheduling software used. See appendix V for more information and a mapping of common date constraint names.↩︎

  2. Our definitions of hard and soft constraints assume that a schedule is formulated under forward scheduling. That is, the project start date is firm and all activities are scheduled to occur as soon as possible to determine the project finish date. Under backward scheduling, the project end date is considered firm and all activities are scheduled as late as possible (ALAP) to determine the project start date. Whether the plan is forward or backward scheduled affects how restrictive certain constraints are. For example, under backward scheduling, a finish no earlier than constraint is considered a “hard” constraint. In general, backward scheduling is not a best practice because it removes all float from a path of activities.↩︎