Commissioning and Completions Software Problems: The 7 That Delay Handover, and How to Avoid Them

Why does completions get scoped as project progress tracking?

Because the project already has a system that reports progress and it is reporting 92 percent. Adding completions looks like adding detail to something that exists, so it gets folded into the construction management tool or handed to whoever owns the schedule.

The two structures do not align. A construction management system tracks progress against a work breakdown structure, which is organised by contract and discipline. Completions tracks status against a tag, and a single subsystem pulls tags from the piping scope, the electrical scope, the instrument scope and the mechanical scope, each sitting 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 last one percent of a subsystem can be a single loop test that blocks energisation.

The second half of the mismatch is granularity. A mid sized industrial project carries tens of thousands of tags, each attracting several check sheets, which is hundreds of thousands of records with signatures, dates and attachments, produced by people standing on scaffolding.

The fix: build the tag as the spine and hang everything off it, then define system and subsystem structure against the tag register rather than against a drawing markup someone typed up. Report readiness per subsystem, not percentage complete per contract. And get the system live before construction completion, because a completions system introduced at handover is an expensive data entry exercise rather than a control.

What goes wrong with the tag register itself?

Almost every failing completions implementation starts with a one time export. Tags are pulled from the instrument index, the line list, the electrical schedules and the equipment list at the start of construction, loaded, and never reconciled again.

By month three it is wrong. Engineering has deleted tags that were designed out, added tags from a late change, and renumbered a section after a review. The completions system keeps chasing check sheets for equipment that no longer exists, which is one of the most common causes of a disputed outstanding list in the Thursday meeting, and it misses equipment that does exist because nobody imported the addition.

Boundary changes compound it. A subsystem redrawn in March moves tags between boundaries, and any completion percentage reported before that date now refers to a different population. If nobody can explain why a number went backwards, the numbers stop being trusted, and once readiness reporting loses credibility it is argued rather than read.

The fix: make the tag register a live feed with a revision trail, so a deleted tag moves to a superseded state rather than vanishing, and every check sheet, punch item and certificate already recorded against it is reported as affected rather than silently orphaned. Version subsystem boundaries and make the effect of a boundary change on completion percentage visible and explainable, because that is precisely the number people will dispute. Ask any prospective developer what happens when engineering deletes a tag that already has signed check sheets against it, and listen for whether they have thought about it at all.

Why do the field and downstream integrations break after launch?

Field capture fails on connectivity and on assignment. A technician at the top of a structure or inside a vessel has no signal for six hours. If the device cannot show assigned work and accept a completed check sheet offline, the work gets recorded on paper for somebody to key in later, and the keying backlog is where completion status goes stale. That is the exact problem the system was bought to solve, reintroduced through the front door.

Check sheet assignment fails through manual process. A coordinator assigning check sheets to new tags by hand falls behind drawing revisions by about week six, and once the assignment lags the outstanding list stops reflecting reality.

Downstream, the handover integrations break on scope. The maintenance management system needs to be populated with assets at handover, and the mapping from a construction tag to a maintainable asset is not one to one, so a mapping designed late produces either duplicate assets or missing ones. The document management system holding the dossiers has its own numbering and revision rules that nobody checked against the certificate structure.

The fix: offline first field execution with local storage, a sync queue, conflict handling on the check sheet and assigned work visible without signal. Automatic check sheet assignment by tag type and discipline, so a new instrument tag has its check sheets within the hour without anyone acting. And agree the tag to asset mapping and the document numbering convention with the owner's operations team during design rather than in the final month.

What happens when punch categories and brownfield interfaces are not covered?

Punch lists get built as a list. Items are raised, assigned and closed, and everyone assumes the important ones will be obvious. They are not, and the consequence is that a subsystem gets certified with an item open that should have blocked it, or, more often, certification is held up by items that should have been carried into operations.

