Ideally in forward scheduling you specify As Soon As Possible (ASAP) constraints to commence your tasks at the earliest possible dates. So is it therefore redundant to specify a Start No Later Than (SNLT) constraint on a particular task? Let’s examine this question.
This article explores how and when to use a Start No Later Than (SNLT) constraint in Microsoft Project 2013.
Constraints are inserted in Microsoft Project schedules to highlight the importance of a particular date in the life of the project. Normally you want your task durations and network logic to drive the start dates of your tasks. Most scheduling guidelines recommend limited use of constraints, because they do not automatically update along with updated task durations and/or logic.
Each constraint in Microsoft Project must be examined individually to determine whether changes in task durations and/or logic are cause for adjustment. However, you may have an external constraint that puts a binding restriction on the latest date your task can start. In the SNLT constraint, network logic is free to decide the task start date if the task start falls on the timescale to the left of the SNLT constraint date. However, if the start date falls on or beyond (to the right) of the SNLT constraint date then the SNLT constraint date is binding. The SNLT constraint limits free movement of task bars towards the right in the timescale; the start date cannot go to the right of the SNLT date.
In Figure 1 we have our demonstration Microsoft Project schedule.
This Microsoft Project schedule is for an underground pipe installation across a roadway. The project commences on November 7th and the natural logic of the schedule has it concluding on December 2nd. Note, in particular, the last non-milestone task: ‘asphalt surface roadway’. Cold winter conditions can negatively affect the asphalt paving of a roadway. In Canada it is not recommended that you install asphalt pavement later than say the 3rd week of November. This is an external weather inspired constraint on our pipe installation project. So this project must be at the asphalt paving stage by the third week of November.
If the project manager cannot find a way to meet this constraint date then the project will have to be delayed until spring; not an ideal situation. On the positive side, this constraint only affects delays. If the network logic says asphalt paving can occur prior to the 3rd week of November, our constraint is not binding in this situation.
What kind of constraint would we use in our schedule to model this winter project blackout period of time? Microsoft Project has a SNLT constraint that matches well with our winter weather inspired constraint, which limits how much we can delay asphalt paving a roadway in Canada during the fall season. To insert this SNLT constraint highlight the task ‘asphalt surface roadway’, and select Task tab, properties ribbon group, and information. In the Task Information dialog select the advanced tab, and from the constraint type drop down menu select ‘Start No Later Than’, Figure 2.
Then select November 21st for the constraint date, Figure 3.
In Figure 4 we see our constraint dates effect on the schedule.
Not only did our constraint date hold, but it caused ‘asphalt surface roadway’ to violate the finish to start (FS) relationship with its predecessor ‘backfill & compact’. Here we must ask ourselves whether it is appropriate to perform ‘asphalt surface roadway’ out of sequence. Maybe here a hard FS relationship is not as critical as the start date of your constrained task.
You won’t know until you examine your schedule logic in light of the constraint. In these cases then you will actually want to examine each constraint individually. Well, it is quite apparent that ‘backfill & compact’ must completely finish before ‘asphalt surface roadway’, so it is inappropriate to commence ‘asphalt surface roadway’ out of sequence.
So our constraint holds, but causes a network logic violation. Ideally, we want to see the impact of our constraint date without violating network logic. To achieve this go to File | Options > Schedule and in the ‘scheduling options for this project’ frame toggle off ‘tasks will always honor their constraint dates’, Figure 5.
Now when we view our schedule we see the end date of the project based upon the natural schedule logic. Further, we know we are “behind the curve” by 9-days because of the negative 9-days total float, i.e. total slack, displayed both in the task table and on the Gantt chart, Figure 6.
Also note the yellow constraint warning sign in the indicator column of the task table.
The project manager has a few, although limited, options:
- Start the project earlier
- Shorten the duration of backhoe excavation and piping installation
- Delay the project until the spring weather is more favorable for asphalt surfacing a roadway
It does not appear that there are any opportunities for fast tacking the schedule. Shortening the duration of both the ‘backhoe excavation’ and ‘piping installation’ appear most promising and should get us close to our target ‘asphalt surface roadway’ SNLT constraint date.
The best scenario is for your Microsoft Project schedule’s task durations and network logic to drive task start dates. There are times, however, when you have an external constraint, such as a weather constraint, which has a binding effect on your schedule. Cold weather negatively affects asphalt paving and prudence calls for limiting this task’s commencement late in the fall season. This fall season limiting advice is best modeled with an SNLT task constraint.
Also, you will want to highlight the impact of this SNLT constraint on your Microsoft Project schedule. Listing total slack in the task table and/or on the Gantt chart achieves this purpose. You do not, however, want your constraint to violate network logic. This may lead some to confuse the actual and achievable completion date of the project. So toggle off ‘tasks will always honor their constraint dates’, and let the total slack values warn when the project is in danger of not meeting its schedule constraints.