The five scheduling sins the DCMA check catches most

Run the 14-point assessment on enough programmes and the same handful of failures turn up again and again — not because planners are incompetent, but because each sin is the path of least resistance under pressure. Here are the five we see most, why good people commit them, and what each one quietly does to your float.

A confession before we start: every planner reading this has committed at least three of these, and so have we. The point is not purity. The point is that each of these shortcuts disables a specific part of the CPM machinery, and the damage compounds in ways that are invisible until the month you need the schedule to tell you something true.

Sin 1 · Open ends — the bar chart in disguise

An open end is an incomplete activity with no predecessor, no successor, or both. In P6 it looks like nothing at all — the bar sits exactly where you left it, which is precisely the problem. An activity with no predecessor starts whenever the project starts, regardless of what actually has to happen first. An activity with no successor can slip for a year without moving the completion date one day.

Why do planners do it? Mostly speed. Building logic is the slow, unglamorous part of scheduling, and when the deadline for issuing the programme is Friday, wiring the last 200 activities is the task that gets sacrificed. Sometimes it is uncertainty dressed up as pragmatism — "we don't know what drives that yet, leave it floating." The schedule gets issued, looks complete, and nobody notices that a third of the network is decorative.

What it does: open ends sever the paths along which delay propagates, so the engine reports float that does not exist and a critical path with holes in it. The programme becomes a bar chart wearing a CPM costume — which is exactly the phrase a forensic analyst will use about it later, in writing.

The fix is unglamorous: wire everything except the project start and finish milestones, and make the open-ends report part of every update cycle so new ones get repaired in the revision that created them. The DCMA tripwire is 5% — in our experience, a well-kept programme sits under 1%.

Sin 2 · Lag abuse — invisible durations nobody owns

A lag is a delay baked into a relationship: "B starts ten days after A finishes." Used sparingly for genuine physical waits — concrete curing, paint drying — it is defensible. The abuse pattern is using lags as a substitute for planning: long SS+lag chains that compress a sequence of real, resourced work into a single invisible number on a relationship line.

Why planners do it: lags are fast, and they make overlap easy to draw. Turning "second fix follows first fix, roughly two weeks behind" into SS+10d takes four seconds; modelling it properly takes thought. Client pressure plays a part too — lags are a quiet way to shorten a programme without visibly shortening any activity.

What it does: a lag has no resources, no owner, no progress, and no presence on the Gantt chart. It cannot be statused, so it never reflects reality — the real gap grows or shrinks and the model never finds out. Worse, lag durations follow a calendar you probably haven't thought about, which can silently change the answer (we cover that nasty trap in our deep dive on leads, lags and logic density). The fix: any lag representing real work or a real physical process becomes an activity with a name and an owner. The DCMA threshold is lags on no more than 5% of relationships — and zero leads, full stop.

Sin 3 · Constraint pinning — forcing the answer

Hard constraints — Must-Finish-On, Mandatory Start, and friends — override logic. Each one tells the engine: whatever the network says, put this date here. Pin enough of them and the schedule stops calculating and starts transcribing your wishes.

Why planners do it: usually because someone senior wants a date the network refuses to produce. The Must-Finish-On constraint on the completion milestone is the classic move — it forces the contract date onto the printout, and the inconvenient arithmetic goes somewhere the dashboard doesn't look: negative float.

What it does: beyond hiding slip, a pinned schedule fails the critical path test — inject a delay and the completion date doesn't move, which means the programme is structurally incapable of demonstrating the effect of any delay event. For a contractor heading into a time claim, that is self-inflicted disarmament. The fix: strip hard constraints down to the handful with genuine external justification, use soft constraints (start-no-earlier-than) for things like permits and access dates, and let the completion date be an output, not an input.

Sin 4 · The six-month activity — progress hides in long bars

The DCMA high-duration check flags incomplete activities longer than 44 working days. The reasoning is about honesty of measurement: nobody can status "Install MEP services — 130 days" meaningfully. Is it 40% complete? 55%? The number is a negotiation, not a measurement, and a long bar can sit at "on track" for months while the work inside it quietly falls behind.

Why planners do it: decomposing work is effort, and early in a project the detail genuinely may not exist yet. That is forgivable at first issue. It is not forgivable in month nine, when the long bars are precisely where the slippage is hiding — long durations and optimistic percent-complete are the natural habitat of bad news.

The fix is decomposition with a rolling wave: near-term work broken to statusable chunks (one to two reporting periods), far-term work allowed to stay coarser until it approaches. The act of breaking a long bar apart almost always exposes missing logic too, which is a free bonus repair.

Sin 5 · The unstatused baseline — fiction by neglect

The final sin is not in the network at all; it is in the process around it. A baseline that is never compared against, updates that roll dates forward without recording what actually happened, actual dates typed in weeks later from memory — the result is a programme that technically exists but describes no project on Earth.

This is the sin the performance checks exist to expose. Missed tasks asks: of the activities that should have finished by now, what fraction met their baseline dates? Above 5% and the baseline has stopped describing the project. The Baseline Execution Index (BEI) measures throughput — tasks completed versus tasks planned to complete — with a tripwire at 0.95. A BEI of 0.80 means the project completes 80 tasks for every 100 promised, accumulating a backlog the completion date pretends not to know about.

Why teams do it: statusing is tedious, the planner is overloaded, and — let's be honest — an unstatused programme never delivers bad news. But this is the sin with the worst exchange rate. Sins one to four damage the forecast; sin five destroys the record. When the dispute comes, the contemporaneous updates are the evidence, and an unmaintained record cannot be reconstructed at any reasonable price. We made this argument at length in our piece on schedule quality: claims are won by whoever kept the more credible record.

The sins at a glance

Notice how the five sins between them trip ten of the fourteen checks. That is not a coincidence — the assessment was designed by people who had seen the same five shortcuts a thousand times and built a tripwire for each.