DCMA-14 Metric 9: Invalid Dates, Data Date Issues and Out-of-Sequence Progress

Invalid dates in a construction schedule are forecast start or finish dates that fall before the data date, or actual start or finish dates that fall after it. DCMA's expectation is zero, because either condition means the schedule was not properly statused or rescheduled after the last update.

This is metric 9 in the DCMA-14 schedule assessment. It is a hygiene check, and it is easy to fail after a rushed update.

What are invalid dates in a construction schedule, and what does DCMA test?

The pamphlet looks at incomplete tasks for two conditions: a forecast (early) start or finish earlier than the status date, and an actual start or finish later than the status date. For both, it states there should not be any (DCMA-EA PAM 200.1). The pamphlet's own example uses a status date of 8/1/09, where any forecast date for incomplete work has to be on or after 8/1/09.

There is no percentage threshold; one invalid date is a hit. The cause is nearly always process rather than logic, which makes the check easy to clear and embarrassing to fail.

What is the data date and why does it drive this check?

The data date, also called the status date, is the as-of date of the schedule's progress (Oracle, Data Dictionary). Actual dates belong on or before it. Remaining work is calculated from it forward.

When you update, the data date advances. If it does not, or if it advances without a reschedule, remaining activities keep forecast dates computed from the old data date and now sit in the past. If an actual date is entered with a typo (the wrong month, the wrong year) or "planned" progress is entered ahead of time, an actual date sits after the data date. Every invalid date is one of those two failures.

What causes invalid dates in an update?

• Data date not advanced. The new progress was entered but the data date still shows last month.
• Update not rescheduled. Progress and data date are right, but schedule was never re-run, so remaining dates are stale.
• Typed actuals in the future. A projected finish was entered in the actual finish field, or a date was keyed with the wrong year.
• Constraints that hold forecast dates. A constraint on an unstarted activity can pin its start earlier than the data date. See hard constraints for how constraints override logic.
• Mixed update sources. Progress imported from a subcontractor file that used a different data date.

Illustrative example: the update has a data date of September 30. The table shows what a reviewer would flag.

How do you find invalid dates in P6?

P6's Schedule Check report has an Invalid Progress Dates section that lists activities with actual start or finish dates later than the data date. It leaves out WBS summary activities, level-of-effort activities and activities that finished before the data date (Oracle, Invalid Progress Dates). That section covers the actual-date half of the DCMA test. For forecast dates, build your own filter.

1. Create a filter for status not equal to Completed.
2. Add a condition for early start or early finish earlier than the data date.
3. Create a second filter for actual start or actual finish later than the data date.
4. Exclude summary, level-of-effort and milestone activities to match the DCMA population.
5. Save both filters as part of the update checklist and run them before you issue the file.

Check the data date field in project details before any filtering. If the data date is wrong, the filters are right and the results are still meaningless.

How does out-of-sequence progress affect dates?

Out-of-sequence progress means an activity has started before its predecessor finished (Oracle, Data Dictionary). It is common in construction because crews overlap trades that the logic shows in series. It is a different problem from invalid dates, but the two often appear in the same bad update.

P6 handles progressed activities through three scheduling options: Retained Logic, Progress Override and Actual Dates (Oracle, updating progress). They differ in whether the remaining work still waits for the predecessor, so they produce different forecast dates and different float. Oracle notes that the Actual Dates option can produce negative float when actual dates fall after the data date, which ties this check to the negative float guide.

Do not use the scheduling option to make the metric look better. Pick the option the contract requires, document it, and clean up the logic so the out-of-sequence activities are no longer out of sequence. A logic-quality check such as missing logic helps find those spots.

How do you fix invalid dates?

1. Verify the data date against the actual status date for the update period.
2. Correct actual dates. Replace typo dates with the real dates, and remove any actuals entered ahead of the data date.
3. Reschedule. Run the schedule so remaining work forecasts from the data date forward.
4. Review constraints on any activity whose forecast date still sits before the data date.
5. Re-run both filters. The expected result is empty lists.
6. Record the change in the update narrative if corrections affected prior reported dates.

Corrected invalid dates can also move the numbers behind BEI and CPLI, because actual finishes change the count of completed tasks.

How do you prevent invalid dates before each update?

Build the checks into the update routine so the file is clean before anyone else sees it. A short sequence works for most teams.

1. Receive field progress with a cut-off date and confirm it equals the planned data date.
2. Enter actual starts, actual finishes and remaining durations, and never enter a projection in an actual field.
3. Set the new data date, then reschedule.
4. Run the two filters and the P6 Schedule Check report, and resolve every hit.
5. Compare against the prior update for activities that jumped or reverted, since those often hide data-entry mistakes.
6. Save the filter results with the update package so a reviewer can see they were run.

Illustrative example: in the earlier table, B1010 was in progress with 3 days of remaining work and a forecast finish of September 24. After correcting the data date handling and rescheduling from September 30, the finish forecasts to October 3. B1020 moves to start October 3 as well, and B1030's actual start of October 2 is changed to the true September 29 entry. All three rows leave the invalid list in one pass, because the cause was a missed reschedule plus one typo.

If the same invalid dates keep returning, look at who enters progress and when. Field teams often report on a different cut-off than the scheduler uses, and subcontractor updates arrive after the data date has already advanced. Agree a single cut-off in the schedule specification, and the problem usually stops.

What mistakes get flagged by reviewers?

• Submitting an update with the old data date because progress was entered after the cut-off.
• Entering planned dates in actual fields to show a future event.
• Fixing the date with a constraint instead of with progress or logic.
• Importing a subcontractor schedule with a different data date and merging it without reconciling.
• Changing the scheduling option between updates without saying so.

A clean invalid dates check does not mean progress is accurate; it means the dates sit on the right side of the data date.