If you just cannot get your schedule to match an important finish milestone deadline you may be tempted to go “thermonuclear” by inserting a Mandatory Finish constraint on the milestone. You’ll definitely get your important finish date this way, but there will be collateral damage to your schedule. Let’s explore this.
If you want a child to stay away from a stove top burner you could simply tell the child ‘do not touch’. A more indirect approach is to tell them about the stove, and in doing so provide them knowledge that warns them to stay away. The later approach is our intent today in explaining mandatory constraints. We are telling you how mandatory constraints work not so you will haphazardly use them, but so that you will know enough to be cautious and even wary of their use.
Project managers can become so fixated on their project deadlines that they force their schedules to match the deadlines by inserting Mandatory Finish constraints. They do not realize that in doing this they may jeopardize the integrity of their schedule.
This article explains the application and effects of mandatory activity constraints on your schedule.
We have in Figure 1 our Primavera P6 demonstration project.
This is a simple Replace Heat Exchanger Tubing Repair project that consists of demolition tubing, installation tubing, and quality assurance inspection deliverables, i.e. work breakdown structure (WBS) elements. The project completion date according to the natural network logic of the schedule is Friday, March 17th, 2017. This finish date is evidently seen on the activity table for the ‘project completion date’ milestone. You may also view this milestone completion date on the Gantt chart. Your program sponsor, however, provides you a project deadline of Tuesday, March 14th. How do you adjust your activity constraints accordingly to meet this deadline?
There are two categories of activity constraints in Primavera P6 Professional: soft constraints and hard constraints. Soft constraints are considered soft because they can be overridden by network logic and will not generally create negative float in the schedule. Hard constraints are considered hard because they potentially can create negative float in the schedule. Let’s proceed by first applying a soft constraint and then, if required, ratchet up our constraint until we see the desired impact.
In Figure 2 we apply the soft ‘Finish On or After’ constraint with a 14-March-2017 constraint date.
After we recalculate the schedule we see the effect of our soft constraint in Figure 2. What happened? Well, absolutely nothing. Our ‘project completion date’ milestone finish date remains 17-March-2017 and the total float of all our activities is still zero. It appears that the ‘Finish On or After’ constraint is impotent. This is not true. For our particular schedule situation it has no effect, but for instances where this constraint does have an impact refer to the following blog “Microsoft Project and Finish No Earlier Than Constraints“.
Note in this blog that the P6 ‘Finish On or After’ constraint equivalent in Microsoft Project is ‘Finish No Earlier Than’. Regardless of the ‘Finish On or After’ constraint’s value as a scheduling tool in P6 it has no effect on our schedule situation. So we proceed and ratchet up our ‘project completion date’ constraint.
This time we apply a hard constraint. Let’s say the 14-March-2017 is the contract completion date. Completing our schedule previous to this date has no benefit, so we choose a ‘Finish On’ constraint instead of the ‘Finish On or Before’ constraint. The ‘Finish On’ constraint is nice because it generates positive, zero, or negative total float on associated predecessors, if they finish before, on, or after the constraint date, respectively. And the actual activity assigned the constraint will display either zero or negative total float. We proceed and insert our ‘Finish On’ hard constraint as in Figure 3.
What effect did this constraint have on our schedule? Well, the Gantt chart still looks the same, so no effect there. The finish date of the ‘project completion date’ milestone and, therefore, the project is still 17-March-2017. This is not quite what we were hoping for. But look at the total float column. The total float for all activities is negative three days. Well, that’s good to know. So the total float is saying our schedule is three days behind. The 17-March-2017 finish date in the finish column and Gantt chart puts us three days late.
This is great, but our sponsor specifically says the project completion date is 14-March-2017. We want to see this completion date on both the activities table and the Gantt chart. Well, to make this happen we have to again ratchet up our activity constraint. This time we decide to use the hardest constraint, a Mandatory Finish constraint. As displayed in Figure 4 we insert a Mandatory Finish constraint on the ‘project completion date’ milestone.
Let’s now examine its effect. The ‘project completion date’ in the activities table has a total float of zero and a finish date of 14-March-2017. Great! This is exactly what we want.
However, when we inspect the schedule more closely however; we get a different story. The ‘project completion date’ milestone is exactly on 14-March-2017. That’s good! But ‘quality assurance inspection’ occurs later on the timescale (see both activities table and Gantt chart). Not good. This in fact doesn’t make any sense.
As displayed in Figure 5, the relationship connecting ‘quality assurance inspection’ and ‘project completion date’ is finish-to-finish (FF), where ‘quality assurance inspection’ is the predecessor and ‘project completion date’ the successor.
In order for that relationship to hold true ‘quality assurance inspection’ must complete before completion of ‘project completion date’. Well, the Gantt chart clearly displays, Figure 5, ‘quality assurance inspection’ completing after ‘project completion date’ so our FF relationship did not hold true.
In short, our Mandatory Finish constraint on ‘project completion date’ caused a network logic violation, where the successor completes before the predecessor. In the precedence diagram the predecessor is the cause or driver and the successor is the effect or driven. The predecessor is first in order. And, in particular, the predecessor in the FF relationship is first on the timescale if not simultaneous. But this relationship is violated in our ‘Replace Heat Exchanger Tubing’ schedule because of our Mandatory Finish constraint.
Let’s step back and examine the collateral damage. We have on the Gantt chart ‘project completion date’ finishing on target. However, network logic is violated and none of the preceding activities fall into line before ‘project completion date’. Not good. The activities table displays the desired total float and finish date 14-March-2017 for ‘project completion date’ activity. That’s good. But other activities that should come before ‘project completion date’ actually come afterward. Not good. All other activities in fact are showing negative three days total float, which warns us something is wrong.
So our ‘project completion date’ Mandatory Finish milestone is met both on the Gantt chart and activities table, however 1) network logic is violated and 2) none of the preceding activities either on the Gantt chart or activities table meaningfully demonstrate how that Mandatory Finish constraint date is achieved. The Mandatory Finish constraint date is disjointed from the rest of the schedule, which is not good. And this also compromises the integrity of the schedule.
Project managers fixated on project end dates are susceptible to the allures of Mandatory Finish constraints. Mandatory constraints will ‘appear’ to meet their contractual constraint dates, as promised. But, a closer examination, however, reveals problems.
The Mandatory constraint can and probably will violate network logic at some point. This can be seen when the milestone it constrains is disjointed from the rest of the schedule, and the schedule does not meaningfully demonstrate on either the activities table or Gantt chart how the Mandatory constraint date is achieved. For these reasons Mandatory constraints are generally discouraged.
Typically, schedules submitted with such constraints will not give the recipient confidence that the project schedule is actually achievable. A ‘Finish On’ constraint is more suitable. It does not violate network logic, and thus shows the progression of activities up to attainment of the completion date. Also, it gives warning in the activities table total float column when you are behind schedule, and by how much. So use a ‘Finish On’ hard constraint in lieu of a ‘Mandatory Finish On’ hard constraint. It’s a more accurate, and yes, a more honest description of the schedule.