Commissioning and Completions Management Software: How Do You Prove a Subsystem Is Ready to Energise Instead of Arguing About It?

The readiness meeting that nobody can settle

Thursday morning, project office, twenty people. The question is whether subsystem 2340, a cooling water loop, can be energised on Monday. The electrical contractor says his scope is complete. The instrument contractor says four loops are outstanding but two of those are waiting on a valve the mechanical contractor has not installed. The mechanical contractor says the valve arrived and was installed last week, and produces a photograph. The commissioning engineer has a spreadsheet from a fortnight ago showing 87 percent of check sheets complete, but nobody can say which 13 percent, or whether any of them are inside the boundary of subsystem 2340 as it was redrawn in March.

An hour and twenty people later the decision is deferred to next Thursday. On a project where the plant earns money from the day it produces, that hour is not the cost. The week is.

The underlying problem is that completion is a status of a boundary, and the boundary exists in a drawing markup while the evidence exists in paper packs and per discipline spreadsheets. Nobody can compute readiness because nobody can join the two. So it gets argued, and the loudest confident person usually wins, and sometimes the plant is energised with an open item that should have blocked it.

Why this breaks on general project software

A construction management system tracks progress against a work breakdown structure. Completions tracks status against a tag, and the two structures do not align. A single subsystem pulls tags from the piping scope, the electrical scope, the instrument scope and the mechanical scope, each of which sits in a different contractor's work package with a different progress claim behind it. Progress at 92 percent against the work breakdown structure tells you nothing about whether any subsystem is complete, because completion is not linear across a boundary.

The second mismatch is volume and granularity. A mid sized industrial project carries tens of thousands of tags, each attracting several check sheets. That is hundreds of thousands of records, each with a signature, a date and often an attachment, produced by people standing on scaffolding. A tool that assumes a desk and a network connection is useless at exactly the moment the data is generated.

The third is that the data has to reconcile with engineering. Tags come from the instrument index, the line list, the electrical schedules and the equipment list, and those registers change throughout construction. A completions system that took a one time export at the start is wrong by month three, and the argument in that Thursday meeting is often about a tag that was deleted from the design in April and is still on somebody's check sheet.

What SmartPlant Completions, WinPCS and hub2 actually leave you doing

Hexagon SmartPlant Completions is the heavyweight, and if your project already runs the Hexagon engineering stack the tag register integration is a genuine advantage that should weigh heavily. The trade is configuration effort and cost, which is proportionate on a multi billion dollar project and disproportionate below that.

WinPCS has been used on serious projects for a long time and is well understood by commissioning people who have worked internationally, which matters more than software buyers expect: a system your commissioning contractor's people already know saves weeks of training.

Wood GoTechnology hub2 comes with the process knowledge of a company that does this work, which shows in the model. It also comes with an opinion about how completions should be structured, and if your owner's certification hierarchy differs, you adapt.

The gaps we get called into are consistent across all three. First, the join to the owner's own systems: the maintenance management system that must be populated with the assets at handover, the document management system holding the dossiers, and the cost system reconciling contractor claims. Second, projects where several contractors need genuinely separate access with different data visibility, which gets messy in a single tenant configuration. Third, brownfield work inside a live plant, where completions has to interact with permit to work and isolation, and a packaged product usually treats that as out of scope. Fourth, cost: on a project below a certain size the licensing and configuration cost of the enterprise products is hard to justify, which is why so many mid sized projects are still run on spreadsheets that fail in exactly the way described above.

What a custom build has to include

The tag register comes first, and it must be a live feed, not an import. Tags arrive from the engineering registers with a status, and changes flow through with a revision trail so a deleted tag disappears from the outstanding list instead of haunting it. Every downstream object hangs off a tag.

Then system and subsystem structure, defined against the tag register rather than drawn on a marked up drawing and typed. Boundaries change during a project, so a subsystem needs versioning and the effect of a boundary change on completion percentage has to be visible, because that is exactly the number people will dispute.

Then the check sheet library, assigned by tag type and discipline, with the rule that assignment is automatic. A new instrument tag appears in the register and its check sheets exist within the hour. Any process where a coordinator manually assigns check sheets to tags will fall behind the drawings by week six.

Then field execution, offline first, on tablets, with the check sheet fillable by the technician who did the work, signed, with photographs attached, and synced when the device reaches signal. This is not a convenience. A commissioning technician at the top of a structure with no coverage either records it on the device or records it on paper for someone to key later, and the keying backlog is where the truth goes stale.

Then punch items, raised against a tag and a subsystem, categorised by whether they block the next certification step, with an owner, an evidence trail on closure and a re-inspection where needed. The single most valuable screen in the whole system is the one that says this subsystem is ready to energise except for these three category A punch items and these two outstanding loop tests, with the responsible contractor named against each.

Then certification, following the hierarchy the owner actually uses: mechanical completion by subsystem, ready for commissioning, commissioning complete and handover, each requiring a defined set of check sheets and punch categories closed. Certificates generated with the evidence attached, not assembled by hand in the last week of the project.

Then the dossier. Handover to operations means a package per subsystem containing the certificates, completed check sheets, test records, vendor documents and the as built references. Generating that continuously rather than at the end is the difference between handover on schedule and three months of a document controller working weekends.

One more integration is worth its own line because it changes behaviour: contractor progress claims. When a contractor's claimed percentage is reconciled against signed check sheets in the system, the argument in the Thursday meeting stops, because completion evidence and payment are looking at the same record.

Cost, timeline and what moves them

The first release runs $100,000 to $220,000 and ships in 14 to 22 weeks. That covers the tag register feed, subsystem structure, the check sheet library with automatic assignment, offline field execution and the readiness view. It should be live before construction completion, not after, because a completions system introduced at handover is an expensive data entry exercise.

The full platform with punch management, certification hierarchy, dossier generation, contractor access control, progress claim reconciliation and handover into the maintenance system runs $280,000 to $650,000 across 8 to 14 months. What pushes it up: multiple contractors with strict data segregation, brownfield interfaces with permit to work and isolation, several sites or trains, and engineering registers held in systems that were never designed to be read externally. What holds it down: one train, a settled certification hierarchy agreed with the owner before build starts, and a check sheet library adopted from your existing standard rather than redesigned during the project.

When you should not build this

A brownfield tie in with a few thousand tags, one contractor and a three month construction window does not need custom software. A packaged tool or a disciplined spreadsheet with one owner is proportionate. The build case appears above roughly 50,000 tags, with several contractors claiming against shared scope, or where handover date sits on the critical path to first production and a week of deferred decisions costs more than the software.

How to choose a developer

Ask what happens when engineering deletes a tag that already has signed check sheets against it. The right answer involves a revision trail, a superseded state and a report of affected records. A developer who has not thought about it will build an import that silently orphans data.

Ask how the tablet behaves on the fourth floor of a structure with no signal for six hours. Local storage, queued sync, conflict resolution on the check sheet and a device that still shows the assigned work while offline. Anything less pushes the field back to paper.

Ask how a boundary change affects a completion percentage that was reported to the owner last week. If they have no answer, your readiness numbers will move without explanation and nobody will trust them again.

Ask who owns the code, the repository, the cloud accounts and the completions data, and settle it before kickoff. At Digital Heroes the client owns all of it from the first commit. The handover dossier is a permanent asset record for a plant that will operate for decades, and it should never depend on a project era software contract.