Primavera P6 Schedule Health Check: 12 Checks Before You Submit a Baseline

A baseline programme is more than a bar chart. Once it is accepted it becomes the yardstick for progress, payment milestones, recovery planning and, if things go wrong, delay analysis. A baseline that carries hidden logic gaps or forced dates will keep generating problems for the life of the project.

This article gives a practical 12-point health check you can run on a native Primavera P6 file before it goes to the client, the PMC or the engineer. It uses the DCMA 14-point assessment as a reference framework, but it is deliberately broader: the DCMA metrics were written for a different industry and a different purpose, and a construction baseline also has to satisfy its own contract.

First, how to use the DCMA 14-point

The DCMA 14-point assessment is a set of schedule metrics developed by the US Defense Contract Management Agency. Vendors describe it as a "schedule health check" and the metrics as advisory guidelines rather than rigid rules. Mosaic Projects traces the last published version to section 4 of the DCMA Earned Value Management System Program Analysis Pamphlet (DCMA-EA PAM 200.1, 2012).

Two cautions apply before you adopt the numbers:

• It is a diagnostic, not a certificate. Commentary on the method is consistent that a failed metric is a signal to investigate, and that passing the checks does not show the schedule is sensible, realistic or achievable.
• Software implementations differ. There is no official certification of tools, and task counting rules (what is included in the denominator) are the biggest source of inconsistent results. State how you counted.

With that in mind, here are the twelve checks. Where a DCMA reference threshold exists, it is quoted from the Deltek metric descriptions.

The 12 checks

1. Logic completeness (open ends)

Every activity except the project start and finish should have at least one predecessor and one successor. Activities with no predecessor can start at the data date for no reason, and activities with no successor can slip without affecting anything. DCMA reference: incomplete tasks missing predecessor and/or successor links should be 5 percent or less. For a baseline, aim much lower and explain every exception.

In P6, filter for activities with no predecessors or no successors and review them one by one. Watch for summary tasks used as activities and milestones that were never linked.

2. Relationship types

Most links should be finish-to-start. DCMA reference: at least 90 percent finish-to-start. Start-to-start and finish-to-finish links are legitimate for overlapping work, but each one is a place where the true driver can be misread. Start-to-finish links are rare and usually a sign of a modelling shortcut; question every one.

3. Leads (negative lags)

Negative lags make a successor start before its predecessor finishes while pretending the relationship is finish-to-start. DCMA reference: ideally none. Be aware that this is a debated point. Mosaic notes that banning leads is not a universal scheduling principle, because overlaps of discrete work can justify them. A practical position: no leads without a written reason, and prefer splitting the predecessor activity so the overlap is explicit.

4. Lags

Lags are time without work or resources. DCMA reference: 5 percent or less of incomplete tasks. Acceptable examples are genuine technical waiting time (a curing period, for instance, ideally modelled as its own activity so it is visible). Unacceptable examples are lags used as placeholders for work that was never scheduled or to hold a date. Check which calendar each lag is measured in, because a lag counted on a different calendar from the activities either side can silently change the dates.

5. Constraints

Constraints override network logic. Hard constraints such as mandatory dates can force activities to appear on time even when predecessors say otherwise. DCMA reference: 5 percent or less of incomplete tasks using hard constraints. Confirm how your tool classifies "hard" before you report a figure.

Reasonable uses: a contractual completion date on the final milestone, a client-handover date, or a permit start. Unreasonable uses: pinning intermediate activities to dates so the schedule "looks right". If a constraint is there to represent a contract date, say so in the activity notes and use the least restrictive type that does the job.

6. Float: negative and excessive

Two separate tests:

• Negative float means the schedule cannot meet a constraint or target date. DCMA reference: none, and any negative float needs an explanation and corrective action plan. A baseline submitted with negative float is effectively a baseline that cannot meet its own contract dates.
• High float (reference: total float above 44 working days) usually indicates missing successors or logic that is too loose. Review the activities, do not just count them.

Also check which total float definition the project uses. P6 can compute total float from start float, finish float or the smallest of the two, which matters on activities that span different calendars.

7. Excessive duration

Long-duration activities hide logic and make progress measurement coarse. DCMA reference: baseline duration above 44 working days for activities in the detailed planning period, with no more than 5 percent of such tasks. In construction, the exceptions are real: long-lead procurement, approvals or rolling-wave work that is deliberately summarised. The check is whether each long activity is intentional. Where it is not, split it by floor, zone or trade.

8. Calendars

Calendars are the quiet source of many wrong dates. Confirm that:

• The project default calendar reflects the actual working week and public holidays for the site.
• Activity calendars match how the work is done (for example a 7-day calendar for continuous curing or a restricted calendar for noise-limited work).
• Seasonal or religious-period working hours are modelled if they apply to the project location.
• No unused or duplicate calendars are inherited from a template.

