Monthly construction progress reports: why they arrive too late
Updated: 7 days ago
By Roman Bazelchuk | NEC Accredited Project Manager | APMG Project Planning and Control
Founder, NEC Planning Solutions Ltd
Take the monthly construction progress report on a typical job. Data cut-off on the 25th, update built over the following week, report issued around the 5th, discussed at the progress meeting mid-month. A decision taken on the 15th therefore rests on information that was already three weeks old when it was read, describing a period that began seven weeks earlier. Nobody is hiding anything. The loop is simply longer than the rate at which the job changes.
Project controls reporting is usually discussed as a frequency. Monthly, with a four-week look-ahead, and that is treated as the answer. Frequency is not cadence. Cadence is the closed loop: capture, update, review, decide, act, and then capture again against what was decided. A project can report monthly for two years and never close that loop once.
This matters because the loop is where drift hides. A programme does not usually fail in a single month. It drifts by a few days at a time, invisibly, until the accumulated gap is large enough to be undeniable, and by then the response is expensive. That is the argument in what programme recovery actually involves, and this piece is about the mechanism underneath it.
The lag nobody prices
Work through the arithmetic on your own project and the number is usually worse than expected. Between the moment a fact becomes true on site and the moment a decision is taken because of it, most monthly cycles carry five to seven weeks.
The first week is collection. Progress is gathered from people who are busy, against activities they did not choose, in a format built for the contract rather than for them. The second is production: the update is built, checked, and cleaned up enough to issue. Then there is the wait for the meeting, because the decision forum runs on its own calendar rather than on the data's.
Individually every step is reasonable and defensible. Together they mean the project steers using a position it held over a month ago. On a job that is stable, that is survivable. On a job that is moving, it guarantees that every correction is applied to a situation that has already changed.
One construction progress report, two incompatible jobs
Most projects run a single reporting product doing two incompatible jobs, and doing neither of them well.
The look-ahead is a delivery instrument. It faces forward, covers two to six weeks, belongs to the people doing the work, and its only test is whether the next fortnight happens as described. It should be short, specific and slightly uncomfortable, because it is a commitment rather than a forecast.
The update is a contractual record. It faces backward, covers the period since the last one, belongs to project controls, and its test is whether it accurately shows what happened and what that did to planned Completion. It is the document the clause 32 revised programme obligation is satisfied by, and the one a later assessment is measured against.
When those two are merged, both degrade. The look-ahead becomes cautious, because anything written in it might be quoted contractually. The update becomes optimistic, because it is being used to reassure a meeting rather than to record a position. The team ends up with a document that neither tells them what to do next week nor tells anyone the truth about last month.
The inversion that starts the drift
Here is the moment a controls function stops working, and it is quiet enough that nobody notices it happening.
In a healthy cycle, the programme is updated in order to plan the next period, and the report is a by-product of having done that. In a drifting one, the programme is updated in order to produce the report. The purpose has inverted, and from that point the programme is an output rather than a tool.
The symptom is easy to test for. Ask when anybody last opened the programme between updates. If the answer is nobody, for any reason, in the last month, then it is no longer being used to run the job. That is the same condition described in the five signs a programme has lost its integrity, seen from the process side rather than the document side.
The second symptom is what happens when the update is late. On a project where the programme is a tool, a late update causes visible pain, because people need it. On a project where it is an output, a late update causes an apology and nothing else. Nobody was waiting for it.
What a reporting cadence that holds looks like
Shorten the loop before shortening the interval. Reporting weekly with the same five-week lag produces the same drift more often and costs more to run. Move the data cut-off closer to the decision, and the decision closer to the data, and most of the benefit arrives without changing frequency at all.
Separate the two products explicitly. Different documents, different owners, different audiences, different rules. The look-ahead is not a contractual submission and should not be written as though it might become one. The update is, and should be.
Make the collection easier than the avoidance. Progress data arrives late because supplying it is harder than not supplying it. Ask for less, ask for it in the form the person already has it, and ask the same question every period so the answer becomes routine.
And close the loop with a named action. Every cycle should end with a short list of decisions taken and who owns each, carried into the next cycle and reviewed there. Without that step the process is measurement rather than control, and measurement on its own has never moved a completion date. The tooling matters less than people assume: this works in a properly structured P6 model and fails in one, depending entirely on whether the loop closes.
The view from the desk
I have joined projects where the reporting was immaculate and the job was in trouble, and projects where the reporting was rough and the team knew exactly where they stood. The difference was never the format. It was whether the cycle ended in a decision or in a distribution list.
My position is that the reporting cadence should be designed once, at mobilisation, and then defended. It is nearly always installed in the first six weeks and then eroded by circumstance: a cut-off slips because somebody is on leave, a meeting moves, one month is combined with the next. None of those is significant on its own and all of them together are how a controls function decays. The dashboard discipline behind a good monthly pack is only as good as the rhythm that feeds it.
And I would resist the instinct to fix a late report by reporting more often. Frequency is the expensive lever and the least effective one. The cheap lever is the gap between the cut-off and the conversation, and almost nobody measures it.
Summary
Frequency is how often you report. Cadence is whether the loop closes. Most monthly cycles carry five to seven weeks between a fact becoming true and a decision being taken because of it, which is why drift accumulates invisibly.
Run the look-ahead and the update as separate products with separate owners. Shorten the lag rather than the interval. Make supplying progress easier than avoiding it. And finish every cycle with decisions and owners, because measurement without that step is not control.
Measure your own lag
Two pages that produce one number: the days between something becoming true on site and a decision being taken because of it. Plus the tests for whether the loop closes, whether the programme is still a tool, and where the collection is stuck. Direct download, no sign-up.
FAQ
What is reporting cadence in project controls?
The closed loop of capturing progress, updating the programme, reviewing it, taking decisions and acting on them, then capturing again against what was decided. It is distinct from reporting frequency, which is only how often a document is produced. A project can report monthly for years without ever closing the loop.
Why does the monthly construction progress report arrive too late to be useful?
Because of accumulated lag rather than delay. Collection takes a week, production takes another, and the decision forum runs on its own calendar. Between a fact becoming true on site and a decision being taken because of it, most monthly cycles carry five to seven weeks, so corrections are applied to a position that has already moved.
Should the look-ahead and the programme update be the same document?
No. The look-ahead faces forward, covers two to six weeks, belongs to the delivery team and is a commitment. The update faces backward, covers the reporting period, belongs to project controls and is a contractual record. Merged, the look-ahead becomes cautious because it might be quoted, and the update becomes optimistic because it is being used to reassure.
How do you know the programme has become an output rather than a tool?
Ask when anybody last opened it between updates. If nobody did, for any reason, in the last month, it is no longer being used to run the job. The second test is what happens when an update is late: if it causes an apology rather than a problem, nobody was waiting for it.
Is reporting more often the answer to poor visibility?
Rarely. Reporting weekly with the same lag produces the same drift more often at greater cost. The effective lever is the gap between the data cut-off and the decision, which almost nobody measures. Shorten that and most of the benefit arrives without changing frequency at all.
About the author
Roman Bazelchuk is the Founder of NEC Planning Solutions Ltd, a UK project planning and controls consultancy supporting contractors with NEC programme compliance, compensation event assessments and live project controls. He is an NEC Accredited Project Manager and holds the APMG Project Planning and Control qualification, with a BEng in Mechanical Engineering.
NEC Planning Solutions provides contract-aware planning support through a QA-governed delivery model, helping project teams keep programmes accepted, current and commercially useful from tender through to live delivery.
Reporting on time and still finding out late?
We run the monthly cycle as a closed loop: cut-off close to the decision, look-ahead and update kept separate, and every period ending with owners against actions. The pack is the by-product, not the purpose.
