Every month you run your schedule update and check the total float on the critical path. Maybe it is 14 days. You report 14 days. Someone asks if that is good or bad. You say it depends. The meeting moves on.
The problem is not the 14 days. The problem is that 14 days means nothing without context. Was it 22 days three months ago? Was it 8 days three months ago? Those are two completely different projects and 14 days is the same number in both.
Float is not a status. It is a trajectory.
How to read a float trend
Plot your critical path total float over the last six reporting periods. Six is enough to see a trend. More than eight and the early points are usually from a different phase of the project and stop being comparable.
What you are looking at is the rate of float consumption. Not the position. The rate.
| Pattern | What it means | What to do |
|---|---|---|
| Steady decline, 2-4 days per period | Normal float consumption on a project that is roughly on track. Activities are completing slightly later than planned but the critical path is absorbing it. This is what most healthy projects look like. | Monitor. No intervention needed unless the remaining float drops below the project's risk threshold (typically 10-15 working days for EPC). |
| Steep decline, 5+ days per period | Something is actively consuming float faster than the programme can absorb. Either the critical path has shifted to a path that was already behind, or a delay event is compounding. | Investigate immediately. Run a period-on-period comparison to identify which activities slipped. Check if the critical path shifted. If it shifted, the longest path analysis from last month may be stale. |
| Flat | Float is stable. Activities on the critical path are completing on or close to plan. This is the ideal state but it is unusual for more than two or three consecutive periods. | Validate. Flat float can also mean the schedule is not being updated properly. Check that actual dates are being loaded, not just durations being reduced. |
| Increasing | Float is growing. Either recovery actions are working and the project is pulling ahead, or there has been a re-baseline that reset the reference point. | Check for re-baseline. If the baseline changed, the trend resets and prior points are not comparable. If there was no re-baseline, this is genuine recovery and worth reporting as such. |
| Sudden drop | A single event consumed a large amount of float in one period. A major delay, a logic change, or a constraint that was added or moved. | Find the event. Run a longest path comparison between this period and last period. The activity where the critical path diverges is usually the cause. |
The rate matters more than the position
A project with 30 days of float that is losing 6 days per period is in worse shape than a project with 10 days of float that is losing 1 day per period. The first project will be critical in five months. The second project has ten months before it hits zero.
This is obvious when you write it down. It is not obvious when you are staring at a single number on a dashboard that says "30 days" with a green indicator next to it.
The rate of consumption is the leading indicator. The absolute position is the lagging indicator. Most reporting systems show you the lagging indicator and ask you to infer the leading one. That is backwards.
A useful rule: If float consumption per period exceeds the average number of working days per period remaining, the project will not finish on time without intervention. This is arithmetic, not opinion. If you are losing 5 days of float per month and you have 4 months of float left, you have 4 months of float and 20 months of programme remaining. The maths does not work.
What P6 does not show you
P6 will give you the total float on any activity for the current schedule. It will give you the longest path. It will give you the critical path based on whatever filter you have set.
What it will not give you, out of the box, is the trend. You have to build that yourself. Every month, record the total float on the critical path. Put it in a spreadsheet. Plot it. This takes five minutes and it is probably the single most valuable thing you can do with your schedule data each period.
Some PMs automate this with P6 SDK scripts or claim digger tools. Some do it manually. The method does not matter. What matters is that you have six data points on a chart, and that chart goes in the steering committee pack every month.
Float trend and delay claims
Here is where the float trend becomes more than a management tool. It becomes evidence.
In a dispute, the claimant needs to demonstrate that a delay event consumed float and pushed the completion date. The respondent will argue that float was already being consumed by the contractor's own performance and the delay event merely landed on a path that was already in trouble.
A six-period float trend line tells this story without ambiguity. If the float was stable at 20 days for four months and then dropped to 2 days in one period, the causation is clear. If the float was already declining at 5 days per month and the delay event landed on a path with 3 days remaining, the picture is different.
The contemporaneous record of float consumption, period by period, is exactly what a delay expert needs to apportion concurrency. Building it takes five minutes a month. Not building it creates a gap in the evidentiary record that costs tens of thousands to reconstruct after the fact.
What to report
Three things. Every month. On one slide.
- The current total float on the critical path. One number.
- The trend chart. Six periods. No decoration. Two axis labels. The chart speaks for itself.
- The rate. "Float is declining at approximately 3.5 working days per period." One sentence that tells the committee whether to worry.
That is the float slide. It takes less space than most PMs use to explain what total float means, which the committee already knows.