Planning, P6 and 4D
DCMA 14-point check: how to get a P6 baseline accepted
A baseline programme is the reference every later update, delay claim and payment milestone is measured against. When the employer's consultant rejects it, the contractor works for months without an agreed reference. Most rejections come from the same handful of weaknesses, and a standard set of tests exists to find them early: the DCMA 14-point assessment.
What the DCMA 14-point assessment is
The Defense Contract Management Agency (DCMA) is a US Department of Defense body. Its 14-point assessment is a list of checks used to judge whether a schedule is well built. The checks are mechanical: each one counts activities or relationships and compares the result with a threshold.
Two clarifications matter for projects in Saudi Arabia. First, the assessment is not a Saudi requirement and is not part of FIDIC. Second, some employers and project management consultants cite it in their programming specification, and many planners use it as a neutral quality benchmark. If your contract names a different method, follow the contract. If it says nothing, running the 14 points before you submit is still a sensible gate.
The 14 checks and the thresholds to aim for
The thresholds below follow the published descriptions from Deltek Acumen and the ForProject checklist. Most tests look only at incomplete activities with a duration above zero.
| # | Check | What it looks for | Aim for |
|---|---|---|---|
| 1 | Logic | Activities missing a predecessor, a successor or both | 5% or less |
| 2 | Leads | Relationships with negative lag | 0% |
| 3 | Lags | Relationships with positive lag | 5% or less |
| 4 | Relationship types | Share of finish-to-start links | 90% or more |
| 5 | Hard constraints | Must-start, must-finish and similar date constraints | 5% or less |
| 6 | High float | Total float above 44 working days | 5% or less |
| 7 | Negative float | Total float below zero | 0% |
| 8 | High duration | Duration above 44 working days | 5% or less |
| 9 | Invalid dates | Actuals after the status date, forecasts before it | 0% |
| 10 | Resources | Activities with no hours or cost where resources are loaded | 0% |
| 11 | Missed tasks | Activities due by the status date that finished late | 5% or less |
| 12 | Critical path test | Does a delay on the critical path move the finish date? | Pass |
| 13 | CPLI | (Critical path length + total float) / critical path length | 1.00 or more |
| 14 | BEI | Activities completed against activities due | 1.00 or more |
Checks 11, 13 and 14 compare progress with a baseline. On a first baseline submission there is no progress, so these three become useful from the first update onward.
Why baselines fail, and what to do about it
Open ends. Activities with no successor are the most common finding. A missing successor means the activity can slip with no effect on completion, which is almost never true. Tie every activity to a successor, and make sure the last activities link to the completion milestone.
Lags used as hidden activities. A 21-day lag after a pour is really curing, formwork stripping or a test. Replace it with a named activity so people can see it, resource it and update it. Keep the genuine lags, such as a specified curing time, but state the reason.
Start-to-start chains. Overlapping trades with start-to-start links and lags is realistic, but a schedule full of them hides the real sequence and breaks check 4. Use them where the work genuinely overlaps and use finish-to-start elsewhere.
Constraints that force dates. A must-finish-on date makes the schedule show the employer's date whatever the logic says. Use hard constraints only for dates the contract imposes, such as an access date. Model the rest through logic.
Long activities. An activity over 44 working days is hard to update and hides progress. Split it by level, zone or trade so you can measure percent complete honestly. The same rule keeps float meaningful.
Float that does not make sense. Large positive float on many activities usually means missing links. Large negative float means the logic does not reach the contract completion date. Neither can be left unexplained in a submission.
A pre-submission routine
- Fix the calendars first. Make sure the project calendar reflects the working week, public holidays and the weather or Ramadan assumptions you will defend. The 44-day tests count working days, so the calendar changes the result.
- Clean the logic in P6. Use filters or layouts to list activities with no predecessor or successor, constraints and long durations. Fix links before you test float.
- Run the 14 points. Use your scheduling tool's report, or a dedicated checker, and export the results.
- Do the critical path test. Insert a large delay on a critical activity, confirm the finish date moves by the same amount, then remove it. If it does not, the logic is broken somewhere along the path.
- Review the critical path with the site team. Ask whether the longest path really is the longest path. A programme can score well and still describe a build that nobody believes.
- Write the narrative. Include the sequence, the key assumptions, any constraints you kept and why, and the 14-point result with explanations for anything outside the threshold.
What the 14 points do not tell you
A schedule can pass every test and still be wrong. The checks measure construction of the schedule, not the realism of the durations, the resource availability or the procurement lead times. They can also be gamed: a planner can reach 90% finish-to-start links by splitting work into meaningless pieces.
Use the results as a reason to talk, not as a score. If a number falls outside its threshold, write one line explaining why, such as a contractual access date driving a hard constraint. Reviewers accept explained exceptions much more readily than silent ones.
What to send with the submission
Send the native file (XER for Primavera P6) and a PDF print. Add the narrative, the calendar list and the check results. Make sure activity IDs and WBS codes match the contract's coding requirements, if it has them, because reviewers often start by comparing the structure.
If you want an independent check before submitting, send us the file and the programme clause from your contract. We will run the checks, mark the findings and propose fixes.