Building Commissioning Software Problems: The 7 That Cost Weeks on Site, and How to Avoid Them

Why does the build come out as a form builder instead of a script library?

Because a test script looks like a form. It has fields, a technician fills them in, it produces a record. A developer sees that pattern in the first meeting, proposes a configurable form builder, and everyone agrees because the demonstration is convincing.

What has been lost is the reason you started. A commissioning firm's value is concentrated in its script library: what to test on a variable air volume box, in what order, with what pass criteria, what to do with a chilled water plant running two chillers and a bypass. That library took a decade to build, and it currently lives as Word documents copied into each project and edited, which means an improvement made on one project never reaches the next. A form builder reproduces exactly that problem behind a nicer interface.

A script is structured content, not a form. It is ordered steps with expected values, tolerances, required evidence, and a link to the specification clause or sequence of operations being verified, held at a version. A project instantiates scripts from the library at a pinned version, so a project already in progress stays stable while the library keeps improving. When a technician finds a step that is wrong or a criterion that is ambiguous, that becomes a proposed revision routed to the library owner rather than an edit in one project's copy.

Ask any prospective developer how a test script differs from a checklist. If they treat both as forms, you will get a form builder, and the asset you set out to create will still be a folder of documents.

What goes wrong when the equipment register is built from drawings?

The register is the project, and it is wrong from the day it is created because it is built from design documents and the building is not built from design documents.

The gap is specific and repetitive. Equipment gets substituted through a submittal, so the model and the test set change. Three units are removed in a value engineering exercise months after the register was drawn up. Tag numbers change between design drawings and shop drawings, and again between shop drawings and what is stencilled on the unit in the field. A controls point list arrives late and does not match the mechanical schedule. Meanwhile the register lives in a spreadsheet that four people have edited and nobody versioned.

The result is the disputed percentage. The commissioning agent counts the equipment on their register, the mechanical contractor counts what they installed, and the owner counts what they think they bought. Two parties counting different denominators will never agree on a completion number, and the argument is unwinnable because neither register carries provenance.

The fix is to model the register as a living reconciliation rather than a list. Every entry records where it came from: design schedule, submittal, controls point list, or field verification. Substitutions and removals are recorded events, not silent edits, so the denominator has a history. Each piece of equipment carries its system, its area, its responsible contractor and its required test set, so a change to the register immediately updates completion percentages by system and area instead of triggering a manual recount. This sounds like housekeeping and it is the single largest source of disputes on a commissioning project.

Why do building automation trend feeds and document integrations break after launch?

Trend ingestion breaks because every building is its own integration. Automation systems expose data through several different protocols and interfaces, and the route that worked on the last project may not exist on this one. It also breaks on access rather than technology: the controls contractor owns the system during construction and hands it over at an unpredictable moment, so a feed established in commissioning can disappear at turnover.

It then breaks a second way that is harder to notice. A point is renamed or a controller is replaced during troubleshooting, and the trend for that point stops without an error. The analysis rules keep running against the points that remain and report nothing wrong, which is worse than reporting nothing at all.

Document integrations break on identity. Submittals, operation and maintenance manuals and shop drawings arrive through a construction management platform under the general contractor's naming, and the link between a document and a specific piece of equipment is usually implicit in a file name.

The fixes are ordinary. Agree the trend data route with the controls contractor in writing at the start, including what happens at turnover. Monitor for point staleness and raise a gap rather than assuming silence means healthy. And make the document to equipment relationship an explicit stored fact created when the document is received, because reconstructing it at handover is where owner turnover packages fail.

What happens when the sampling logic is never recorded?

You issue a certificate asserting that systems perform as designed, backed by testing whose extent nobody wrote down.

Nobody tests all 84 fan coil units. You test a sample and expand if failures exceed a threshold. That approach is standard, defensible and usually stated in the commissioning plan. What almost never happens is recording which units were in the initial sample, how they were chosen, what failure rate triggered expansion, and what final coverage was achieved. So the report says the sampled units passed, and the owner has no way to know whether that was eight units or thirty, or whether the eight were the ones nearest the mechanical room.

The exposure is not theoretical. The owner accepts systems on trust, and two years later the energy performance nobody verified appears in the utility bill, at which point the commissioning record is examined and found to be an assurance rather than evidence.

The fix is to make sampling an explicit rule per equipment type. The initial sample is selected by the system rather than by whoever is on site, using a stated method. The failure threshold is declared before testing starts, not negotiated afterwards. Expansion triggers automatically when the threshold is breached, and the report states coverage as a fact. Owners who have been through a poor handover care about this more than any other feature, and providers who can produce it win work on it.

Should you build custom or configure the commissioning product you already own?

If you are a small practice running a handful of concurrent projects with one or two agents, buy. CxAlloy and Facility Grid are purpose built, priced sensibly against a build, and will give you a competent issue log and checklist workflow immediately. A custom platform at that scale is an expensive way to feel organised, and the honest answer on the first call is to configure what exists.

The same applies if you are an owner commissioning a single building. Your provider will bring their own tooling, and imposing yours creates friction with no benefit to you.

Build when two or more of these are true. Your script library is genuinely differentiated and you want it versioned and reusable rather than copied into each project. You run enough concurrent projects that quality depends on which agent is assigned. You commission healthcare, laboratory or data centre facilities where documentation is heavier and sampling has to be defensible. You are an owner with a portfolio and want commissioning data flowing into your maintenance system rather than arriving as a binder. Or you want to offer monitoring based commissioning as a service, which requires trend infrastructure a checklist tool does not provide.

How do hidden costs get into a commissioning software quote?

Five items, and the largest is content rather than code.

• Migrating the existing script library. Turning a decade of Word documents into structured, versioned content with tolerances and specification links is real weeks of expert time, and it is routinely underestimated by everyone including us.
• Trend ingestion. Usually the most expensive technical component, because each building automation system is its own integration with its own access negotiation.
• Offline capture. Mechanical rooms and shafts have no signal. Offline first has to be in the first release, and retrofitting it later is close to rebuilding the field application.
• Handover into a maintenance system. Valuable, and it requires agreeing an asset data standard with the owner's facilities team early rather than near completion.
• Owner portals with per project branding. Cheap to ask for, not cheap to maintain across a portfolio.

Keep the number down by starting with mechanical and controls, which carry most of the scope, and adding electrical, life safety and specialty systems in a second phase.

What separates a commissioning build that works from one that fails?

Four things.

First, offline capture from day one. A technician who cannot record a result on the spot writes it on paper, and paper transcribed at the end of the day is where the record loses its evidentiary value. This is not a refinement, it is the difference between a system used in the field and a system used at a desk afterwards.

Second, issues classified at creation. A deficiency against the contract documents, a design issue needing the engineer, an incomplete installation that is simply not ready, and an operational adjustment have different owners and different resolution paths. Lumping them into one list is what turns the contractor relationship adversarial, and the cost of that is measured in schedule weeks. Attach the failing test step and its acceptance criterion so the contractor sees exactly what was expected, route the issue to the party that actually owns it under the contract structure, and require a linked retest before anything closes.

Third, trend findings entering the same lifecycle as failed test steps. A flagged condition such as short cycling or an economiser that never opens should become a tracked issue against the equipment record, not a graph in a report appendix. That is the difference between a system that passed a test on one afternoon and a system that is behaving correctly in operation.

Fourth, you own the repository, the cloud accounts and the right to hire anyone else. If your script library is the firm's core intellectual property, encoding it into a system controlled by someone else is the opposite of what you set out to achieve.