The log that tells you first

Every month on a capital program, somebody reports the change order position. Approved changes against contract value, pending changes below it, a percentage at the bottom. If that number is small, the project is reported as being in control.

It is the wrong number to be looking at, and the reason is structural rather than careless.

A change order log is a record of things that have stopped moving

By the time a cost becomes an approved change order, several things have already happened. Someone identified the condition. Someone priced it. Someone argued about entitlement. Someone with authority accepted the argument and signed.

That process takes months. Which means the change order log is not a picture of your exposure — it is a picture of the exposure you finished negotiating about, some time ago. It is a lagging indicator by construction, and it is at its most reassuring exactly when it is least informative: early, when little has been settled, and the percentage is therefore tiny.

I have watched a project report a change position of well under one percent of contract while roughly a quarter complete, and be described as clean on that basis. The change channel on that job eventually ran to a substantial fraction of contract value. Nothing was hidden. The information was simply sitting in a different log.

The leak shows up first as a question

Before a change is a change, it is a question. Someone in the field cannot build what the drawing shows. A dimension does not close. Two disciplines occupy the same space. A specification says one thing and a detail says another.

That question goes into the RFI log. And the moment it carries a cost impact — even an unpriced one, even a to be determined — the money exists. It is not approved, not agreed, not negotiated. But it is real, and it is on the record months before it will appear anywhere a steering committee is looking.

Read that way, the RFI log is a forecast. It is the earliest quantitative signal a program produces about where it is going, and on most projects nobody reports it as a number at all.

Why nobody reads it as money

Three habits get in the way, and all three are fixable.

It is filed as a question log, not a cost log. RFIs live with the field team and the engineer. They are tracked for turnaround and closure, because that is what the field needs. Nobody totals the cost column, because the log was never designed to be totalled.

The reason codes describe who asked, not who caused. Most RFI coding schemes distinguish a clarification from a contractor query from a field management query. Those categories record the origin of the question. They say nothing about the origin of the condition — and the origin of the condition is the only thing that decides who pays. A log coded by questioner can tell you that a great deal of money moved. It cannot tell you whose money it was.

Items close with the cost still open. An RFI gets answered, the field unblocks, and the entry is closed with the impact left as unknown. The question is resolved, so the record is tidy. But the cost has not gone anywhere — it has merely stopped being visible, and it will reappear later as a claim assembled retrospectively rather than a change managed contemporaneously.

What to do instead

Four changes, none of which requires new software.

Report the RFI channel as a forecast, every month, beside the approved change position. Cumulative cost impact including unpriced items carried at an estimate. Two lines instead of one. The gap between them is your early warning, and the size of that gap is the most useful number on the report.

Require a cause code at closure, not at opening. An RFI may legitimately open as a clarification — at the moment it is raised, nobody knows. It must not close as one. Closure should require somebody to say what caused the condition. That is a two-minute decision made while the facts are fresh, and it is worth an enormous amount later, because it is the difference between a documented position and a reconstructed one.

Do not let anything close with an open cost or schedule flag. If the impact is genuinely unknown, the entry stays open and ages in a report where someone has to look at it. A tidy log full of unknown impacts is not control. It is deferred argument.

Review by threshold, not uniformly. Cost impact in the change channel is severely concentrated — a small number of entries carry most of the money, and the long tail carries almost none. So set a dollar line above which an independent check estimate is mandatory, and put everything beneath it on a light-touch path. Reviewing every RFI equally is how teams end up reviewing none of them properly.

The part that generalises

None of this is exotic. It is bookkeeping, done in a slightly different order, in a log that already exists.

But I want to be honest about where it came from, because it makes a point about how problems in this industry actually get found. Nobody would build this from the outside. If you have never watched a change order log report a project as healthy while the field is drowning in unresolved conditions, you would have no reason to suspect that the change order log is the wrong place to look. You would build a better change order log.

The problem was never that the data did not exist. It was that the data lived somewhere nobody had thought to read as money — and knowing where to look is not a technical insight. It is a domain one.

That is the general shape of most real problems in capital delivery. They are not waiting to be solved by better tooling. They are waiting to be noticed by someone who has felt them.