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:

HardConstraints_1

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

 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

 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.

HardConstraints_4

 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

HardConstraints_5

 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.

HardConstraints_6

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.

HardConstraints_7

 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.

HardConstraints_8

 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.

 

 

Next Webinar

Is Being A Good Project Manager Good Enough?

Written by Bridget Fleming
Bridget Fleming, PMP, PMI-SP, MCP has been in project management and scheduling for over 30 years, working with Microsoft Project since 1994 and Project Server since 2002.  As the founder of PMM, a project management training and consulting company, she has provided implementation support, process definition, user support and training for Microsoft Project and Project Server.  Bridget ran a Microsoft Project helpdesk for 15 years that provided support for a Fortune 100 client with over 500 users and has trained thousands of users in Microsoft Project and Project Server.  Bridget was a core team member for the development of PMI Practice Standard for Scheduling - Second Edition.  You may contact Bridget at bfleming@p-m-m.com.
Share This Post
Have your say!
00
5 Comments
  1. Nice article

  2. A variation might include one more task called “Schedule Margin” that links the final two milestones as FS. The Schedule Margin is under control of the Program Manager and is property of the program, not the individual task owners.

    If someone wishes to extend a task duration, they must negotiate the increase with the PM who then can reduce the Schedule Margin to assure timely completion. This becomes a positive control mechanism since it must be manually decremented. There are ways to float this duration, but I do not recommend it.

    Nice article Bridget!

  3. I couldn’t agree more with one thing: use constraints if you must, but monitor total slack. It’s the schedules without complete link networks that don’t understand slack where all of the surprise failure comes from. Now if we could all monitor total slack AS WELL AS peak units on the resource side life would indeed be good. Thank you for this Bridget.

  4. For the example you gave, where you are planning an event that must happen on a certain day, adding a hard constraint at the end of the project is appropriate. The problem is that 99% of the time, and especially with new users, they’re not used this way.

    The main advantage and purpose of MS Project is the calculation of the critical path. You enter your tasks, durations, relationships, resource assignments, etc. and it calculates the end date for you. When you enter hard constraints, you are interfering with that calculation. You would be better off using Excel instead because Excel won’t be calculating an end date that isn’t accurate.

    For someone in charge of planning an event — a wedding, a track meet, etc — adding a hard constraint the date of the event is the right thing to do, and as you pointed out, watch the float values. But for almost every other kind of project, stay away from hard constraints and allow Project to do what it was designed for.

  5. Hi Brian,
    I agree that constraints can be a problem when used incorrectly which is why I included the caution at the bottom of the article, and why I make sure my students understand how to use them correctly.

    I also agree that you want to let MS Project calculate the end date of the project which is represented in my example using the Project Complete milestone.

    However, I have found that most projects, whether it is a satellite launch or a software release or anything else, have a commitment date, promise date, contract requirement or whatever they call it that they are trying to meet. Given this, there needs to be a way for the project to measure progress toward meeting it. That is the value of the Target Complete with MFO.

Leave a Reply