What is safe start date & safe float?

In a deterministic project schedule, total float represents the amount of time an activity start or finish date can be delayed without affecting the project schedule end date or an intermediate benchmark (e.g., fixed milestone). The uncertainty in the project schedule will likewise affect the amount of flexibility each activity has to be delayed.  

For a stochastic project schedule, the safe start date for any activity is defined as the latest possible time to which an activity may be delayed safely without affecting the probability of completing the project by the targeted P-value completion date. Safe float is defined as the available amount of time flexibility that an activity has, considering remaining risk/uncertainty in the schedule. Safe float of any activity is its total float adjusted for risk and uncertainty remaining in the schedule. 

Since activities in project schedules may start on planned dates, as in instances with GPM, the safe float available to a task is always defined with respect to the task early date in the simulation’s schedule model. The safe float is thus the time between the early date of the task and its safe start date; however, not all tasks have a safe start date, and sometimes the safe float is negative, indicating that such activities are critical in nature and cannot be delayed.     

Why should total float not be trusted?

Total float is calculated using a deterministic schedule. Deterministic schedules represent only one possible scenario out of potentially thousands, if not millions, of possibilities of how the project might be executed. As the task durations are inherently uncertain and there is potential for risks to impact project progress, use of total float calculated in a deterministic schedule is therefore not the best measure to predict whether the project will be delayed or not.  

A Highly Likely Completion Date May Equate to P95/P75 in the Early/Paced P-Value Curves

For example, consider a schedule where “Task A” has 6 days of total float. During execution of the project, “Task A” was delayed by 5 days and, considering available total float, the deterministic schedule will still indicate on-time completion. However, due to uncertainty that still exists in future tasks, it is likely that at least one or more tasks on the successor path of “Task A” will take longer when started, thereby delaying the project end. Consequently, we see that total float is a lagging indicator when making decisions pertaining to delays and their potential impact on the project. Total float identifies the delay in the project after it has occurred, and the project team must then react to control it after the fact.  

  1. Total float can misrepresent the actual flexibility or likely success of the project.
    A systematic misrepresentation of the task durations can be used to game the available total float to the detriment of the project. For example, using only optimistic durations on tasks will show an abundance of available total float, whereas using only pessimistic durations will mean that the total float available to tasks will be very low. Critical paths on the schedule can thus be manipulated to cross tasks for the benefit of a party even when the actual critical path during project execution may likely be different.
  2. Total float does not represent the same flexibility at the project start or end.
    Schedulers have always understood that 5 days of total float at the start of a project is not equivalent to 5 days of total float at the end. This leads to recommendations on using a percent of remaining project duration as the allowable float to define criticality. This approach, however, still treats every path in the network equally, irrespective of the uncertainty on the path, and uses a judgment in picking the “correct” percent value for float, in addition to being calculated for a deterministic scenario. Hence a task on a riskier path will be treated equally to a task occurring at the same time but on a purely deterministic path.       

Why should we use safe float?

  1. Safe float is true flexibility.
    Safe float considers duration and other risk uncertainty in the schedule. This inherently means that safe float is not calculated based on one set of deterministic durations; instead, it takes into consideration all significant duration possibilities that are anticipated to occur during execution of the project. Safe float thus represents the true flexibility available for a task to be delayed, as it considers all possible duration outcomes for all activities in the portion of the network rooted at the activity. Unlike total float, using different sets of durations for the remaining tasks will not impact safe float if the logic ties and uncertainty in the schedule remain the same.
  2. Safe float is a better indicator of criticality.
    As safe float considers uncertainty and is independent of the choice of durations for the deterministic project schedule used to determine safe float, its value provides an important indication of criticality. Certain tasks in a project schedule may not have a valid safe start date, indicating that any delay to the task will potentially translate into a delay to the project end date. This allows the project manager to focus resources on tasks that are absolutely critical rather than tasks on the deterministic critical path which are sure to change as the project progresses.
  3. Safe float is an early indicator of potential delay in a project.
    Projects are typically controlled or monitored using deterministic schedules or a project baseline; however, as described earlier, the choice of deterministic durations for float calculations may be random and/or insufficient. When tasks have a negative safe float value, it indicates that the early date denoted on the baseline schedule might already be causing delay. As a result, such scenarios can be handled early, and tasks planned for execution even sooner, by modifying the plan or adding resources to complete tasks on their predecessor path earlier.
  4. Safe float improves decision-making when floating tasks.
    Unlike total float, if an activity is delayed within its safe float, there is an inherent certainty that the delay will not impact the project end date. Using up total float provides no such certainty, as described earlier. Accordingly, any delay past the safe float available to a task provides a direct indicator of a potential delay in the project. As projects are executed, it is common for certain tasks to be delayed for a myriad of reasons: managing with lower resources, floating work to avoid frequent start and stops, pacing due to delay in related but different schedule path, etc. When deciding to delay a task, the available total float is ineffective; however, safe float provides a significant tool to quickly assess which tasks can be safely delayed and how much delay to the task there can be without impacting the project end date.