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.
