Installation Is Complete. Why Is Commissioning Still Not Ready?
Commissioning often exposes incomplete dependencies hidden by installation progress: energisation, controls, interfaces, records, access, approved settings and upstream systems. Physical completion is only one prerequisite.
The short answer
Installation completion does not guarantee commissioning readiness.
A system can be physically complete and still unable to test because energisation, controls, upstream systems, approved settings, access, records or another contractor’s work are not ready.
Commissioning is where hidden dependencies become visible.
The best projects manage those dependencies before specialist teams arrive and start waiting.
Commissioning is the first time the project asks the whole system to work together
Installation can be divided.
One trade installs equipment.
Another runs power.
Another installs controls.
Another completes pipework or ductwork.
Each package can appear complete on its own.
Commissioning asks whether the interfaces work together.
That is a very different test.
The pump is installed, but is power available?
The controls are wired, but is the final software loaded?
The equipment is energised, but is the upstream system clean and ready?
A system can therefore look complete in construction terms while remaining immature operationally.
Specialist teams are expensive to mobilise into an unready system
Commissioning engineers and vendor specialists are often limited resources.
Bringing them to site before prerequisites are ready wastes more than their time.
It can also consume testing windows, client confidence and programme float.
The readiness review should therefore happen before mobilisation.
What needs to be energised?
What records must be available?
Which interfaces must be complete?
Which permits or safety conditions apply?
Which other systems must be running?
The objective is not a giant checklist.
It is to prevent obvious dependency failures from being discovered during the test.
Testing sequences reveal whether the programme understood dependencies
Commissioning is highly sequential.
One test may depend on another system.
Functional testing may depend on static testing.
Integrated testing may depend on several packages being complete at the same time.
If the programme treats these activities as independent, commissioning will expose the error.
This is why completion control has to connect physical installation with acceptance and system readiness.
The commissioning sequence is often the most honest picture of whether the project’s interfaces are genuinely resolved.
Failed tests are not all the same
A failed test can mean defective installation.
It can also mean incorrect settings, incomplete upstream conditions, temporary configuration or a test performed too early.
The cause matters.
If every failed test is treated as a quality defect, the project may blame the wrong trade.
If every failure is dismissed as commissioning adjustment, genuine defects may remain hidden.
The test record should capture enough context to distinguish the condition.
What was being tested?
Under what configuration?
Which prerequisites were confirmed?
What actually failed?
What changed before retest?
That evidence becomes valuable during final acceptance.
Commissioning records should become handover records automatically
Testing creates some of the most important evidence the client will need.
Results.
Settings.
Certificates.
Witness records.
Performance data.
If those records remain inside a temporary commissioning folder and are reorganised only at handover, closeout becomes harder than necessary.
The information should move progressively toward the final asset record.
That makes the handover package more reliable and reduces the risk of losing specialist evidence after teams demobilise.
Commissioning should therefore be designed with the final record in mind.
The client’s witness plan can become a programme constraint
Some tests require client, consultant or authority witness.
Those appointments need planning.
If the project treats witness attendance as an administrative booking after everything else is ready, the system may sit complete but unable to achieve formal acceptance.
The witness requirement belongs in the sequence.
Who must attend?
What notice is required?
What evidence must be submitted first?
What happens if the test fails and a new slot is needed?
These conditions can have real programme effect.
Integrated testing is where package boundaries disappear
Individual subcontract packages can pass their own tests and the building can still fail as an integrated system.
Fire alarm interacts with lifts.
Controls interact with mechanical systems.
Power failure affects emergency systems.
Access control interacts with life safety or security sequences.
Integrated testing reveals whether the project has managed the whole asset rather than separate packages.
This is often one of the last places where interface weakness becomes visible.
By then, recovery can be difficult.
That is why integrated commissioning should influence design coordination and package planning much earlier.
Commissioning can also reveal whether responsibility boundaries were designed well.
When a test fails between two systems, each package may be technically compliant on its own while the interface remains unresolved.
If this happens repeatedly, the issue is not just commissioning.
The project may have divided scope in a way that left integration ownership unclear.
That lesson belongs back in procurement and contract packaging on future projects.
Commissioning also changes the meaning of progress.
A mechanical system may be physically installed at 100% while the functional result remains unproven.
For management, that distinction matters because the remaining risk is not visible in installed quantity.
The project may still face failed tests, control changes, balancing, tuning or integration work.
These activities can consume specialist time and create programme uncertainty late in the job.
A credible completion forecast should therefore recognise commissioning maturity separately from installation.
This is particularly important for systems with several stages of testing.
Static checks.
Pre-functional testing.
Functional testing.
Integrated testing.
Client or authority witness.
Each stage reduces uncertainty, but none should be confused with the next.
The project can use these states to understand where risk remains concentrated.
For example, a package may have completed all static testing but still depend on a central control system that is not ready.
The package is advanced, but not yet capable of final acceptance.
This kind of visibility helps management focus on interface dependencies rather than pushing individual trades to declare completion prematurely.
It also improves vendor mobilisation.
Specialists can be brought to site when the correct prerequisites are genuinely ready.
That reduces wasted attendance and protects limited testing windows.
Commissioning planning therefore has a strong resource dimension.
The project is not only sequencing systems.
It is sequencing specialist knowledge, client witnesses and test conditions.
When these elements are managed together, the final phase becomes far more predictable.
When they are not, installation completion creates false confidence right up until the tests begin.
Commissioning readiness should also influence how the project thinks about temporary systems.
Temporary power, temporary controls, bypass arrangements or incomplete upstream services can help testing begin earlier.
They can also create results that do not represent final operating conditions.
The project should be clear about what each test actually proves.
A successful test under temporary conditions may demonstrate equipment function without proving integrated system performance.
That distinction prevents premature confidence.
It also helps the client understand which milestones represent genuine operational readiness and which are intermediate technical checks.
As commissioning progresses, the project should reduce temporary assumptions and move toward tests that reflect the final asset configuration.
That progression is what turns installed equipment into a proven system.
Commissioning data can also improve the remaining programme. If one system repeatedly waits on the same upstream dependency, later test sequences should be replanned rather than assuming the original logic will suddenly work.
That feedback makes later commissioning windows more credible and reduces repeated specialist mobilisation.
It also gives the client a more reliable picture of which systems are genuinely ready for operation rather than merely installed.
Where Epicor Saturn fits in testing and commissioning control
Epicor provides the enterprise-grade ERP foundation for approvals, purchasing, commitments, finance and governance. Epicor Saturn adds the construction and engineering project layer that connects system readiness, subcontract packages, milestones, site records and project cost.
That connection helps testing and commissioning remain part of the same project control model rather than a separate late-stage exercise.
Epicor Saturn provides the project-centric industry structure while Epicor supplies the enterprise-grade transactional foundation underneath it. Explore Epicor Saturn for construction and engineering.
Frequently asked questions
Is installation completion enough to start commissioning?
Not necessarily. Energisation, controls, upstream systems, access and records may still be incomplete.
Why do commissioning teams often spend time waiting?
Because dependencies across multiple trades and systems are discovered too late.
Should failed tests always become defects?
No. The cause may be incomplete prerequisites, settings or test configuration rather than defective installation.
Why connect commissioning records to handover early?
Because the test evidence will be required for final asset acceptance and should not be reconstructed later.