Why did the project slip when the critical path was green the whole time? Usually because the critical path was only half the story. Tasks sitting a few days off zero-float can absorb one small delay and become the new path that decides your finish date, and nobody sees it happen. By the time the Gantt chart turns red, you've already lost the week you needed to react.

The audit worth running isn't "are we on the critical path?" It's a series of decisions about where to spend your attention, what to trust in the schedule, and when to step in. Each section below frames one of those decisions.

Decide What Counts as Near-Critical Before the Project Starts

The first decision is a definition, and it's easier to make when nothing is on fire. Tasks with zero float sit on the critical path; tasks with very low float are near-critical and need closer monitoring as the project runs. The question is where you draw "very low" for this engagement.

Pick the threshold up front and write it into your schedule health rules. Two defensible ways to do it:

  • A fixed-day rule. Anything within, say, five or ten working days of the critical path counts as near-critical. Simple, easy to filter in any tool, and it holds up on shorter engagements.
  • A percentage rule. Anything with float that is a small fraction of remaining project duration. Scales more sensibly on long programs where ten days is nothing.

Either works. What matters is that the threshold exists before the project is halfway through, so status reviews look at the same set of tasks every week instead of re-litigating what "close" means.

Decide Whether You Trust the Float You See

Float quantity is easy. Float quality is where projects get killed. A task with twelve days of slack looks safe until you notice the twelve days depend on a vendor commitment nobody validated, a duration estimate someone typed in during planning six months ago, or a predecessor that finishes "on paper" but hasn't actually been signed off.

Before you trust a float number, ask three questions about it:

  1. Where did the duration come from? An estimate from the person doing the work is worth more than a placeholder inherited from the last project.
  2. What assumptions is it resting on? Vendor lead times, environment availability, and regulatory sign-offs are the usual suspects, and the usual sources of surprise.
  3. How stale is the logic? Dependencies drawn in month one may not reflect how the work is being sequenced now.

This argument runs through an episode of the an episode of the ProjectManager.co podcast on the Critical Path Is Not the Most Important Path on Your Project podcast on the Critical Path Is Not the Most Important Path on Your Project: float built on optimistic estimates behaves less like a cushion and more like a countdown timer. Auditing float quality means asking what the number is made of, not how big it is.

Decide How You'll Measure Float Consumption

The second decision is how to watch float move once the project is running. A snapshot each Friday tells you what float looks like today. It says nothing about how fast you're burning through it.

Track the trend, not the value. If a chain started the month with fifteen days of float and now sits at six, that path is spending float faster than the calendar is spending itself, a leading signal that a near-critical chain is turning into the critical one. Compare consumed float against expected consumption at the current stage and you get an early warning instead of a post-mortem.

One more piece of arithmetic worth remembering: float on a chain is shared, not per-task. When several activities sit on the same path, they draw from the same pool, so one delay early in the chain eats the cushion for everything downstream. A task manager who thinks they have "a week of slack" may have none left by the time the work reaches them.

Run a Real Schedule Health Check, Not a Vibe Check

Most status meetings audit progress. Fewer audit the schedule itself. The DCMA 14-Point Assessment is a widely used reference here, a set of structural checks on logic, constraints, float, and duration that surfaces the kinds of problems humans miss when they're staring at a Gantt bar instead of the network behind it.

You don't need all fourteen checks to get value from the exercise. A short version worth running monthly:

  • Missing logic. Tasks with no predecessor or successor float freely in ways that mask real risk.
  • Hard constraints. "Must finish on" dates override the network math and hide slippage behind fixed pins.
  • High-float outliers. Activities with wildly more float than the rest of the plan usually mean broken logic, not spare time.
  • Long durations. Any task longer than a reporting period is a place for slippage to hide between status updates.
  • Negative float. If it's showing anywhere, the deadline has already been missed by the math, whether or not anyone has said so.

Auditing near-critical work isn't about adding another status color; it's about buying back the reaction time that late escalation gives away. Projects that finish on schedule tend to be the ones where somebody was watching the second-most-important path all along, long before the dashboard had anything to say about it.