Slack/Float Principles

Every project should expect schedule variances. Some Tasks and Activities will finish early. Others will finish late. Small variations in either direction can impact a rigid schedule across the length of the project. Float, also known as Slack, built into a project schedule is a means for schedule managers to keep variance impacts localized. Some slack is necessary to keep a schedule flexible, however if a schedule contains too much float, team members will encounter significant periods of inactivity. 

How much slack is appropriate for a project? How should float be incorporated into a schedule and how should total available float be tracked and reported? This article will discuss these questions and overview the creation of float at the Task level. 

Rigid Schedule Characteristics                                      

Though the components that contribute to schedule rigidity are inherently technical, they are summarized here to facilitate discussion of creating adequate schedule float. 

The most obvious indicator of a rigid schedule is when delaying completion of any single Task irrevocably delays project completion by the same amount of time. In this situation, the project schedule has:

  • All Resources (team members) working at 100 percent or greater capacity
  • Few Tasks performing and completing in parallel
  • Multiple parallel critical paths
  • No gaps in work between major activities or major milestones

When a rigid schedule encounters delays it results in what is often known as a day-to-day slip, and can require drastic corrective action. Each of these characteristics individually can contribute to schedule rigidity. Their combined effects limit the Schedule Manager and Project Manager’s recovery options.

Slack or Schedule Contingency and Fundamental Problems

Most scheduling guides recommend creating schedule contingency activities to allow for and manage schedule variance. The GAO Schedule Assessment guide echoes the generally accepted principle that hour estimates and durations should not be padded, instead establishing a separate schedule contingency based on the complexity of the Tasks and the overall project schedule.  

US Government Accountability Office, GAO Schedule Assessment Guide. https://www.gao.gov/products/GAO-16-89G, December 2015

Filling Available Time (Parkinson’s Law1Parkinson, Cyril Northcote, “Parkinson’s Law“. The Economist. )

It is a matter of shared experience that any assignment will take exactly as long as the time allowed. The college graduate knows that a ten page paper due in two weeks will be completed just as close to the deadline as the same paper due in three weeks, with just as much last minute agony. This natural inclination to fill the void means project schedules with large amounts of slack just before a major milestone will create a false sense of security for managers. Team members and team leads will always work towards the deadline for which they believe they are actually accountable. The problem, with working towards the perceived last possible due date is that team members often do not see the full impact of real or perceived delays. The solution is to distribute reasonable slack estimates across multiple activities and multiple weeks to create a more realistic and achievable schedule. 

Quantifying Required Float

As is the case for confronting any uncertainty, defining and bounding arbitrary float will reduce overall float and constrain its impact. Making realistic assumptions about resource availability can reduce some demand for float. Float can also be accounted for with realistic assumptions of resource efficiency. 

Holidays and Time Off

The easiest opportunity to bound schedule float is to define holidays. Most organizations in the US provide eight to ten holidays a year. These days should be marked as non-working days in the project schedule calendar. 

Additionally, a schedule manager can reduce working time around historically high periods of inactivity. Many U.S. team members take off the Friday after Thanksgiving. The week between Christmas and New Year’s and the month of August are other common vacation times. By reducing standard working time during these weeks, schedule managers capture realistic resource efficiency losses. 

Accounting for sick days is not recommended. Employee sick leave estimates range between 5 and 10 days per year, or approximately 0.9 hours per 40 hour workweek. However employee sickness varies significantly from average estimates. Some team members will never take sick days. Others will have an illness requiring weeks of treatment, and the reassignment of responsibilities. The unpredictability of medical leave makes its anticipation impractical at a general level. 

Resource Availability (Units)

Resource availability is the fraction of fulltime a resource can dedicate to a specific task. All Tasks and Resource assignments follow a simple formula, known as the Work Equation.

Figure 1: The Work Equation for a nominal eight-hour workday.

By this formula, a developer who is assigned half time to an eight hour Task will take two business days to complete the Task. It is a common mistake for managers to assign Resources full time to a Task. Even if labor estimates are accurate, a project that assigns full time Resources is likely to run late. In the business environment no Resource can sustain 100 percent utilization for more than a few days, even in urgent circumstances. Team members must support meetings, fulfill timekeeping and human resource obligations and get sidetracked by interruptions and other work events. In reality, team members will work part time on multiple Tasks in parallel during a typical week.

Figure 2: Two identical development tasks. One has a resource operating full time, with four days of float before the deadline. The other shows the tasks requiring 10 days of a half time developer.

Managing Resource Units is necessary for collaborative tasks with two or more resources assigned. A testing event that requires 60 hours of a junior tester and 30 hours of a senior tester will necessarily require the senior tester to work half as hard as the junior tester. 

Leveling Resource Loads

The last opportunity to account for and absorb float is to ensure resources are not overloaded. Figure 3 shows a Resource Usage view of a large system design effort. The example project has the equivalent of eight fulltime Business Analysts (IBO-BA) to support the project. Whenever the weekly workload exceeds 320 hours (8 x 40 hours), there are not enough BAs available to cover the required effort.

Even without looking at individual tasks, it is easy to identify the project’s resource allocation rigidity. Based on resource availability during the month of May, this project schedule will likely require substantial slack to achieve the real deadline. Placing a week of float directly at the end of May might sufficiently buffer the schedule, but it will make the schedule perpetually late. By spreading the Tasks out sufficiently, so that there are few or no resource overloads, the schedule manager can produce a more accurate and reliable schedule to track progress against. 

Figure 3: Generic Resource Types in a large project schedule. Numbers in red indicate instances where there are more Task hours planned in a given week, than available resource types.

By accounting for Holidays, typical vacation times, realistic resource availability on tasks and achievable resource loads, the schedule manager can distribute reasonable amounts of slack across the project schedule, reducing or eliminating arbitrary schedule contingencies. 

Measuring Dispersed Float

As soon as the first schedule variances start consuming float, managers may ask, “How much slack is left in the schedule?” A schedule contingency at the end of a project schedule, or a network diagram can easily quantify this answer. However with slack dispersed within individual Tasks on the project schedule, calculating total slack is difficult and not entirely informative. 

Figure 4: Textbook example showing how to calculate slack using forward and backward passes through a schedule network diagram. This strategy presumes significant schedule rigidity and does not account for resource availability.

The solution is a three-step answer that quantifies the overall schedule variance and its impact:

  • Identify schedule pressures against key milestones and recover schedule variance where practical
  • Forecast potential delays at least a month out with a high degree of accuracy
  • Analyze resource load and availability to ensure resources are not tasked with more work than is achievable in a week

While this three-step answer does not directly answer how much slack remains in the project schedule, is does answer the more fundamental question, whether the project schedule is still achievable. 

Next Steps

This article has identified the characteristics of a schedule rigid schedule and discussed principles for quantifying and distributing schedule float. 

Future articles will explain the mechanics of building holiday calendars, balancing the work equation and using resource leveling to build schedule float at the Task level. 

Managing slack and schedule variance is part of a Schedule Manager’s weekly schedule management process and will be covered in articles dedicated to that practice.

© ProactiveScheduleManagement.com