Information Latency: Managing Technical Queries as a Controlled Workstream

On most UK commercial projects, the programme is a crowded document. It tracks trades, milestones, inspections, deliveries and commissioning. What it rarely tracks is the question nobody answered. A request for information, a technical query or a clarification on a drawing can sit in an inbox for days without appearing as a line item, a risk or a delay. By the time it surfaces, a subcontractor is standing idle, a sequence has slipped and the commercial conversation has hardened.

Information latency is not a new problem. It is simply one that tends to be managed informally until it becomes expensive. The argument here is straightforward: technical queries deserve the same governance as any other workstream on a commercial project. Not because paperwork is inherently virtuous, but because unanswered information is a constraint on production, and constraints that are not measured cannot be controlled.

The invisible constraint

A programme shows what is planned to happen. It does not automatically show what is waiting to happen because a detail remains unresolved. That gap matters. A cladding interface, a service penetration, a fire strategy assumption or a landlord's consent condition can each stop a trade from proceeding. If the query sits outside the programme, the delay is often attributed to the trade rather than to the information flow that held it up.

This is where margins erode quietly. Preliminaries continue, supervision continues, and the site team absorbs the disruption in the short term. Later, when a delay claim arrives, the evidence is often thin: a chain of emails, an unanswered call and a drawing revision that arrived after the window had closed. The absence of a controlled record makes the claim harder to defend and harder to price.

Why the backlog grows

Backlogs rarely grow because nobody cares. They grow because responsibility is diffuse. Queries arrive through multiple channels — email, site meetings, mark-ups, messaging apps — and are answered by different parties depending on the subject. There may be no single register, no agreed response period and no clear point at which an unanswered query is escalated.

In UK contracts, the mechanism varies. Under JCT arrangements, further information may be requested through the contract administrator. Under NEC, the early warning and compensation event machinery creates its own rhythm and notice requirements. In either case, the contractual label matters less than the operational discipline: who owns the query, by when it should be answered, and what happens if it is not.

Four controls that make a difference

Treating queries as a workstream does not require a large bureaucracy. It requires a small number of controls applied consistently.

First, a single register. Every technical query should have one home, with a unique reference, the date raised, the party responsible for answering and the trade or activity affected. If queries live in several inboxes, the register should still be the authoritative record.

Second, response targets based on consequence. Not every query carries the same urgency. A finish detail can wait a few days; a structural or life-safety query cannot. Sorting queries by the activity they block, rather than by the date they arrived, allows effort to follow risk.

Third, an escalation route. A response target without an escalation point is a hope, not a control. The register should show when a query becomes overdue and who is responsible for escalating it — typically through a weekly information review rather than an ad hoc chase. The review should be short, factual and focused on the queries that are blocking work.

Fourth, closure evidence. A query is not closed when someone sends an email. It is closed when the answer is recorded, distributed to the parties who need it and reflected in the relevant drawing, specification or instruction where necessary. That final step is often skipped, which is why the same question can reappear weeks later in a different form.

Programme status, not programme theatre

Giving technical queries programme status does not mean adding a long list of RFIs to the master schedule. It means recognising information as a dependency and reporting it alongside other dependencies. A weekly report showing the number of open queries, their age, the trades affected and the overdue responses is more useful than a comprehensive log that nobody reads.

The commercial benefit is not only fewer delays. A controlled register provides a contemporaneous record of what was asked, when it was answered and what changed as a result. That record supports fair valuation of variations, defends against unfounded claims and gives the client a clearer view of where decisions are needed. It also supports the information requirements that increasingly sit alongside building safety and handover obligations, where the quality and timing of technical information matter well beyond practical completion.

Before the critical path is rewritten

Projects rarely fail because of one unanswered query. They fail when unanswered queries become normal, when the site team works around missing information and when the commercial record no longer reflects the sequence of events. By then, the critical path has been rewritten by default rather than by design.

The practical response is not complicated. Appoint an owner. Keep one register. Set response targets by impact. Escalate on evidence. Close the loop. These are ordinary controls, but they are the difference between a query that is managed and a backlog that manages the project.