Negative float: what it actually means and who owns it

Against what?

Total float is the gap between the late dates and the early dates, and late dates only exist because something anchors the backward pass. When the forecast finishes later than the anchor, the backward pass pulls late dates earlier than early dates, and the gap goes negative. So negative float always names a collision with a specific object you can point to: a hard constraint on a downstream activity, a Must Finish By date on the project in P6, a Deadline in Microsoft Project, a contractual milestone constrained to its obligation date. Find the anchor first. The recovery conversation for "we are ten days behind a client-imposed access date" and "we are ten days behind a Finish On constraint somebody typed in eight months ago and forgot" are different conversations, and the float column cannot tell them apart.

The three usual producers

In practice almost all negative float traces to one of three sources:

• A hard constraint downstream. Mandatory Finish, Finish On, Must Start On: anything that fixes late dates regardless of logic. The forecast slips, the constraint does not, and everything on the path between them goes red. This is the category most likely to be an artefact rather than a real commitment, because hard constraints accumulate in files the way logic errors do: silently, and with the author long gone.
• A must-finish-on project date. In P6 the Must Finish By field on the project drives the backward pass for the whole programme. Set it to the contract date and any forecast slip past that date paints negative float across every driving path simultaneously. This is a legitimate way to run a schedule, provided everyone reading it knows the convention. Handed to a reviewer who assumes the backward pass starts from the forecast finish, the same file looks like a disaster.
• A contractual milestone with a late forecast. The milestone carries a constraint matching its obligation, the work feeding it is forecast late, and the negative float is simply the size of the miss. This is the real case, the one negative float exists to report.

Baseline versus mid-execution

Negative float on a submitted baseline is a different animal from negative float in month seven. A baseline is a proposal. Submitting one with negative float says "we plan, from day one, to miss a date we are contracted to hit", which is either an admission that the scope does not fit the window or a sign the file was never checked. Most contract schedule specifications reject it outright, and DCMA treats any negative total float as a defect requiring a documented recovery position. There is no acceptable quantity on a baseline.

Mid-execution is where the counterargument lives. A live programme that never shows negative float is suspicious in the other direction: real projects slip, and a file that always resolves to zero or better is usually being managed to look that way, through constraint softening or duration trims. Negative float appearing in an update is the schedule doing its job. The defect is not the number. The defect is a number with no recovery narrative attached, or the same number growing quietly for three updates in a row while the reports say "on track".

Why the tools disagree with each other

The same network can show negative float in one system and none in another, and knowing why saves an argument. In P6, whether Must Finish By participates at all, how retained logic versus progress override treats out-of-sequence work, and the "calculate float based on finish date" scheduling options each change the float column without changing a single date the site would recognise. Multiple float paths settings change which activities get flagged in a filter without altering the values. Two analysts opening the same XER with different scheduling options can genuinely both be right about what the file says, which is why any negative float finding should state the options it was calculated under.

Microsoft Project adds its own wrinkle: Deadlines. A deadline is not a constraint, it leaves the forward pass alone, but it caps the late dates, so a forecast past the deadline produces negative slack and a small red diamond warning. Schedulers who use deadlines instead of hard constraints are doing it right, and they should expect exactly this behaviour: the plan keeps telling the truth about when work will finish while the slack column reports the miss. The trap is the reverse assumption, an MSP file with clean slack proving nothing if nobody entered deadlines in the first place.

It spreads along the path. That tells you nothing about cause

Because float is a path property, every task on the chain between the driving work and the anchor shows the same negative value. Forty activities at minus twelve days is one problem, not forty problems, and the float column is completely silent about which activity created it. The slip might be a single procurement item at the head of the chain; every successor inherits the twelve days regardless of how well its own work is going. Sorting by total float and reading the worst offenders as the culprits is the most common misreading of a red schedule. The cause is found by walking the driving path backwards from the anchor to the first activity whose own performance, duration growth, or logic change introduced the delay, and that is an investigation, not a filter.

The recovery conversation has three exits

Once the anchor and cause are known, there are only three honest moves:

• Absorb it. Re-sequence, overlap, resource, or crash the remaining work so the forecast comes back inside the anchor. This is real recovery and it costs something: money, risk, or production-rate assumptions that need a name against them. Duration cuts with no method behind them are not absorption, they are cosmetics.
• Relieve it. Move the constraint, because the commitment itself has moved: an extension of time, a renegotiated access date, a milestone formally re-baselined. Legitimate only when the paper exists. Moving the constraint because the number was embarrassing is covered below.
• Accept and report it. Sometimes the plain answer is that the date will be missed, recovery is uneconomic, and the schedule should carry the negative float openly while the commercial consequences are managed. This is an unpopular exit and frequently the correct one.

Who owns it

The split is clean. The scheduler owns detection and honesty: negative float is found, traced to its anchor and cause, and reported with the scheduling options stated. The project manager owns the decision: which of the three exits to take, what the recovery costs, what gets escalated. A scheduler who picks the exit unilaterally has exceeded the brief. A PM who shoots the messenger has guaranteed the next miss arrives unreported.

And one move sits outside the professional pale entirely: making negative float disappear by softening the constraint that measures it. Swapping Mandatory Finish for As Late As Possible, deleting a deadline, quietly sliding Must Finish By to the right. The commitment has not moved; only the instrument reporting the miss has been disconnected. Whoever finds it later, and in a compare between updates someone always does, will reasonably treat every other number in the file as suspect from that point on.

Reading negative float in someone else's programme

Reviewing a file you did not build, run the questions in this order. What are the scheduling options, and is a project must-finish date driving the backward pass? List every constraint harder than Start No Earlier Than and ask which ones correspond to a real external obligation. Then group the negative float: contiguous values along a path point to one anchor and one cause, scattered unrelated pockets point to constraint litter. Ask when it first appeared, because the update where minus three became minus nine is worth more to the review than the current value. And check the previous update for constraints that existed then and do not exist now. A programme whose negative float vanished between updates without an approved change is telling you where to look next.