The Data Date: What It Is and How It Goes Wrong

The data date is the "as of" date the schedule is being calculated from — the line that separates what's already happened from what's still being forecast. Drag the slider to move the data date across a six-activity programme. The chart assumes every activity has been statused exactly to plan up to the data date (green = actual, blue = remaining); in a real update, progress comes from site records, not from moving the data date.

What the data date is

Each P6 project has one data date (in the XER, PROJECT.last_recalc_date) — the date the forward pass is anchored to for remaining work. Completed activities keep their actual dates. In-progress activities keep their actual start, and their remaining duration is scheduled from the data date onwards. Actual dates should fall on or before the data date, and remaining or forecast dates on or after it. An actual date after the data date, or remaining work forecast before it, is an invalid date and usually means the update was not statused or rescheduled correctly.

How P6 uses it in the forward pass

For an in-progress or not-started activity, P6's forward pass uses the latest of the data date, the activity's logic-driven early date and any applicable start constraint as the start for remaining work (mandatory constraints can override logic). That's why moving the data date forward without also updating progress pushes any unstatused work that was due before the new data date forward to it, whether or not the work actually happened.

What happens when it's wrong

If the data date is behind the real status date, progress recorded up to that status date produces actual dates after the data date — dates that claim to have happened in the calculation's "future". If the data date is ahead of where progress has actually been recorded, unstatused work is pushed to the new data date as if it simply hadn't happened yet, and the forecast starts from a status the records don't support. Schedule checks such as the DCMA invalid-dates test look for exactly these symptoms.

Retained logic, progress override and actual dates

P6's schedule options include a setting for how progressed activities are scheduled. It mainly matters for out-of-sequence work — an activity that has started before its logical predecessor has finished. Retained logic keeps the relationship: the successor's remaining work is scheduled to follow the predecessor (for a finish-to-start link, after the predecessor finishes). Progress override ignores the unfinished predecessor relationship for that started activity and schedules its remaining work from the data date. A third option, Actual Dates, changes how the actual dates of progressed activities are used in the calculation; check Oracle's documentation for your P6 version before relying on it. The choice can change remaining dates, float and the critical path, so state it whenever an update is issued or compared. Retained logic is generally regarded as the more conservative choice, because progress override can hide a genuine sequencing problem.

Data date vs report date vs update date

These three are easy to conflate, and only the first is a P6 setting (terminology for the others varies between organisations, so define them in your update narrative). The data date is the date the calculation is anchored to inside P6. The report date is whatever date appears on the printed or exported report, which may not match the data date if the report was generated later. The update date is when the underlying progress data was actually collected on site, which may be earlier than both if there's a lag between site data collection and schedule update.

A basic but damaging mistake

Leaving the data date at the project start and never advancing it. Progress entered against that schedule produces actual dates after the data date, and remaining work is never re-forecast from the real status date — so the "live" schedule stops reflecting where the project actually is.