Author: 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.

Mastering Your Critical Task Threshold

All too often project managers narrowly focus on the critical path tasks in a project to the exclusion of all other tasks. In many projects, however, what we call near-critical paths are just as likely to cause a project to experience schedule problems and miss the commitment date. To illustrate, let’s start with two definitions from the Project Management Institute®’s Practice Standard for Scheduling – Second Edition: 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. 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. The project critical path is the longest path in time from the project start to the project finish which, by definition, means it is the path with the least total slack. As I described in my previous article, “In Defense of Hard Constraints,” if driven by a “Target Complete” commitment date, the total slack on the project critical path may be positive, zero or negative. However, by focusing strictly on the critical path, a project manager may be surprised when another path — a near-critical path — causes a delay in the project end date. Think about this scenario: You’re managing a 12-month project with about 300 tasks. When you create your schedule model, 12 paths are defined from the start of the project through the end of the project. When you identify the critical path, you see that it has a total slack of two days. This means that your current finish date is two days before your commitment date. If you decide to proceed with this plan without making any adjustments, what do you think the likelihood is of completing this critical path (and therefore the project) on time? In most cases, with this length of a project, if nothing is done to increase the total slack, the chances are very close to zero percent. However, what if you have two additional paths, each with four days of total slack? What’s the likelihood of completing those paths on time? I would argue that they are probably also close to zero percent, particularly if there are tasks in those paths with duration estimates where you’re less confident of the accuracy. These are what we refer to as near-critical paths. So what’s a project manager to do? We recommend for each project that you manage that you determine an acceptable level of total slack for likely success — your critical task threshold. This threshold will vary from project to project, but should be based on things such as: Total duration of the project (or remaining duration if the project is in progress). If you have a 12-month project, you would want a higher level of total slack on critical and near-critical tasks before you commit to a date than if you have a three-month project. Confidence in your duration/work estimates for the project. Are the tasks in this project similar to things you have done in the past or are you developing new technology that you have no experience with? Historical information from project closeout/lessons learned sessions for similar projects. Looking at past projects, how close do you typically come to meeting your original plan/baseline? Other schedule risk factors. These may include things like external dependencies, resource availability, etc. Some organizations will build schedule contingency into a project to minimize these risks; but if your organization doesn’t plan schedule contingency, make sure to consider these factors when determining your critical task threshold level. Once you determine what this threshold should be, the project should not be committed to and baselined until ALL tasks have total slack values that are greater than your critical task threshold. This may be achieved by compressing your schedule using crashing or fast tracking (see the box), or if necessary, by eliminating scope if it’s impossible to accomplish everything in the time available. Compression Methods Crashing is a method of shortening a schedule’s duration by analyzing a number of alternatives to determine how to get the maximum schedule duration compression for the least additional cost. That may include options such as expediting parts, adding shifts, overtime, etc. It also increases the cost of the project. Fast tracking is a method of shortening a schedule’s duration by changing network logic to overlap phases that would normally be done in sequence, or to perform schedule tasks in parallel. Typically, this method increases risk in the project, but not the cost. Once that threshold has been met by all tasks, you are ready to baseline and begin the project. As the project progresses, you should continue to monitor and address tasks that don’t meet the threshold, not just the very worst case critical path. There’s a seldom used option in Microsoft Project that will help you do just that! Under the File/Options/Advanced selection, at the very bottom is the option, “Tasks are critical if slack is less than or equal to __ days.” The default is set to 0 days. By default, Microsoft Project defines critical tasks to be any task with 0 or negative slack. This value should be changed so that it’s equal to your critical task threshold for the project. This allows you to focus on tasks that don’t meet your threshold (not just those already in trouble). Once you make this change, all references to critical tasks in Microsoft Project will use your threshold. To demonstrate, I will use a small project with a required completion commitment target date of 9/11/15 as an example. Note that the Target Complete task has a Total Slack of 0 days due to the use of the Must Finish On constraint approach as described in my previous article: The critical path (the path with the least total slack) in this project has two days of total slack. It’s made up of IDs 1, 6, 7, 10 and 11. However, I also have a path that includes IDs 4 and 5 with four days of total slack. Let’s assume I have determined that my critical task threshold for this project should be five days. This means that I want to have no fewer than five days of total slack on all of my tasks. I set the threshold under the File/Options/Advanced selection to five days. Now when I use Microsoft Project options that reference critical tasks, as shown below, my threshold value is used. For example: When I select the Format/Bar Styles/Critical Tasks check box, all tasks with Total Slack less than or equal to my threshold (five days) are highlighted in red as critical. Prior to changing the threshold value, when the File/Options/Advanced/Tasks are critical if slack is less than or equal to __ days option was set to zero days, with the Format/Bar Styles/Critical Tasks check box checked, the project looks like this. No tasks are highlighted as critical. When I select View/Data/Filter: Critical all tasks with total slack less than or equal to my threshold of five days are displayed. Using this approach, I can identify tasks in any paths that need to be compressed so that they reach five days or greater of total slack. I’m still able to sort by total slack to identify the true critical path tasks (those with the smallest total slack) at the top of my schedule if I want to focus on those first. Note: Sorting can be done using the View/Data/Sort/Sort By… option or by clicking the downward arrow on the Total Slack column and selecting Sort Smallest to Largest as shown below: As the project progresses, you’ll want to make adjustments to your critical task threshold. For example, on your 12-month project, once you’ve been working for a few months, you’ll likely be able to reduce the threshold because there’s less time remaining. After a few months you’ll also have some performance history on this project to see how accurate your estimates have been to date. This can help inform the new value you decide on for your critical task threshold. Modified battery image courtesy of Intel Free Press, licensed under a Creative Commons CC BY-SA 2.0 license.

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. An additional milestone, Target Complete, is added following the Vacation Plan Complete milestone.  A Finish to Start link is created from the Vacation Plan Complete milestone to the Target Complete milestone. 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.