Why project schedules slip (and what the data actually shows)
Most schedule slippage comes from a small set of structural problems in the file. Missing logic ties, hard constraints, and open-ended tasks are predictable. Here is how to find them before they cause delays.
Project managers talk about schedule slippage as if it sneaks up on them. It usually does not. Most delays are predictable from the structure of the schedule file itself, often weeks or months before the first missed task. The file contains the evidence. Most teams just never look at it.
What causes most schedule slippage?
Schedule slippage comes from two places: execution problems (things take longer than planned, resources are unavailable, scope changes) and structural problems in the schedule itself. Execution problems are hard to predict. Structural problems are not.
The structural problems that most reliably produce late projects include: missing logic ties (tasks with no predecessors or successors), hard constraints that override the network, tasks with unrealistically long durations, and schedules where the critical path does not exist or is broken. These are measurable before the project starts.
Why missing logic ties cause delays
A task with no predecessor is disconnected from the network. It floats independently of everything around it. When you update progress elsewhere in the schedule, that task does not move. It stays in place with artificially inflated float, giving the impression that there is more slack than there is.
The DCMA standard flags this problem when more than 5% of tasks are missing a predecessor or successor. In practice, even a 3% missing-logic rate on a 500-task schedule means 15 tasks that cannot be managed. Those are 15 places where delays do not propagate and float is unreliable.
Why hard constraints produce negative float
A hard constraint (Start No Earlier Than, Must Finish On, etc.) tells the scheduling engine to ignore logic. When a task has a Must Finish On constraint that conflicts with the sequence of work before it, the result is negative total float. Negative float means the schedule already predicts a late finish, mathematically, before a single task starts.
This is why the DCMA assessment treats negative float as a zero-tolerance failure. Any negative float means the schedule predicts failure. The fix is always upstream: find the constraint, ask whether it is a real external requirement or an artifact of how the schedule was built, and remove or replace it with logic.
Why task duration matters for detection
A 90-day task in a 12-month project cannot be managed. You cannot measure progress on it accurately. By the time the task is clearly late, you have already lost most of the buffer that could have recovered the schedule. The DCMA standard caps task duration at 44 working days. Any task longer than that is a measurement problem waiting to become a schedule problem.
Decomposing long tasks into shorter work packages does not change the total duration of the project. It changes how early you can see that something is going wrong.
How to find these problems before they cause delays
All of the problems above are detectable before the project starts. You can run the DCMA checks manually in Microsoft Project, or you can use a tool that automates the process. The key metrics to check are:
- Missing predecessor/successor rate (target: below 5%)
- Hard constraint rate (target: below 5%)
- Tasks with negative total float (target: zero)
- Tasks with duration above 44 working days (target: below 5%)
- Whether a valid critical path exists (target: yes)
- Critical Path Length Index (target: 0.95 or above)
A schedule that passes these checks is not guaranteed to finish on time. But a schedule that fails them is structurally compromised and will produce unreliable float, unreliable finish dates, and unreliable progress reports.
Frequently asked questions
Can a schedule pass all the DCMA checks and still finish late?
Yes. The checks identify structural problems, not execution problems. A structurally sound schedule can still be delayed by resource unavailability, scope changes, or external events. What the checks prevent is avoidable delay: slippage that comes from a schedule that never accurately predicted the project in the first place.
How often should I run a schedule health check?
At a minimum: before submitting a schedule for review, at the start of each phase, and whenever the schedule has been significantly updated. On active projects, a monthly health check catches structural problems before they compound.
What is the single most important check to run?
Negative float. If any task has negative total float, the schedule predicts a late finish. That is the most urgent problem because it means the end date is already impossible given the current logic and constraints. Fix that first, then the constraint rate, then the logic gaps.