What is DCMA 14-Point Schedule Analysis?

If you work on defense, federal, or large capital programs, you have almost certainly heard a reviewer ask for a DCMA 14-Point assessment. The phrase refers to the Defense Contract Management Agency’s schedule assessment guidance in PAM 200.1—a structured set of tests that ask whether a network schedule is usable for management, not merely whether it looks complete in a Gantt chart.

This guide explains what the assessment is, what the checks cover at a practical level, and how teams automate the same review with a stateless API.

Why DCMA 14-Point exists

Schedules fail reviews for predictable reasons: missing logic, excessive constraints, broken critical paths, optimistic baselines, and progress that does not match the network. DCMA’s 14-point framework turns those failure modes into measurable checks with thresholds reviewers can cite.

Compared with a single “health score,” the 14-point assessment is deliberately checklist-oriented:

Style	What you get
Composite health score	One 0–100 number plus weighted diagnostics
DCMA 14-Point	Per-check pass/fail (and detail) against PAM 200.1-style criteria

Both are useful. Health scoring is excellent for triage and product UX. DCMA 14-Point is what many compliance and surveillance conversations still expect on paper.

What the 14 checks cover (practitioner view)

Exact wording and thresholds live in DCMA PAM 200.1 and your contract’s data requirements. In practice, reviewers group the checks into a few themes:

Network logic and structure

• Missing predecessors / successors — open ends that hide true path length
• Relationship quality — overuse of SS/FF/SF or lag that masks real finish-to-start handoffs
• High duration / high float — activities that are too coarse or too unconstrained to manage

Constraints and hard dates

• Hard constraints that pin dates and defeat float analysis
• Leads/lags used as a substitute for real logic

Critical path and performance indices

• Critical path test — does a delay on the critical path move the finish?
• CPLI (Critical Path Length Index) — remaining critical path length vs. time to target finish
• BEI (Baseline Execution Index) — baseline tasks completed vs. tasks that should have finished by the status date

Baseline and progress integrity

• Baseline presence and consistency for execution measurement
• Invalid dates / out-of-sequence progress that break earned-schedule style reasoning

For a full automated mapping of checks to API fields, see the DCMA 14-Point API reference and standards coverage.

Worked example: a three-task chain under review

Consider a tiny schedule a reviewer might still reject:

ID	Name	Duration (days)	Predecessors	Baseline finish	% complete
T1	Requirements	10	—	2026-01-16	100
T2	Design	15	T1	2026-02-06	60
T3	Development	30	T2	2026-03-13	0

Even this chain can fail DCMA-style checks if:

• There is no status date, so BEI cannot be evaluated
• Target finish is missing, so CPLI cannot be computed
• Summary/LOE tasks are mixed into topology metrics without exclusion
• Baseline finishes lag actual plan without explanation

A realistic review package always includes status date, baseline dates, and clear start/finish milestones.

Running DCMA 14-Point with Bellator

Bellator’s Track A APIs are stateless: you send the schedule (or import XER/MPP first), and you get structured results without storing the file.

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 '{
    "tasks": [
      {
        "id": "T1",
        "name": "Requirements",
        "duration_days": 10,
        "predecessors": [],
        "planned_start": "2026-01-05",
        "planned_finish": "2026-01-16",
        "baseline_start": "2026-01-05",
        "baseline_finish": "2026-01-16",
        "percent_complete": 100
      },
      {
        "id": "T2",
        "name": "Design",
        "duration_days": 15,
        "predecessors": ["T1"],
        "planned_start": "2026-01-19",
        "planned_finish": "2026-02-06",
        "baseline_start": "2026-01-19",
        "baseline_finish": "2026-02-06",
        "percent_complete": 60
      },
      {
        "id": "T3",
        "name": "Development",
        "duration_days": 30,
        "predecessors": ["T2"],
        "planned_start": "2026-02-09",
        "planned_finish": "2026-03-20",
        "baseline_start": "2026-02-09",
        "baseline_finish": "2026-03-13",
        "percent_complete": 0
      }
    ],
    "start_task_ids": ["T1"],
    "finish_task_ids": ["T3"],
    "status_date": "2026-02-15"
  }'

The response includes pass/fail (and detail) for each check—ready for a QA dashboard, PDF narrative, or CI gate on schedule submissions.

Tier note: Full DCMA 14-Point is a Health scored check at POST /api/v1/health/dcma-14-point (Starter and above). It is not a Forensics path. Tier 1 health scoring still surfaces several DCMA-aligned diagnostics for free-tier triage. Retired POST /api/v1/forensics/dcma-14-point is a 308 only.

How this differs from GAO and AACE

Framework	Emphasis
DCMA PAM 200.1	Checklist thresholds for schedule integrity
GAO Schedule Assessment Guide	Ten best practices for credible schedules
AACE RPs (e.g. 29R-03, 92R-19)	Forensic methods and health metrics for claims and controls

Bellator maps algorithms to these standards explicitly so results remain citable in reviews and disputes. See Standards for current coverage by tier.

Practical workflow for teams

1. Import P6 XER or MS Project XML → normalized JSON (Import guide).
2. Triage with health score for a fast 0–100 read.
3. Assess with DCMA 14-Point before customer or government submission.
4. Drill down on failed checks (logic audit, baseline compare, delay analysis) as needed.
5. Re-run after repairs—stateless APIs make regression checks cheap.

Common misconceptions

• “Passing DCMA means the project will finish on time.” No. It means the model is structurally sound enough to manage. Execution risk still needs resources, risk analysis, and change control.
• “One failed check always fails the program.” Contracts and reviewers differ. Treat the checklist as a risk register for the schedule model, then prioritize fixes that unblock critical path credibility.
• “Summaries and LOE should count like production tasks.” Topology metrics should exclude LOE/summary/hammock activities. Bellator does this by design when task_type (or import classification) is present.

Next steps

• Fix the findings that show up most often: Common DCMA findings and how to fix them
• Learn the triage score first: How to read a CPM schedule health score
• End-to-end API path: From health score to DCMA in one integration
• Try it live in the Playground (no signup required for demo scope)

Sources and further reading

• Defense Contract Management Agency — Schedule Assessment (PAM 200.1) 14-Point guidance
• Bellator standards coverage
• DCMA 14-Point API
• Task schema guide (baseline, status date, CPLI/BEI fields)