PERT (Programme Evaluation and Review Technique) was developed around 1958 as one statistical means for estimating durations based upon optimistic, realistic and pessimistic values. It was used as part of the development of the Polaris submarine project.
The float between two Tasks ‘A’ and ‘B’ is the amount of time Task ‘A’ can be delayed before it has a detrimental effect on the start or end point of Task ‘B’.
In its simplest form for a finish-to-start relationship, there may be two weeks after the completion of Task ‘A’ and the start of Task ‘B’, and Task ‘B’ requires Task ‘A’ to finish.
The float is therefore two weeks.
If Task ‘A’ is held up for three weeks then Task ‘B’ will be delayed by one week.
Float is shared across the project. Hence, if it is available it will almost certainly be used. There is always a limited supply of float.
MS (Microsoft) project defines the above as ‘free slack’, with ‘total slack’ being the period for which delay will cause the project end date to change.
If a task has a ‘total slack’ of 3 weeks it means that if the task is delayed by 3 weeks it will become part of the critical path.
By definition any further delays will extend the end date of the project.
In addition there is a subtle difference between ‘float’ and ‘slack’.
They often used in the same context.
It is very common for people to use the word ‘slack’ instead of float.
Slack really only applies to Activity-on-Arrow networks and the events that are created.
These show arrows that represent tasks and start and end at ‘events’.
It is only these ‘events’ that can have ‘slack’.
Only the tasks themselves have ‘float’.
However, for most times they will be one and the same.
When the free slack is zero there is no room for delay.
Any series of tasks that end with the final task bearing the project end date, that all possess zero slack are by definition on the critical path.
A delay in any one task will cause slippage of the project end date.