Definition Through Elimination
I believe strongly, however, in a few things that commissioning is not. For example, commissioning, in general terms, is not the transfer of responsibilities from the project team members typically responsible for them to the commissioning provider (CP). The CP should not be introduced to a design and construction project as someone who will relieve the designers, contractors, construction managers, or owner of their normal contractual obligations.The CP should be introduced as someone who will facilitate a process and team approach that will help all team members perform their responsibilities efficiently and successfully. The testing at the end of the commissioning process should be seen as the team's demonstration that they have been successful in delivering properly functioning facility systems in a preplanned, organized, and well-documented manner.
With respect to BAS, I believe there are some CPs who believe their real work starts only when the construction phase nears its end. I've noted a number of times in the past that simply testing at the end of construction is not commissioning. That approach typically turns into problem identification, fingerpointing, and probable missed schedule deadlines - not the desired result from a well-orchestrated team commissioning process.
Keeping The Definitions In Focus
What I want to focus on in this month's column is my opinion that commissioning is not startup and fine-tuning of BAS (or any other system, for that matter). I understand there are a few CPs who wait until the controls contractors are complete with their installation and programming and then enter the scene to perform the programming checkout and to "tune" the control loops.In typical project specifications, the controls contractor is responsible for both of these activities. To introduce the CP as the person who will be doing, or at least directing, the startup and tuning may bring a level of confusion regarding who is responsible (liable) for the controls system performance. In my opinion, if there are any "problems" later on (i.e., after project completion and the owner assumption of operational responsibility), the controls contractor will try to use this usurpation of his responsibility/authority as a contractual release from liability.
Conversely, the CP is not likely to step up to the plate and admit full responsibility (liability) for the operational issues. The owner will be back to the standard fingerpointing exercise sometimes found on noncommissioned projects when issues arise after construction is complete.
Another one of my regular mantras over the years has been that the CP needs to be a third party - defined as someone who is solely responsible for verifying the functional performance and quality assurance aspects of a project and who has no responsibilities with respect to design engineering, installation, or quality control functions. When the CP takes on all or some of the specified responsibilities of the controls contractor (e.g., startup and tuning), the CP is blurring the lines between unbiased third-party verifier/documenter and installation contractor.
I believe that the CP is absolutely responsible for developing, directing, and documenting verification procedures that test the controls contractor's programming and loop tuning work. However, the CP will overstep the bounds of his authority if he directs the contractor to make changes or, worse, makes changes unilaterally without going through the appropriate communication channels.
Commissioning is not redesigning or reprogramming the controls system, but documenting that the control system performs as specified and as defined in the design intent document. For the CP to step outside of the realm of "review, test, document, and train" is for the CP to subject the project team to confusion regarding responsibilities and to take on far more liability than most CP typically sign up for. ES
