Your TQ register is a commercial radar. Most people never read it that way.
Most commercial events announce themselves first as technical queries. Here is what happens when you assess the whole register in one pass.
Ask most project teams what their technical query register is for, and you will get a version of the same answer: it is a list of questions we have asked the design team, and the answers we got back. A record. An administrative artefact.
That is true, and it is also a wasted opportunity. Because a TQ register, read commercially rather than administratively, is one of the earliest and clearest signals of where a project is about to change.
Why events hide in queries
A commercial event rarely arrives announcing itself. It arrives as confusion. Somebody on site hits something that does not match the drawings, or the drawings that does not match each other, and they do the correct thing: they raise a technical query.
At that moment, before anyone has thought about entitlement or notification, the seed of a compensation event is already sitting in the register. The TQ is the entry point through which most commercial events are first discovered, long before they are recognised as commercial at all.
The question that starts as "which detail is correct?" is very often the same question that ends as "who is paying for the difference?"
The problem with reading them one at a time
TQs are handled in the order they arrive, by whoever is free, as isolated items. Each one gets an answer and gets closed. The register grows to hundreds of entries.
And the pattern (the three TQs that are all circling the same underlying design problem, the cluster of queries that together signal a change the client has not formally instructed) is invisible when you only ever look at one row at a time.
What a single-pass assessment finds
The exercise that changes things is deceptively simple: assess the entire register in one pass, specifically for commercial implication. Not to answer the queries, but to ask, of each one, a different question. Does this carry entitlement? Does it point at a change that was never instructed? Is there a notification window already running on it?
Done by hand, this is a punishing day's work, which is why it almost never happens until a dispute forces it. Done in one pass, it consistently surfaces the same categories:
- Queries that are really unnotified compensation events, with the clock already ticking.
- Clusters pointing at a single design change dressed up as several small questions.
- Entitlement that is clear sitting next to entitlement that is arguable. A distinction worth everything when you decide what to submit.
The register was always a radar. Most people just never had the time to read the whole screen at once.