Learning Center
The Hidden Bugs in Your P6 Schedule
A P6 schedule can open cleanly, print a tidy Gantt chart, and still be quietly wrong underneath. Here are five of the most common structural problems that hide in a schedule’s logic -- none of them loud enough to trigger an error message, all of them capable of undermining any conclusion drawn from the schedule later.
Why a Schedule Can Look Fine and Still Be Wrong
P6 will happily calculate dates, float, and a critical path for a schedule full of these problems -- it has no way of knowing that an activity’s missing predecessor was an oversight, or that a constraint was typed in to hit a target rather than reflect reality. The software isn’t checking the schedule’s honesty; it’s just doing the math on whatever logic it’s given. That’s exactly why these problems tend to survive a normal review and only surface once someone -- a scheduler, an owner, a forensic analyst -- goes looking for them specifically.
Five Problems Hiding in Plain Sight
1. Open Logic Gaps
An activity with no predecessor, no successor, or neither is floating free of the network's actual logic. On paper the schedule still looks complete -- every row has a duration and a bar on the Gantt chart -- but that activity's dates aren't really being driven by anything, and nothing downstream is really waiting on it either. It's one of the easiest problems to miss on a casual read-through, because nothing about it looks broken until you go looking for the connection that isn't there.
2. Hard Constraints Overriding the Network
A Mandatory Start or Mandatory Finish date tells the software to show that date no matter what the activity's predecessors actually do. That can be exactly what's needed for a handful of genuinely fixed events -- a permit expiration, a contractual milestone -- but scattered across dozens of ordinary activities, hard constraints quietly replace the schedule's logic with someone's typed-in opinion of when things should happen, which can mask real delay building up underneath.
3. Excessive Lag
Lag is time added to a relationship between two activities -- a positive number for real waiting time like concrete cure or inspection turnaround, a negative number (a "lead") that lets a successor start before its predecessor even finishes. A little lag with a documented reason is normal. Large or unexplained lag values are a common place for schedule duration to hide in plain sight, invisible on the activity bars themselves and easy to overlook unless someone checks the relationships directly.
4. Implausibly High Float
Total float is supposed to represent genuine scheduling flexibility -- how much an activity can slip before it affects the finish date. An activity showing months of float this early in a project, with nothing else obviously tied to it, is usually not that lucky. Far more often, it's the visible symptom of the same open logic gap described above: nothing is really constraining that activity, so the software reports enormous slack that doesn't reflect any real cushion in the actual work.
5. Out-of-Sequence Progress
This happens when an activity is reported as started, or partly complete, before its logical predecessor has actually finished -- work being marked done in an order the schedule's own logic says shouldn't be possible yet. It usually means either the field is genuinely working ahead of the planned sequence, or the logic linking those two activities was never right to begin with. Either way, it's a sign that the schedule's story and the project's real story have started to diverge.
A Small Example
Here’s a simplified five-activity slice of a loading-dock addition, as of a data date partway through construction. Two of the five problems above are visible in the table alone.
| Code | Activity | Pred. | Lag | Total Float | Flag |
|---|---|---|---|---|---|
| A | Mobilization | — | — | 0d | — |
| B | Foundation excavation & footings | A | — | 0d | — |
| C | Steel canopy erection | B | +20d | 0d | Excessive lag |
| D | Interior slab & MEP rough-in | — | — | 96d | Open logic gap / high float |
| E | Dock leveler installation (Mandatory Finish 11/14) | C | — | 0d | Hard constraint |
There’s a fifth problem this table can’t show on its own: suppose that as of the data date, C is reported 40% complete even though B -- the activity C logically depends on -- is only 80% complete and hasn’t finished. That’s out-of-sequence progress: work being reported in an order the schedule’s own logic says shouldn’t be possible yet.
These five checks are exactly the kind of thing the DCMA 14-point assessment was built to catch systematically, with a defined pass/fail threshold for each one. If this list has you wondering how many of these your own schedule might be hiding, The Complete DCMA 14-Point Assessment Explained walks through the full, systematic version of this check.
Spotting five of these by eye is manageable. Doing it across a real, multi-thousand-activity P6 schedule isn’t. Claims Digger runs the full DCMA 14-point assessment automatically against an uploaded schedule, surfacing exactly which activities are driving each of these problems -- logic gaps, constraints, lag, float, and out-of-sequence progress -- so you don’t have to hunt for them by hand. See how it works.
Frequently Asked Questions
- Are these problems specific to P6?
- No. Open logic gaps, hard constraints, excessive lag, implausible float, and out-of-sequence progress are structural issues that can show up in any critical-path-method scheduling tool. P6 is simply the most common target because of how widely it's used on larger construction and capital projects.
- Does having one of these problems mean the schedule is unreliable?
- Not automatically. A single open logic gap on a minor activity, or one reasonable hard constraint tied to a real contractual date, is common and not disqualifying on its own. What matters is how many of these show up, and whether they cluster around the activities or time period a specific conclusion -- like a delay claim -- depends on.
- How is this different from the DCMA 14-point assessment?
- This article is the plain-language overview: five of the most common problems, described conceptually. The DCMA 14-point assessment checks these same underlying issues -- plus several others -- with defined, numeric pass/fail thresholds for each one, run systematically across every activity in the schedule.
- Can these problems be fixed after they're found?
- Usually, yes. Open logic gaps get fixed by adding the missing predecessor or successor relationship; unnecessary hard constraints can often be converted to a softer constraint type or removed entirely; excessive lag can be replaced with an actual activity representing the waiting time. Negative float and out-of-sequence progress are different -- they're often signs of a real, current problem rather than a schedule-cleanup item.
Part of the Claims Digger Learning Center. Related reading: The Complete DCMA 14-Point Assessment Explained · Full glossary