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.
However there are few generally accepted practices or rules of thumb for establishing the size and placement of schedule contingency in the project schedule. As a result, risk buffers are often arbitrary, and intuition based. The schedule manager’s challenge is to quantitatively justify required schedule slack, and distribute the slack through the schedule in a manner that best reflects reality. By identifying and addressing sources of rigidity, the schedule manager can remove arbitrary and overt instances of schedule float. The schedule manager’s two major obstacles are making accurate estimations, and ensuring that slack is used responsibly.
Estimates Based on Estimates
The fundamental challenge behind estimating schedule contingency is that schedule contingency is an estimate of an estimate. Estimating schedule contingency requires the subject matter expert or the team lead to estimate how inaccurate the initial labor and duration estimate is. Historical project data can guide estimating schedule contingency. However this still represents an estimate of an estimate. These secondary estimates are inherently less objective, and more prone to uncertainty.
Filling Available Time (Ideal Gas Law)
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.
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.
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.
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.
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, it does answer the more fundamental question, whether the project schedule is still achievable.