The rule that makes punch management useful is categorisation tied to certification. Category A items block the next certification step, typically anything affecting safety, function or the ability to energise. Category B items can be carried into operations with an agreed owner and date. Once that rule is enforced by the system rather than negotiated in a meeting, most of the value has been captured.

Brownfield work carries a second gap that packaged products often treat as out of scope. Commissioning inside a live plant has to interact with permit to work and isolation, and a completions system that does not know whether an isolation is in place is providing readiness information that is dangerous to act on.

The fix: raise punch items against a tag and a subsystem, categorise them by whether they block the next certification step, require evidence on closure and re inspection where the item warrants it, and enforce the certification rule mechanically. For brownfield, scope the interface to permit to work and isolation explicitly at the start, because retrofitting it means changing what a readiness view means after people have started relying on it.

Should you build custom or configure what you already own?

If your project already runs the Hexagon engineering stack, evaluate SmartPlant Completions seriously. The native tag register integration is a genuine advantage, and tag register drift is where most completions data problems begin, so solving it natively is worth real money. The trade is configuration effort and cost, which is proportionate on a very large project and disproportionate below that.

WinPCS has long field credibility and commissioning people who have worked internationally often already know it, which saves weeks of training that nobody costs. Wood GoTechnology hub2 brings the process knowledge of a company that does this work, along with an opinion about how completions should be structured, and if your owner's certification hierarchy differs you adapt to it.

A small brownfield tie in with a few thousand tags, one contractor and a three month window does not need custom software at all. A packaged tool or a disciplined spreadsheet with one owner is proportionate, and we would say so.

Build above roughly 50,000 tags, where several contractors claim progress against shared scope, where the system has to reach into the owner's maintenance, document and cost systems in ways packaged products treat as out of scope, where contractors need genuinely separated data visibility, or where enterprise licensing is disproportionate to a mid sized project and the alternative is the spreadsheet that fails in the way described above.

How do hidden costs get into the quote?

The check sheet library treated as content someone will supply. Deciding which check sheets apply to which tag types, in which discipline, at which certification step, is substantial work, and redesigning the library mid project rather than adopting your existing standard reliably loses two months.

Contractor data segregation priced as user permissions. Several contractors who must not see each other's data, while the owner sees everything and a commissioning contractor sees a slice, is an access model with design and testing behind it.

Engineering register integration priced as an import, when registers held in systems never designed to be read externally need extraction work and each has its own revision behaviour. Multiple trains or sites, each bringing its own numbering conventions and local practice, so the second is never a copy of the first.

The certification hierarchy itself. If the owner has not agreed mechanical completion, ready for commissioning and handover criteria before the build starts, the design will change mid project and everything already recorded has to be reconsidered.

From Digital Heroes delivery experience, a first release with the tag register feed, subsystem structure, an automatically assigned check sheet library, offline field execution and readiness reporting runs $100,000 to $220,000 over 14 to 22 weeks. A full platform adding punch management, the 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 separates a build that works from one that fails here?

Live before construction completion. A completions system that arrives at handover is recording history rather than controlling it, and the return disappears with the schedule it was meant to protect.

One screen that settles the meeting. The most valuable view in the whole system 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. If a proposal does not describe something close to that, the Thursday meeting will still be an argument.

Progress claims reconciled against signed check sheets inside defined boundaries. When completion evidence and payment read the same record, the monthly claim conversation becomes a data review rather than a negotiation, and field behaviour changes quickly because signing off work in the system becomes the route to getting paid for it.

Dossiers generated continuously rather than assembled at the end. Certificates, completed check sheets, test records, vendor documents and as built references accumulating per subsystem as the project runs is the difference between handover on schedule and three months of a document controller working weekends.

Ownership settled before kickoff. You should own the repository, the cloud accounts and every completions record. At Digital Heroes the client owns all of it from the first commit, which matters more here than almost anywhere, because the dossier is a permanent asset record for a plant that will operate for decades while the software was built for a project with an end date.