Negative Float

The DCMA guideline sets the allowance for Negative Float (Slack) as zero.  In other words, there should not be any in the programme.  

Negative Slack happens in one of two ways: 

1. When a hard constraint is preventing a task being pushed out to a later date and is therefore preventing calculation of the true critical path.  This is potentially a problem that can have big repercussions, especially if there is a risk of penalties for late finish.  It can also be hard to spot when you have a large complex programme, meaning the problem may not be realised before it is too late to fix. 
2. When it is the result of the programme indicating a missed deadline.  A deadline is a useful tool employed to provide early warning of a potential problem at a known pinch point or key milestone.  This then allows a chance to take corrective action, before the problem happens while still allowing the programme to calculate critical path based on the logical dependencies.

In the example above Task 5 is fixed by the imposition of a Hard Constraint, either a Must-Start-On 19^th Aug or a Must-Finish-On 27^th Aug (both have the same effect of fixing the Task in place and overriding the logic). 

Notice that there appear to be two critical paths –

1. Tasks 1, 6 7 & 8 - which would appear to be the prime critical path, given that it’s the longest chain of Tasks, and…
2. Tasks 1, 2 5 & 8 which would appear to have a day of slack on Task 5.  Notice also, that Task 1, 2 & 5 have –3 days slack noted in the Total slack column.

This is actually a distorted view driven by the corrupted logic caused by the Hard Constraint.  Now look at the actual logic as driven by the dependencies when the Hard Constraint is removed:

Straight away we see that the finish date has moved out from the 3^rd Sept to the 7^th and that we now have a clearly defined critical path running through Tasks 1, 2 5 & 8.  This is the true situation based on the logic and dependencies in the network. But this doesn’t address the important issue that we need Task 5 completed by a set date (in this example 27^th August).  Important milestones like this are best handled by using a deadline.

In this example, the logic driving the critical path is correct, and Task 5 has had a deadline set to say that it should be complete by 27^th August.  This is indicated by the Green Arrow on the Task.  Notice the Total Slack indicates that the chain of Tasks leading into Task 5 all show -3 days of Slack indicating that in order to meet the deadline the preceding tasks will need to be accelerated.

The deadline does not restrict the calculation of the logic of the critical path, but it does identify there is a problem, by showing the hazard warning above and advising how many days behind programme the task is calculated at. 

This can then be reviewed at the time of writing the programme, and a solution put in place to correct the overrun before the programme is finalised and issued, all without the need for a Hard Constraint or negative float or slack (whichever you prefer to call it).

To set a deadline double click the task and then choose the advanced tab and set the date in the deadline field (see illustration shown right)