The 14 checks
The DCMA 14-point assessment screens a schedule for the defects that make its dates unreliable: missing logic, leads and lags, constraints, float and duration outliers, dates that make no sense, progress against the baseline. The server computes every check on the open activities of the last P6 schedule run (F9), with level of effort and WBS summary activities left out, as the DCMA guidance intends.
| Check | What it counts | Default threshold |
|---|---|---|
| 1. Logic | Open activities without a predecessor or a successor | at most 5 % |
| 2. Leads | Links with a negative lag | 0 % |
| 3. Lags | Links with a positive lag | at most 5 % |
| 4. Relationship types | Finish-to-start share of the links | at least 90 % |
| 5. Hard constraints | Mandatory and other hard constraints | at most 5 % |
| 6. High float | Total float over 44 working days | at most 5 % |
| 7. Negative float | Total float below zero | 0 % |
| 8. High duration | Remaining duration over 44 working days | at most 5 % |
| 9. Invalid dates | Forecast dates before, or actual dates after, the data date | 0 % |
| 10. Resources | Activities with duration and no resource | report only |
| 11. Missed tasks | Baseline activities due by the data date and not finished on time | at most 5 % |
| 12. Critical path test | Does a delay on the critical path move the finish as much? | pass |
| 13. CPLI | Critical path length index | at least 0.95 |
| 14. BEI | Baseline execution index | at least 0.95 |
Before you start
- Install the server and select your P6 database in its Settings window (install steps), or load XER files in XER-only mode.
- Press F9 in P6 first: the check reads the dates and float of the last schedule run. Reading does not need P6 to be closed.
- Missed tasks and BEI need a baseline. The server takes the project baseline set in P6, or the one you name.
Run the check
Run a DCMA 14-point health check on DEMO-SS225 and explain each failed check in one line.
The assistant calls p6_health_check(project="DEMO-SS225"). The server returns, per check, the count, the denominator, the percentage, the threshold, pass or fail and a sample of 15 activities or links, plus a score and a weighted grade. On the demo project at its data date of 26 October 2026:
| Check | Result | Threshold | Status |
|---|---|---|---|
| Logic | 0 of 75 (0 %) | at most 5 % | Pass |
| Leads | 0 of 145 | 0 % | Pass |
| Lags | 15 of 145 (10.3 %) | at most 5 % | Fail |
| Relationship types (FS) | 130 of 145 (89.7 %) | at least 90 % | Fail |
| Hard constraints | 0 of 75 | at most 5 % | Pass |
| High float | 28 of 75 (37.3 %) | at most 5 % | Fail |
| Negative float | 37 of 75 (49.3 %) | 0 % | Fail |
| High duration | 2 of 67 (3.0 %) | at most 5 % | Pass |
| Invalid dates | 0 of 214 | 0 % | Pass |
| Resources | 13 of 67 (19.4 %) | report only | Info |
| Missed tasks | 134 of 149 (89.9 %) | at most 5 % | Fail |
| Critical path test | finish moves | pass | Pass |
| CPLI | 0.85 | at least 0.95 | Fail |
| BEI | 0.93 | at least 0.95 | Fail |
Score: 6 checks passed and 7 failed of the 13 evaluated (46.2 %); weighted score 70.5 points, grade C. The weighted score also counts logic density (links per open activity, here 1.93 against a minimum of 1.5), which is outside the DCMA 14 and outside the score.
A useful reading of this result: negative float on half of the open work and a CPLI of 0.85 say the same thing, the forecast finish is beyond the must finish by date; the many missed tasks say it did not happen suddenly. The lags and the non-FS links are the first logic questions to ask the scheduler.
Drill into a failed check
Each check can be paged in full, in the same snapshot, with the activities or links behind it.
Which open activities fail the high float check on DEMO-SS225? List them as Activity ID - name with their total float, largest first.
The assistant calls p6_health_check(project="DEMO-SS225", check="high_float") and pages the 28 activities. The same works for lags, fs_links, negative_float, missed_tasks and the other checks. For the logic check, ask for the dangling ends too: p6_dangling lists open starts and open finishes and suggests the link that would close each one.
The test delays the most critical open activity by 100 working days in the server's CPM engine and checks that the finish moves as much. It runs only when that engine reproduces P6's own dates on the project. Ask "validate the CPM engine on DEMO-SS225" to see the match rate from p6_cpm_validate.
Use your own thresholds
P6 Professional stores schedule check settings per project. When they exist, the server uses them instead of the DCMA defaults, including the checks you turned off, and says so in threshold_source. You can also override a threshold for one run:
Run the health check on DEMO-SS225 with a lags threshold of 10 % and high float above 30 days.
That becomes thresholds={"lags": 10} and high_float_days=30. Nothing is stored: the next run is back to the project's settings.
Follow the trend
Every full run saves a snapshot next to the server's logs. After the next update, ask:
Compare today's DCMA check of DEMO-SS225 with the previous one. Which checks got worse, and which activities are new in them?
p6_health_check_compare compares the totals, every check value and the activities or links that entered or left each check. When the CPM engine version changed between two runs, it says so.
What the check does not tell you
- A schedule can pass all 14 checks and still be wrong: durations, sequence and resource assumptions need a planner's review.
- Thresholds are screening values, not contract requirements, unless your contract says so.
- The check reads the last F9. If someone edited the project since, the result says the schedule is stale.