In Defense of Hard Constraints…

I have a confession to make that will surprise many experienced Microsoft Project users – I use Must Finish On (MFO) constraints.  I have found that they are the only way that I can always ensure an accurate Total Slack value in my projects.  Let me explain using a simple example…

Here is the scenario – I have a project plan for a trip to New York City as shown below.  When I teach Microsoft Project, I always tell my students that projects should be modeled so that all paths flow out of a single Start milestone at the beginning of the project and all paths flow into a single Complete milestone at the end of the project (with a few possible exceptions that are outside the scope of this discussion).  This project follows that best practice:

Figure 1 – Original Schedule Model

My vacation planning needs to be complete by 3/26/15.  This means I have 5 working days between when the project is currently scheduled to finish (3/19/15) and when it must be finished (3/26/15).  I have 5 days of flexibility/slack in my project completion.  Based on the definition of Total Slack and Project Critical Path (below) I should see 5 days of Total Slack in my critical path for this project.

Definitions: From the Project Management Institute’s Practice Standard for Scheduling Second Edition.

Total Slack – The total amount of time that a schedule activity may be delayed from its early start date or early finish date without delaying the project end date, or violating a schedule constraint.

Project Critical Path – The longest schedule path from the project start date to the project finish date and generally determines the duration of the project.

The Total Slack on the critical path of a project may be negative, zero or positive.  Despite what is often stated, it is NOT always equal to zero.  In the scenario above, I have a critical path (IDs #1, 4, 5, 8, 9) that I want to reflect a Total Slack of 5 days, but it is currently showing a Total Slack of 0 days because no project end date has been modelled.  (All dates and calculations in this article are based on a 5-day work week.)

Using the Deadline Date Approach

Often I hear recommendations to use a Deadline Date to mark the due date of the project.  However, using a Deadline Date will only drive the Total Slack if the project is running late (the Finish date is later than the Deadline Date).  If the Deadline Date is later than the Finish date, the critical path will always have a Total Slack of 0 days. See Figure 2 below.

 Figure 2 – Deadline Date on ID 9 is set to 3/26/15

Using the Deadline Date approach, the Total Slack on the critical path will always be 0 days when the Deadline Date (due date) is later than the Finish. Therefore, I don’t have visibility to how many days of slack I actually have between the current project Finish and the Deadline Date (due date).  The 5 days between when the project is currently finishing and when it must be finished is not reflected.

Additionally, when using a Deadline Date that is later than the project Finish, the Total Slack of all non-critical tasks and milestones will be calculated based on a 0 day critical path – with a backward pass that uses the Finish date of the completion milestone as the Late Finish of the completion milestone.  Note that the Total Slack values don’t change between Figure 2 and Figure 3 even though the Deadline Date (due date) changes from 3/26/15 to 4/2/15.  My due date has moved out, but there is no increase in Total Slack reflected.  In fact, there is no difference in the Total Slack values between Figure 1 with no Deadline Date, Figure 2 with a Deadline Date of 3/26/15 and Figure 3 with a Deadline Date of 4/2/15.  I have no way of seeing the real slack in my project as compared to the due date using a Deadline Date.

 Figure 3 – Deadline Date on ID 9 changed to 4/2/15

In Figure 4, the Duration of ID 4 is increased from 5 days to 12 days which causes the project end date to push out past the due date of 3/26/15.  If the project runs late and the Finish date is pushed later than the Deadline Date, only then will the Deadline Date drive the backward pass and be used in the Total Slack calculations.  A warning indicator is also displayed, showing that the task is running late.

Also, only when the project runs late, is an accurate Total Slack calculated for tasks and milestones NOT on the critical path (see IDs #2, 3, 6, and 7 in Figure 4).  The Total Slack on tasks that are not affected by a delay should not change.  However, here, they change from being incorrectly calculated with a backward pass that uses the Finish date of the completion milestone, to being correctly calculated against the Deadline Date.

 Figure 4 – Duration on ID 4 increased to 12 days

Using the Must Finish On (MFO) Constraint Approach

I think it is critical, however, to be able to see an accurate Total Slack on each task in a project whether the Total Slack is positive, negative or zero.  By using the following approach, an accurate Total Slack will always be calculated.

1. An additional milestone, Target Complete, is added following the Vacation Plan Complete milestone. 
2. A Finish to Start link is created from the Vacation Plan Complete milestone to the Target Complete milestone.
3. A Constraint Type of Must Finish On is assigned to the Target Complete milestone with the due date assigned as the Constraint Date

 Figure 5 – Target Complete milestone added and assigned an MFO of 3/26/15

Note: You can use the Project Completion milestone (Vacation Plan Complete) to identify the Total Slack of the Project Critical Path.

The Total Slack of the Target Complete milestone itself should not be used for analysis as it is does not always provide an accurate Total Slack for the project.

Using this method, all tasks and milestones in the project (except the Target Complete milestone) will always reflect an accurate Total Slack whether it is zero, positive (Figure 5), or negative (Figure 6).  This means that if you have a standard project where all paths lead to the completion milestone, you can see the Total Slack for the critical path on the completion milestone – in our case, the Vacation Plan Complete milestone.  In Figure 5, the Total Slack for the critical path is 5 days, in Figure 6 (with ID 4 Duration increased to 12 days) it is -2 days.  Note how the Total Slack correctly does not change for tasks not impacted by the delay caused with the Duration increase from 5 days to 12 days of ID 4.

Figure 6 – MFO set to 3/26/15 and Duration on ID 4 increased to 12 days

Additionally, if the due date changes to 4/2/15, using this method, all Total Slack values (except the Target Complete milestone with the assigned MFO) reflect the increase to the Total Slack as shown in Figure 7.  The project critical path now has 10 days of Total Slack.

 Figure 7 – MFO on ID 9 changed to 4/2/15

If you like the visual indicators provided by the Deadline Date and want to include the arrow in the Gantt area and the warning indicator, a Deadline Date can be added to the Vacation Plan Complete milestone as shown.  In this way, its primary use is visual.  If the due date of the project changes, both the Deadline Date of the Vacation Plan Complete milestone and the Constraint Date of the Target Complete milestone must be changed.

 Figure 8 – MFO on Target Complete milestone and Deadline Date on Vacation Plan Complete milestone

I will agree that the Deadline Date approach often works because many projects have negative slack in the critical path.  However, if you want accurate Total Slack values whether they are zero, positive or negative, try the MFO approach described above.

One caution, don’t use the Must Finish On constraint anywhere but at the end of a path – in this case the Target Complete.  I use a modified version of the above approach if I need to measure Total Slack against a milestone date that is in the middle of a path.  Send me an email if you are interested in the details.