Did you know that Microsoft Project uses a different definition for Total Slack than what you probably learned in your project management training courses? In this blog, I will teach you the Microsoft Project definition of Total Slack and more importantly, I will teach you why it is better than the standard definition…

Total Slack Defined

If you have ever taken a project management course, you undoubtedly learned the definition of Total Slack or Total Float. First, let’s talk terminology. Total Slack and Total Float mean exactly the same thing. You will see the terms used interchangeably depending on the text that you are reading. Take Microsoft Project for example. Microsoft Project uses the term Total Slack. So because of this, we will also use the term Total Slack from this point on in this blog.

Now let’s look at the typical textbook definition of Total Slack… Total Slack is the amount of time a task can be delayed before it impacts the project completion date. In the below screen capture, we can see that Task 3 has four days of Total Slack before the project completion date is impacted. Said differently, Task 3 can be delayed up to four days before we impact or delay the end of the project.

Why Total Slack is Important

As project managers, we can use Total Slack to effectively focus one of our most limited resources… Time. We will use Total Slack to focus our attention on those tasks that are driving, or close to driving, the schedule. These tasks are those that have little to no Total Slack. Tasks with little to no Total Slack have very little wiggle room. In other words, they can’t be delayed without impacting the project completion date. Or, maybe they can only be delayed a very short period of time before they impact the project completion date.

Either way, tasks with little to no Total Slack need to be high on our watch list. If we don’t track them closely and ensure that they start and finish on time, we could easily find ourselves with a late project. Other tasks that have a moderate to excessive amount of Total Slack can simply be watched. We can let the people assigned to these tasks manage their schedules until Total Slack values become an issue. So we focus on tasks with little to no Total Slack and we simply watch tasks that have moderate to excessive amounts of Total Slack.

That is how we use Total Slack to effectively focus our time. We simply don’t have the time to focus on every task in the project schedule. Total Slack values help us identify which tasks need to be focused on and which ones don’t. For example, look at the below screen capture. We added the Total Slack field to our table and we see that some tasks have 3 days Total Slack, some have 8 days Total Slack, and others have 158 days Total Slack.

So what can we do with this knowledge? Well, we should closely manage those tasks with 3 days Total Slack first. They have most potential to impact the project completion date. And we should watch those tasks with 8 days Total Slack since they can easily start to impact the project completion date if we have even a minor delay. And the tasks with 158 days Total Slack? For now we will simply track and update task progress. We might even be able to reallocate the resources assigned to the tasks with 158 days Total Slack to keep other tasks with less Total Slack on schedule if they are interchangeable. That is just one example of how we can manage our schedule using Total Slack values.

Total Slack Defined in Microsoft Project

In Microsoft Project, Total Slack is defined differently than our standard textbook definition of Total Slack that we introduced above. Its definition is expanded to include not only the project completion date, but to also include Date Constraints and Deadlines into its calculations. Total Slack in Microsoft Project is defined as the amount of time a task can be delayed before it impacts the project completion date, it violates a Hard Constraint, or it violates a Deadline. Microsoft Project will show us the lowest value of these three options. Let’s take a look at what I mean by this…

In the below screen capture, I have a set of tasks and milestones to develop System 1. We see that ‘System 1 Housing’ tasks and milestones have 158 days of Total Slack available. There are no Date Constraints and no Deadlines assigned to these tasks.

If we now assign a deadline of 3/31/2019 to the ‘System 1 Complete’ milestone as shown below, the Total Slack value of the ‘System 1 Housing’ tasks and milestones that drive the ‘System 1 Housing Complete’ milestone drop to 4 days. This reduction in Total Slack happens because Microsoft Project is taking Hard Constraints and Deadlines into consideration when assessing Total Slack values.

Using this Expanded Definition of Total Slack to our Benefit

This expanded definition of Total Slack is actually a little more practical than the standard definition. Instead of simply seeing how many days a task can be delayed before the project completion date is impacted, Microsoft Project also takes into account Hard Constraints and Deadlines into its Total Slack calculations as we saw above. We can use this expanded definition to our benefit. Let’s see how…

In my schedules, I assign Deadlines to key milestones to reflect contractual date requirements or other critical externally imposed date constraints as shown in the below screen capture. And as you also see below, I typically assign these Deadline to key milestones that are located at the top of my schedules. By using this strategy, I can then use Total Slack values to really see how much time my tasks can be delayed before I impact something important such as a contractual date requirement, an externally imposed date constraint, or the project completion date. This is a lot more powerful than simply seeing how many days I have until I breach the project completion date, isn’t it???

A Note About Hard Constraints

And now I have one additional topic that I want to address in this blog. And that is my use of Hard Constraints. I seldom use Hard Constraints in my schedules. I prefer to use Deadlines. Why do I prefer Deadlines? Because if a Deadline is breached, the result is simply negative Total Slack. My schedule continues to adjust beyond the Deadline and the schedule remains dynamic. I want my schedule to adjust and remain dynamic so that I see the most accurate milestone completion dates or project completion date even if the result is negative Total Slack. If I see negative Total Slack, I know that I absolutely must replan some work to get rid of the negative Total Slack. We simply can’t have negative Total Slack.

Hard Constraints are called hard for a reason. They can actually freeze the schedule and make it static once they are breached. The Hard Constraint can function like a blocking wall that prevents any movement past the constraint date. And once the schedule is frozen, I no longer see accurate forecasts. This is really a matter of personal preference though. And for me, I just prefer to use Deadlines because of how they behave once breached.


In closing this blog, we learned about the expanded definition of Total Slack that Microsoft Project uses. And we learned how to use this expanded definition to our benefit. We learned that by assessing Total Slack values in Microsoft Project, we can actually ensure that we are always aware of how many project days we have before we breach the project completion date, violate a Hard Constraint, or violate a Deadline. And we discussed how I use Deadlines to exploit the expanded definition of Total Slack in Microsoft Project.