Unfortunately most projects come with deadlines, a fact that is a challenge when building schedule to meet them. Finish No Later Than constraint (FNLT) are helpful in Microsoft Project to stress the importance of meeting a deadline date.
Constraints express the importance of a particular date in the life of the project. So when network logic alone cannot define the true situation of the project schedule a constraint is appropriate. Finish No Later Than constraints are particularly helpful to define submittal dates for deliverables. This is when the deliverable can be submitted at an earlier date, but definitely must be submitted by the FNLT constraint date.
This article discusses the insertion of a Finish No Later Than constraint in a Microsoft Project schedule to mark the submittal of deliverables date in the life of the project.
Finish No Later Than Constraint
Both Start No Later Than (SNLT) and FNLT constraints restrict tasks from moving later than the specified constraint date. Though these constraints are similar, each one may be a more conservative fit depending on the schedule situation. Let’s explore these two constraint types with some examples.
Consider an asphalt paving effort, which may be negatively impacted by cold winter weather conditions. In this situation you would not want to pave asphalt beyond a specified date in the late fall season. How would you define this date? Would you use a SNLT or FNLT constraint?
The SNLT constraint is a more conservative and better fit for this situation. If your calendar reaches the near winter season then it is best not to even consider starting asphalt paving. To say the asphalt paving must finish by a certain winter calendar date is not helpful.
When the FNLT constraint date is breached it’s too late. The horse has already left the barn. You’ve already started asphalt paving so you must finish the paving effort to the detriment of your installed asphalt. So the SNLT constraint is a better fit than the FNLT constraint for defining winter shutdowns.
The Finish No Later Than constraint, however, is more helpful for deliverable delivery due dates. When it comes to deadline dates the FNLT constraint is more conservative and harder to meet than the SNLT constraint. It is always easy to start an effort. Completing the effort comes with difficultly. Completing the effort requires a demonstration that the effort is in fact complete, whereas starting an effort requires little proof of progress in some situations.
FNLT constraints are therefore good for alerting project managers of the agreed upon contractual delivery date of submittals. Breaching a SNLT constraint may be little cause for concern, you can say your effort started and provide no proof: although this is the hight of bad practice and poor ethics. After all, who are you trying to kid? But missing a FNLT delivery constraint is a problem, because you promised to provide a deliverable by the Finish No Later Than constraint date. So project managers should be cautious when setting Finish No Later Than constraint dates. And, yes, FNLT constraints are better than SNLT constraints for defining dates for submittal of deliverables.
In Figure 1 we have a demonstration schedule.
Figure 1
This project is scheduled for the summer time, so cold weather asphalt paving conditions are not an issue and we do not need to consider insertion of a SNLT constraint. The contract does specify, however, that a fully functional underground piping system must be provided by July 24th, 2018. Our schedule therefore requires a FNLT constraint on the project closeout milestone. This is the underground piping system delivery commitment date.
To insert our FNLT delivery constraint date highlight project closeout in the task table and select the task tab, properties ribbon group, and information icon. In the resulting task information dialog select the advanced tab. From the constraint type drop down menu select Finish No Later Than, Figure 2.
Figure 2
Set the constraint date to July 24th, 2018, Figure 3.
Figure 3
The resulting schedule with July 24th project deliverable delivery date is displayed in Figure 4.
Figure 4
Not only did our FNLT constraint date hold, but on the Gantt chart it caused project closeout to violate the finish to start (FS) relationship with its predecessor asphalt surface roadway. Well, that does not make sense. You cannot complete the project until asphalt surface roadway is complete. 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.
Figure 5
Now when we view the Gantt chart of our schedule, Figure 6, we see the end date of the project based upon the natural schedule logic.
Figure 6
Further, we know we are “behind the curve” by 3-days because of the negative 3-days total float, i.e. total slack, displayed in the task table, again, Figure 6.
To address this schedule situation the project manager has a few, although limited, options:
- Start the project earlier
- Shorten the duration of backhoe excavation and piping installation
- Request a later project delivery date.
It does not appear that there are any opportunities for fast tracking the schedule. Shortening the duration of both the ‘backhoe excavation’ and ‘piping installation’ appear most promising and should get us close to our target project closeout FNLT constraint date.
Summary
The best scenario is for your schedule’s task durations and network logic to drive task finish dates. There are times, however, when you have an external constraint, such as a contract specified delivery date, which has a binding effect on your schedule. This delivery date is best modeled with a Finish No Later Than constraint. You want to display the effects of this constraint in the task table.
You do not, however, want your constraint to violate network logic on the Gantt chart. This may lead some folk to confuse the actual and achievable completion dates 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.
And one final point that goes back to scheduling practice standards – use constraints very conservatively in your schedules. They should only exist for contractual or other external constraints; not be used to push tasks onto a desired date. Oh yes and document every constraint you create so its existence and rationale are clear.