The Data Date, Explained

The data date is the point in time that separates what has happened from what is forecast to happen. Everything to the left of it is history and should be backed by actual dates. Everything to the right is the plan for the remaining work. It is the single most important date in a schedule update, and it's also the one most often handled carelessly. This post covers what it does, the rules that follow from it, and how to check an update for data date errors.

What it is

Every CPM calculation needs a starting point. In a new, unprogressed schedule, that's the project start. Once work begins, the starting point becomes the data date: the scheduler computes early dates for all remaining work from the data date forward.

Different tools call it different things. Primavera P6 calls it the data date. Microsoft Project uses the status date, which plays a similar role though Project's behavior around it is less strict. Some owners call it the status date, the as-of date, or the cutoff date. They all mean the moment the update describes.

The data date is usually the start of a day. A data date of May 1 means "progress as of the end of April 30, forecast starting the morning of May 1."

The three rules

Every update should satisfy these. Most schedule quality checks test for them directly.

1. No actual dates after the data date. An activity can't have actually started or finished in the future. If the update says the elevator rails were installed on May 6 and the data date is May 1, something is wrong.
2. No forecast dates before the data date. Unstarted work and the remaining portion of in-progress work can't be scheduled in the past. If an activity was supposed to start April 20 and didn't, its forecast start is now the data date or later.
3. In-progress activities resume at the data date. The remaining duration of an in-progress activity runs from the data date forward.

Rule 2 is the one that does the real work. It's how the schedule picks up delay. If something should have started and didn't, moving the data date pushes it forward, and with it everything downstream.

A worked example

Convention: working days, 0-based. A network of four activities, all finish-to-start with zero lag:

Unprogressed, starting day 0:

Now update with data date = day 8. Status:

• A actually started day 0 and actually finished day 7, one day late.
• B has not started. It should have started on day 6 (the planned EF of A), but A finished late, and then the plumber didn't show on day 7.

Recalculate from the data date:

A: actual 0 to 7 (history, left of data date)
B: not started; ES = max(A actual finish 7, data date 8) = 8; EF = 12
C: ES 12, EF 15
D: ES 15, EF 25

Project finish moved from day 23 to day 25. One day came from A finishing late. The other came from B not starting on day 7 when it could have, which the data date captured automatically: B can't be forecast to start before day 8.

If the scheduler entered the actuals but forgot to move the data date forward from the last update, the software would forecast B to start right after A's actual finish, on day 7, and show a finish of day 24. The schedule would look one day better than reality. That's the classic error.

Common data date mistakes

Moving progress without moving the data date

Someone enters actuals but leaves the data date where it was. The forecast for unstarted work stays in the past and the schedule ignores time that has passed. The fix is to move the data date with every update.

Actuals entered as of different days

The steel progress came in on the 28th, the plumbing on the 2nd, and drywall on the 5th. The update now mixes snapshots. Pick one cutoff, normally the end of the day before the data date, and report all progress as of that moment. Anything that happened later goes in next month.

Remaining duration not updated

A 15-day activity started 12 working days ago. The software might compute remaining duration as 3 days if it's linked to percent complete or duration elapsed. The field says there are 8 days left. If you don't enter 8, the forecast is wrong. Always ask for remaining duration directly.

Actual dates that change month to month

Actual dates are history. Once submitted, they shouldn't move unless you found an error, and if you did, say so in the narrative. An actual start that drifts between updates is a red flag for any reviewer.

Data date set to a weekend or holiday

It works mathematically, but it confuses people. Set it to the first working day of the period or to whatever your spec requires.

How the data date interacts with other settings

• Out-of-sequence work: When a successor has started but its predecessor isn't finished, the remaining work on the successor resumes from the data date or from the predecessor's finish, depending on whether you use retained logic or progress override. See Retained Logic vs. Progress Override.
• Constraints: A start-no-earlier-than constraint before the data date has no effect on remaining work, since the data date already pushes it later. Constraints after the data date still apply. See Schedule Constraints.
• Calendars: The data date is converted using the activity's calendar. A 5-day calendar activity and a 7-day calendar activity resume at the next working period for each.
• Baselines: The baseline doesn't move with the data date. Comparing current forecast to baseline is how you measure slip. See Baselines: When to Set Them and When to Re-Baseline.

A quick check for any update

Before you submit, or when reviewing one you received, run through this:

Most scheduling tools, including schedule.construction, flag the first three automatically. The last three need a person.

Key takeaways

• The data date splits history (actuals) from forecast (remaining work).
• No actuals after it, no forecasts before it, and in-progress work resumes at it.
• Moving the data date is how an update captures delay from work that didn't start on time.
• Report all progress as of one cutoff and get remaining durations from the field.
• For the full update routine, see How to Run a Monthly Schedule Update.