Startup and functional performance testing get used interchangeably in a lot of project conversations, and on the surface it's easy to see why - both happen around the same point in a project, both involve turning equipment on, and both produce the recognizable ceremony of a system coming to life for the first time.
They are not the same activity, and conflating them creates a specific risk: an owner who believes a system has been validated because it started up successfully may be accepting a system that has never actually been tested against the performance it was designed to deliver.
Startup Confirms a System Runs. Functional Performance Testing Confirms It Performs.
Startup is the process of energizing equipment, verifying safe operation, and confirming that a system runs without immediately failing or triggering a safety shutdown. It's a necessary step and it answers a real question - does the equipment operate - but it's a narrow one.
Functional performance testing answers a different, broader question: does the system perform to the specific sequence of operations and design intent it was engineered for, across the range of conditions it will actually encounter in operation. That includes testing failure modes, interlocks, and sequences under conditions startup alone rarely exercises - what happens when a chiller fails over to backup, when a UPS transfers load, when a control loop has to respond to conditions at the edge of its design range.
Where Owners Get Exposed
The exposure shows up when a project schedule is under pressure and startup gets treated as sufficient evidence that a system is ready for substantial completion. A system that starts up cleanly can still fail functional performance testing - control sequences that don't match the design intent, equipment that performs outside spec under partial load, interlocks that don't behave as engineered - and none of that shows up until someone actually tests for it.
The commercial risk compounds from there: accepting a system based on startup alone means accepting it before it's been validated, which weakens an owner's position if a performance issue surfaces later and the contractor points to a successful startup as evidence the system was delivered as contracted.
Frequently Asked Questions
Does every system need full functional performance testing before acceptance?
Systems central to the facility's operation and safety - mechanical, electrical, instrumentation and controls, and process systems - should be functionally tested against their design intent before an owner accepts them, not just started up.
Can startup and functional performance testing happen at the same time?
They're sequential by necessity - a system has to start up successfully before it can be functionally tested - but they should be tracked and documented as distinct activities with separate acceptance criteria, not collapsed into a single milestone.
Who should be responsible for confirming the difference is being respected on a project?
Independent commissioning oversight, reporting to the owner rather than the contractor, is the mechanism that keeps startup and functional performance testing from being blurred together under schedule pressure.
Building the Distinction Into the Schedule and the Contract
The fix is not complicated in concept: define startup and functional performance testing as separate milestones in the schedule and the commissioning plan, each with its own acceptance criteria, and don't let substantial completion hinge on the former standing in for the latter.
Owners who hold that line get what they're actually paying for - systems that have been proven to perform as designed, not just systems that turned on.
