How old is the news you act on?

On a project that updates its schedule monthly, a site problem can be seven weeks old before anyone with authority decides what to do about it. This guide is for project directors and programme leads. It shows how to measure that reporting and decision delay from records you already hold, and how to tell whether the site, the report or the meeting is the slow part.

Ask a project director what the site costs to keep open each month and they will know. Ask how long the programme has left to run and they will have an answer.

Now ask when the last serious problem could first have been seen on site, and how many days passed before someone with the authority to act made a decision about it. That number is in nobody's report.

We call it the event-to-decision age: the number of calendar days between a problem becoming visible on site and someone with authority deciding what to do about it. It tells you how old the information was when that person made the decision. The time between that decision and work starting on site is a separate interval. Both deserve attention alongside cost and progress.

There is a reason to care beyond tidiness. A 2004 study by Flyvbjerg, Holm and Buhl found an association between longer project implementation and higher cost overruns. Its regression estimated nearly five additional percentage points of overrun per extra year from the decision to build through opening. That study measured implementation length; it does not establish the cost of slow reporting. But every week a problem goes unaddressed is a week of options lost. The resequence that was available in week one is rarely still available in week seven.

A monthly schedule update can leave a problem seven weeks old before anyone decides

Consider a piling crew that hits an obstruction in early January, just after the previous monthly cut-off. The obstruction affects the critical path. The site knows, but a revised solution needs approval beyond the site team. In this example, the formal monthly report carries the issue to the roles needed to approve that solution.

The January report reaches the approval role in mid-February. Approval follows later that month, and work on the revised piling solution starts near the end of February: roughly two months after the problem became visible.

These timings are chosen assumptions. The site can know immediately while the response still needs a design decision or funding approval beyond its authority. A direct escalation could reach those roles sooner; necessary investigation and approval may also take time. The audit below asks where the time went on your project.

The Florida Department of Transportation's construction manual gives a published example: where the contract specifies a CPM schedule, it says updates should be made monthly, alongside the progress payment cycle. The manual also calls for weekly progress meetings. When the people who decide depend on the monthly update, a problem waits for the data date, then for the report, then for the next meeting, before anybody acts. I have argued elsewhere that the monthly report is the one deadline a controls team always meets, and that everything without a deadline gets deferred. Escalating a problem outside the cycle is one of the things that gets deferred.

A late report can show only the first few days of a fix

The piling work starts near the end of February, just before the reporting cut-off. When February's report arrives in mid-March, it describes only the first few days of the fix. Work has continued throughout report preparation, but that newer progress is absent from the figures.

The example assumes that progress through March provides enough evidence to judge the fix. March's report brings that evidence to the April review, roughly three to four months after the original problem. Direct site evidence could support an earlier review.

I have watched progress meetings read that report and lose their nerve. A sound fix gets reversed, doubled or replaced before it has had a fair trial. Leadership is judging work that has been underway for weeks using only its first few days of measured progress.

So record both when work on the fix began and when reliable evidence reached the decision-maker. The interval includes the time the fix needs to produce a result and the time that result takes to reach leadership. Establish which caused the wait before trying to shorten it.

One large owner held approval dates but did not check the delay

If this number were easy to see, someone would already be tracking it. Mostly they are not, even at the largest scale.

The United States Government Accountability Office looked at how the Department of Veterans Affairs, which builds hospitals costing hundreds of millions of dollars each, handled changes on its major projects. In 2013 the auditors found that changes had to climb several levels of review, and that those reviews had caused extensive delays and increased costs. In 2017 they reported something stranger. The VA's software recorded when every change was raised and when it was approved, and the VA had its own required timeframes for approval, but it was not using those dates to check whether approvals met them. By 2018, GAO had confirmed that a new system was collecting approval-cycle figures.

Having the dates is not the same as looking at them. Most project systems already hold enough to answer the question, scattered across diaries, packs and minutes. The step that is missing is subtracting one date from another.

How to measure reporting and decision delay from your last three surprises

You do not need a new system to get a first answer. Start with the last three events that genuinely surprised the leadership: an unexpected delay, a cost increase, a missed handover or a claim that arrived late. Three events will not prove anything about the industry. They will show whether your project has a pattern.

Measure from when the problem could reasonably have been spotted. Use the true escalation date, even if a phone call preceded the written record. When the site manager knew is relevant, but the audit follows the role authorised to approve the particular response you named.

Find what caused the longest approval gap

Compare the two intervals across your three events. Start with the longest gap and use the underlying records to separate necessary work from waiting. A date difference points to where you should look; it does not establish the cause.

If the problem was recorded the same day but waited four weeks for a meeting, faster site capture will not help. If leadership decided that day but the instruction took two weeks to reach the work, the report is not the constraint. If the commercial team had the problem promptly through an early warning or a notice while the board pack stayed slow, the contract machinery is working and the management reporting is not.

Look for the pattern across the three:

• Did every event wait for the monthly data date?
• Did the report add weeks after the schedule was updated? If so, the way the report is assembled is the place to look.
• Had an early warning, request for information or notice already carried the news faster?
• Did the decision wait for a standing meeting?
• How long did the site wait after the decision?
• When could the project first judge the result fairly?

If any event was more than a month old when the decision was made, investigate where that month went. Some time may have been needed for investigation or approval. If most of it was spent waiting for scheduled reports or meetings, the reporting cycle is controlling the response.

You will then know how long it took to inform the approver and agree the response, with a concrete gap to investigate. Keep implementation and the freshness of review evidence as separate follow-up questions. This post is the first in a series on the cost of slow news. The posts that follow build on that baseline: how to shorten each interval, how to put a cost on the days that remain, and how to protect the contractual clocks that were running the whole time.