Three departments, three month-ends
Ask three people on a project when the month closed and you can get three answers.
Finance closed on one date because the financial calendar says so. Project controls closed on another, because that is when the progress data was cut. The quantity surveyor measured across a period that matches neither, because measurement for payment follows the contract.
Each is defensible on its own terms. The report that combines them describes a month that nobody actually had.
And almost nowhere was this decided. The dates were inherited, from a previous project or a previous manager or a client requirement that has since lapsed, and they have never been examined together.
The cut-off decides the data
The hour and the date are not administration. They determine what proportion of the report is a measurement and what proportion is a recollection, for the reason Week 17 describes at daily level and which applies at every frequency.
Close too early and you have asked people to report work that has not finished producing its own record. Close too late and the report arrives after the meeting it was meant to inform, which is a different kind of failure and just as complete.
Between those there is usually a defensible window, and the useful question is not what the deadline is but why it is where it is. Ask on most projects and the answer is that nobody knows.
Data date is not cut-off
Two terms get used interchangeably and they are not the same thing.
The data date is the moment the schedule is considered current: everything before it is actual, everything after is plan. It is a property of the schedule.
The cut-off is when data collection stops for a reporting period. It is a property of the process.
They should coincide and often don't, which produces the quiet error where a schedule updated to one date is reported against quantities collected to another. Nothing looks wrong. The progress figure is simply describing a slightly different period from the one on the cover.
Why the dates are where they are
It is worth asking, because the answer is usually recoverable and usually surprising.
A deadline set to feed a Monday morning meeting that no longer takes place. A client representative who wanted the report before their own call, and who left the project two years ago. A finance close inherited from a corporate calendar that has nothing to do with construction.
Some of these can't move. Finance answers upwards and measurement answers to the contract. But the ones that belong to the project can move, and moving a collection deadline by three hours sometimes does more for data quality than a year of chasing people.
The precondition is knowing why the hour is the hour. If nobody on the project can answer that, it is not a constraint. It is a habit.
What to write down
The remedy is a calendar, and it is a page rather than a system.
For each reporting product, four things: when collection closes, who has to have submitted by then, when it is issued, and who receives it. Then the same for the month, including the finance close and the measurement period, so that the three dates sit on one sheet where their differences are visible.
Most of the value appears when it is first written. Three people discover they had assumed different dates, and that conversation is cheaper now than in the reconciliation meeting described in Week 25.
The boundary items
Wherever two dates differ there is a set of items that fall between them: work done after your cut-off but before finance closed, material delivered in the gap, a measurement completed two days late.
These don't need a system. They need a list, made each month, of what crossed the boundary
and which period it was counted in. Twenty minutes, and it removes almost all of the argument that would otherwise happen when the two documents disagree.
The alternative is that each side treats boundary items according to its own logic, both correctly, and the difference is discovered by somebody downstream who has no way of knowing it was a calendar effect rather than an error.
System design
One page, not a system. Written once, it settles the assumptions three departments were each making separately.
| Record | Produced by | Required quality | Verified against | Feeds |
|---|---|---|---|---|
| Reporting calendar | Project controls | One page holding all three closing dates | Finance and contract dates | Every report |
| Data date | Project controls | Coinciding with the collection cut-off | The schedule | Schedule update |
| Collection cut-off | Project controls | Late enough that the site can count, early enough to be read | The meeting it feeds | Report content |
| Boundary item list | Both sides | Made monthly, before publication | The two cut-offs | Reconciliation |
The last two rows are not yours and can't be changed. Putting them on the same page as the first three is the point: the gaps become visible, and the boundary items become a list rather than an argument.
Practical insight
Write down three dates for last month: when your progress data closed, when finance closed, and the end of the measurement period.
If all three are the same, you are in a small minority and it is worth knowing. If they differ, work out by how many days, and then ask one question for each gap: what was going on during those days that would land on one side or the other?
You don't need to change the dates. Changing them is often impossible, because finance answers to a corporate calendar and measurement to the contract. What matters is knowing where the seams are, because every unexplained difference between two reports lives in one of them.
Key takeaways
- Three departments can close a month on three different dates, each for a good reason.
- The dates are almost always inherited rather than chosen, and rarely examined together.
- Cut-off decides how much of a report was measured and how much was remembered.
- Data date is a property of the schedule; cut-off is a property of the process. They should coincide.
- A reporting calendar is one page: collection closes, who submits, when issued, who receives.
- Most of its value appears while writing it, when people discover they assumed different dates.
- List the items that fall between two dates each month. It removes most of the argument later.
Records born here. Reporting calendar · boundary item list · the agreed data date for each update.
What is coming next
With the calendar fixed, the outputs start. The first is the shortest document on the project and the one with the longest afterlife.
Next week: the daily report — what the deadline does to it, and how one day ends up with several versions of itself.
Enjoyed this lesson?
Join with Google to get each new lesson the moment it's published — and help me see which topics matter most to you. No spam, one email a week, unsubscribe anytime.
Already following on LinkedIn works too — this is just for the weekly email.