Ask a controller what is slowing down their capital reporting and you will hear about systems, headcount, and the volume of projects. Ask to see the project list and the real answer is usually sitting in the first column.

Bldg 4 Reno. BUILDING 4 RENOVATION - PHASE 2. B4 renov (Smith). 2024 Cap - Bldg 4.

Four projects. Possibly one building. Nobody can say for certain without opening all four.

Naming is not cosmetic — it is the join key

A capital portfolio only becomes reportable when costs can be grouped reliably. Grouping requires that two people describing the same thing produce the same string, or at least the same structured identifier. When they do not, every roll-up becomes a manual reconciliation, and the analysis that leadership actually wants — spend by site, by asset class, by funding source, by year — requires a person with institutional memory to assemble by hand.

That person becomes the bottleneck. And when they take a new role, the reporting capability leaves with them.

What free-text naming actually costs

  • Duplicate projects. The same work opened twice under different names, with costs split across both. Neither balance is right.
  • Orphaned costs. Invoices coded to a project nobody recognizes at close, so they sit in CIP indefinitely rather than being capitalized or expensed.
  • Impossible portfolio views. "How much have we spent at the north campus since 2022?" becomes a research project instead of a query.
  • Audit friction. Sampling a CIP balance is straightforward when project identity is unambiguous. It is painful when the auditor has to ask what four similar names mean.
  • Lost componentization. When a project name does not encode what kind of work it is, the person capitalizing it four years later has no signal about how it should be broken apart.

A convention that survives contact with reality

The mistake in most naming standards is ambition. A 12-segment code that captures everything will be abandoned within two quarters because the people opening projects are facilities managers under deadline, not data stewards.

What holds up is short, structured, and enforced at entry:

  • Location. A controlled list, matching the site codes finance already uses. Never free text.
  • Asset class or work type. Building, building improvement, fixed equipment, moveable equipment, software, infrastructure. Six to ten values, not forty.
  • Year initiated. Makes aging visible in the name itself.
  • A short human description. Free text belongs here and only here.

The critical word is enforced. A convention that lives in a policy document is a suggestion. A convention implemented as required dropdown fields in the system where projects are actually opened is a control. If someone can type a project name into a blank box, they will, and the standard is already gone.

The bottleneck was never the volume

Organizations reach for more staff or a new system when capital reporting gets slow. Sometimes those are the right answers. But in most of the fixed asset environments I have walked into, the constraint was not capacity or software — it was that the underlying data had no consistent identity, so every question required a human to interpret it.

Standardizing project identity is a small piece of work with a disproportionate payoff. It is also the prerequisite for everything downstream: componentization, in-service date governance, and clean conversion into a fixed asset system. Loading badly-named data into a better system just produces the same problem at higher speed.

What is in a name? For a capital portfolio: whether you can report on it at all.