Common DCMA Findings and How to Fix Them

Passing a DCMA 14-Point assessment is less about memorizing PAM 200.1 paragraph numbers and more about eliminating a short list of recurring defects. This field guide maps frequent findings to practical repairs you can make in Primavera P6 or Microsoft Project before you re-run POST /api/v1/health/dcma-14-point.

If you need the conceptual overview first, read What is DCMA 14-Point Schedule Analysis?.

Triage order (do not skip)

1. Structure — open ends, circles, invalid dates
2. Classification — LOE / summary / hammock excluded from topology
3. Constraints & lag — remove artificial criticality
4. Duration & float quality — decompose monsters; justify high float
5. Baseline & targets — enable BEI / CPLI
6. Critical path proof — does a push on CP move finish?

Finding: missing predecessors or successors

What it means: Activities (often true work, not milestones) sit with an open end, so path length and float are fiction.

How to confirm: Filter activities with no pred/succ in P6; compare to API open-end lists.

Fix:

• Tie every real work activity into the network with meaningful FS (default) logic
• Use start/finish milestones deliberately—not as a way to hide open ends
• Avoid “hanging” commissioning tasks waiting on undocumented external deps; model the external milestone

Example repair table:

Activity	Before	After
Cable pull	No successor	FS to “Torque & test”
Torque & test	No predecessor	FS from cable pull
Area complete milestone	Orphan	SS/FS from last work + finish milestone set

Finding: excessive soft logic or lag

What it means: SS/FF/SF chains and large lags encode calendar wishes instead of handoffs.

Fix:

• Prefer FS with realistic durations
• Replace lag with an explicit activity (“cure time,” “submittal review”) when the lag represents work or wait that management should see
• Document remaining lags in the basis of schedule

Finding: too many hard constraints

What it means: Must-start/must-finish constraints pin dates, defeating float and critical path tests.

Fix:

• Convert hard constraints to deadlines or finish milestones where contractually honest
• Keep true contractual constraints; remove “scheduling convenience” constraints
• Re-run CPM and verify the critical path still matches field reality

Finding: high duration activities

What it means: Multi-month bars hide internal logic and make progress measurement coarse.

Fix:

• Decompose into work packages that match how the job is supervised
• Keep planning packages explicitly classified (task_type / prefixes) so they do not pollute detailed topology metrics

Finding: high total float / “nothing is urgent”

What it means: Either the network is disconnected from the finish milestone, or the finish is unconstrained.

Fix:

• Ensure a complete path into the contractual finish milestone
• Remove dangling side networks
• Confirm calendars on the finish path

Finding: critical path test failure

What it means: Delaying a declared critical activity does not move project finish—your “critical path” is not critical.

Fix:

• Search for constraints, actuals, or level-of-effort that pin finish
• Verify the finish milestone is driven by logic, not a constraint alone
• Exclude LOE from CP claims

Finding: CPLI cannot pass (or cannot compute)

Critical Path Length Index compares remaining critical path length to time remaining until target finish.

Typical root causes:

• Missing target_finish_date (or equivalent) in the analysis payload
• Status date in the wrong place
• Critical path not credible (fix CP test first)

Fix: Supply the management target finish, correct status date, and a valid CP.

Finding: BEI failure

Baseline Execution Index asks whether work that should have finished per baseline is actually complete by the status date.

Typical root causes:

• Baseline not exported / not mapped on tasks
• Status date missing
• Progress not updated (percent_complete / actual finishes)

Fix:

1. Restore baseline dates on activities
2. Update progress honestly
3. Re-import and re-run DCMA

See task schema — baseline fields.

Finding: false failures from LOE and summaries

What it means: Reviews count open ends on summaries or treat LOE as missing logic.

Fix:

• Classify during import (auto_classify_task_types, prefix rules)
• Confirm task_type on normalized JSON
• Rely on engines that exclude LOE/summary/hammock from topology stats (Bellator default when classified)

Batch repair playbook

for each DCMA run:
  export findings → CSV
  fix top 20 structural items in P6
  re-export XER
  import → normalized
  POST /api/v1/health/dcma-14-point
  diff failed checks vs previous run
stop when failed checks are only accepted contractual exceptions

Automate the middle with the XER import guide and API walkthrough.

Minimal re-score snippet

# After import, re-check the package (payload abbreviated)
curl -X POST "https://api.bellatorsi.com/api/v1/health/dcma-14-point" \
  -H "Content-Type: application/json" \
  -H "x-api-key: YOUR_API_KEY" \
  -d @dcma-payload.json

Keep dcma-payload.json in version control next to the XER when your process allows—schedule quality becomes reviewable like code.

Next steps

• DCMA Deep Dive part 1 — overview
• Health score triage
• Playground DCMA sample

Sources

• DCMA PAM 200.1 — 14-Point schedule assessment checks and intent
• GAO Schedule Assessment Guide — best practices that overlap several DCMA failure modes
• Bellator DCMA 14-Point API
• Standards coverage