Calendar errors also distort float and the critical path, so fix them before judging the float results in check 6.

9. Critical path integrity

The critical path should be a continuous chain from the data date to the project finish, and it should make sense to the site team. Two practical tests:

• Longest Path versus total float. P6 lets you define critical activities as total float at or below a value, or as the Longest Path. Oracle describes Longest Path as the sequence of driving activities that determine the project end date. Use it, and compare it to what a float filter shows.
• The DCMA critical path test. Temporarily add a large delay to an activity on the critical path and check that the project finish moves by the same amount. If it does not, there is a break in the logic or a constraint absorbing the delay. Do this on a copy of the project, never on the baseline.

Also check the setting that labels open-ended activities as critical, as it changes what the critical filter returns.

10. Resource and cost loading

Where the contract or the client requires a resource-loaded or cost-loaded baseline, check that every activity with a duration above zero is loaded, that units and rates are consistent, and that the curves are plausible (for example, no huge spikes in a single month). DCMA reference: tasks with duration and no resources or cost should be none. If the baseline is intentionally not loaded, say so rather than leaving the field blank.

11. Dates and progress settings

On a baseline there should be no actual dates in the future and no forecast dates in the past (DCMA reference: none). Also confirm the data date. For updates, confirm the setting for out-of-sequence progress:

• Retained Logic holds the remaining duration of a progressed activity until all of its predecessors finish.
• Progress Override ignores the logic and lets the activity progress.
• Actual Dates calculates the passes using actual dates.

These produce different critical paths and different completion dates, so record which one is used and apply it consistently from baseline through each update. Many contracts specify one.

12. Baseline integrity and indices

Last, check that what you are about to submit matches what the contract asks for: the right contract milestones, a clear WBS and activity coding structure, contractual start and finish dates, and a baseline stored in the database so later updates can be compared. Two DCMA indices come into play from the first update onwards, not at baseline: the Critical Path Length Index (a ratio of critical path length plus total float to critical path length) and the Baseline Execution Index (activities completed against those planned). The related "missed tasks" check compares finishes against the baseline.

Worked example

Illustrative example, not a real project. The numbers below are invented to show how to read the results. They do not describe any RAYYAF client or any real programme.

A contractor prepares a 412-activity baseline for a mid-rise residential block and runs the checks before submission.

The headline is not "fails two metrics". It is the reading beside each figure. Most of the 31 open ends turn out to be finishing activities with no link to handover. The seven intermediate constraints were added to match a client's milestone list. Both are fixed by adding logic and moving the dates onto milestone activities with sensible constraints. After the fixes, the schedule is re-run, the critical path is re-checked, and the results are recorded in a one-page memo that travels with the submission.

A practical pre-submission checklist

• [ ] Native file reviewed (not PDF); copy used for testing
• [ ] Scheduling options recorded (progress setting, float definition, lag calendar, open-ended handling)
• [ ] Open ends, relationship mix, leads, lags and constraints counted and explained
• [ ] Negative float resolved or explained; high float reviewed
• [ ] Calendars checked against the site working week and holidays
• [ ] Longest Path reviewed and critical path test run on a copy
• [ ] Resource or cost loading verified if required by contract
• [ ] Contract milestones and WBS coded as specified
• [ ] Results and exceptions written into a short submission memo

When to get a second pair of eyes

A planner who built the schedule will rarely see its blind spots. An independent review of the native file before submission is usually faster and cheaper than a rejected baseline and a resubmission cycle. RAYYAF's Primavera P6 Schedule Health Check is a scoped review of this kind: it covers logic, constraints, float and calendars and delivers a prioritised findings list. If the baseline needs rebuilding rather than reviewing, see Baseline Schedule Development. Fees are confirmed in a written proposal.

About the author

Mohd Faisal Afatab is Founder and Principal Consultant of RAYYAF, with 14+ years in construction planning and project controls. His career covers residential high-rises, luxury villas, commercial developments and a 40 MW mission-critical data centre, working in Primavera P6 and Microsoft Project. These are experiences from previous employment, not RAYYAF client engagements.

Sources

• Deltek Acumen help: DCMA 14-Point Assessment Metric Descriptions (v8.11)
• Deltek: What is the DCMA 14-Point Assessment?
• Mosaic Projects, White Paper WP1088: DCMA 14 Point
• Oracle Primavera P6 Help: Settings tab of the Schedule dialog box

General information only. This article does not certify any programme and is not legal or contractual advice.

Frequently asked questions

Sources

1. Deltek: What is the DCMA 14-Point Assessment?
2. Mosaic Projects, White Paper WP1088: DCMA 14 Point
3. Oracle Primavera P6 Help: Settings tab of the Schedule dialog box

More from Insights

• RA Bill vs BOQ: How to Reconcile Quantities and Avoid Payment Disputes
• Extension of Time Claims: The Schedule Evidence a Contractor Needs