If the goal is to complete the project in as little time as possible, the question is why would a scheduler want to use a “Start No Earlier Than” (SNET) constraint on a project task? Let’s explore this paradox.
Constraints describe external dependencies on the project schedule or tasks along the project schedule. Scheduling guidelines recommend using activity constraints sparingly. The ideal is for your task durations and associated relationships to drive the schedule. If your schedule has only task durations and dependency relationships defining the start and finish of tasks than updating your schedule will go rather nicely.
If, however, you have activity constraints in the schedule be forewarned that they will not automatically update according to your updated task durations and/or dependency relationships. The constraint dates will not change. Also you will have to examine each activity constraint individually to see if schedule updates are cause for making any changes to your constraint definition. If so, then you will have to manually change the constraint date and/or type.
Hence the reason scheduling guidelines advise you to limit the number of activity constraints in the schedule. Despite the paradox of using a SNET Constraint to restrain a task when the goal is to complete the project in as little time as possible, there are instances when this constraint type provides a proper and helpful enhancement to the schedule description.
This article describes how to insert a SNET activity constraint in Microsoft 2013, and when a SNET activity constraint is beneficial to the project schedule definition.
We begin with a demonstration schedule, Figure 1.
Here we have a manufacturing and installation project. After parts are manufactured they are shipped to site and installed. Note that all activities are on the critical path. Also, Manufacturing consists of two phases. The network logic says we can proceed with Manufacturing Phase II immediately after completion of Quality Assurance Phase I. Phase II manufacturing is scheduled to start on January 13th, 2016.
However, we know that a critical component for Manufacturing Phase II will not arrive and be available until January 18th, 2016. Another possible issue is that a critical labor resource for Manufacturing Phase II is not available until Monday, January 18th. Either reason would justify the insertion of a SNET constraint on Manufacturing Phase II.
As you can see, resource availability can compel the project manager to divert from the schedule dependency/network logic and insert a constraint. Whether it is the delivery of material, arrival of equipment, or availability of labor, the need for critical resources may justify the insertion of a SNET constraint in the schedule.
The SNET constraint in our demonstration says the Manufacturing Phase II effort cannot proceed until Monday, January 18th. So if the network logic says Manufacturing Phase II may commence on January 13th, the SNET constraint will delay this activity until Monday, January 18th. If the network logic says Manufacturing Phase II begins after Monday, January 18th, then the SNET constraint has no effect on the schedule.
Let’s go ahead and insert a SNET constraint in our demonstration schedule and see its impact. Note that all the tasks in Figure 1 have a constraint type As Soon As Possible (ASAP). This means the activity will begin as soon as the network logic says it can, and no later. Well, we know our Manufacturing Phase II effort cannot start until Monday, January 18th, regardless of what the network dependencies say. Thus, we inform the scheduler to insert a SNET constraint type with a date of Monday, January 18th.
To include a SNET constraint on Manufacturing Phase II highlight the Manufacturing Phase II task and select Task tab, Properties ribbon group, and Information icon, Figure 2.
In the resulting Task Information dialog, Figure 3, select the Advanced tab.
And in the Constraint Type drop down menu select “Start No Earlier Than”. Finally, in the Constraint Date menu option select Monday, January 18th, as the constraint date, Figure 4.
So your SNET January 18th constraint is now set. The effect on the schedule is seen in Figure 5.
First note that Manufacturing Phase II task has shifted to a start date of Monday, January 18th. Great! This is what you want. The network logic had it starting earlier, which the SNET constraint prohibited. Also, note that Manufacturing Phase I and Quality Assurance Phase I are now blue bars, because they are no longer on the critical path. In Figure 6 we insert a Total Slack column in our task table and can clearly see that these tasks, in addition to Notice to Proceed and Project Start, have 3-days of total float (total slack).
The SNET constraint has caused all the activities previous to have 3-days total float, and, therefore, they are no longer on the critical path. Well, this is another reason that constraints are discouraged and should be limited; you lose your critical path.
You want your schedule to be driven by task durations and dependencies. Sometimes, however, an activity cannot start until the arrival of a critical resource, regardless, of what the task network dependency logic allows. In these instances, a SNET constraint is advisable. Be forewarned though that you, most likely, will lose part of your critical path.
Another negative is that you may have to manually adjust your constraint date as task durations, lags, and dependencies are updated. Schedule updates are a compelling reason to limit the number of activity constraints. Nevertheless, a SNET constraint is a useful tool when network logic alone cannot accurately describe the intricacies of your project schedule.