Integrated Systems Project Management Process (ISPM) Overview The most valuable and least used word in a project manager's vocabulary is No. The integration of multiple building monitoring and controls systems is a very complex process involving multiple systems manufacturers, installers and contractors, multiple software platforms and communication protocols resulting in typically large databases of information. Whether new construction or renovation, project management is essential to the successful completion of any project. However, project management of integrated systems requires a very different skill set not readily available in today s marketplace. Unlike traditional project management, Integrated Systems Project Management (ISPM) has a specific focus on software platforms, communications methodologies, device naming conventions and database creation for each building system and the Enterprise or Integration System Software Platform. New Construction The ISPM process starts with the systems design for each building element including the Building Automation, Power Monitoring and Control, Security Access Control, Life Safety, Lighting Control and any other microprocessor based system that has the ability to share information with other systems. 1
Contractors Owner/Client Interior Designers Architect Civil Engineers Mechanical Engineers Construction Manager Electrical Engineers The typical design approach is to specify an open protocol system based on industry standard communications such as BACnet, Lonworks, Modbus, SNMP, OBIX and many others including wireless device technology. It has been the role of the Building Automation System vendor to integrate these systems either as part of the traditional Division 15 scope of work or as a separate scope under Division 25 with each system being provided under different divisions of electrical and mechanical. But the expected results in this typical approach have not met design and client expectations and have been expensive. There has been too much emphasis on communications protocols and technology gadgets and not enough attention on the intricacies of system databases. This compounds the issues with the integrated architecture for a large project. The ISPM process needs to start at Design Development with identifying the end result (client s goals and objectives) in the use of technology to operate the facilities regardless of the size of the building or portfolio of buildings. The database definitions are the result of specifying not just the physical points and types of information but must include all data that will be used by the Integrated System Software to accomplish the stated objectives. A single temperature sensor or device contained within a DDC system that uses the BACnet protocol may have as many as 30 data values for each BACnet object. Because the BACnet protocol supports Auto-Discovery, all 30 data values may be in the database at multiple levels of the system architecture. How many of those values are actually going to be used by the software and more importantly by the end user to manage their facility is just one aspect of the IBPM process that needs to be included in the overall systems design. Another aspect is the device (sensor) naming convention used by vendors that is used by all the software platforms. This one aspect has been one of the most difficult, time consuming and expensive parts of trying to implement a fully Integrated Building Systems project. To resolve this issue the IBPM process should define the naming conventions as part of the design for 2
each system which all vendors must follow. The device naming conventions can be part of the vendor selection pre-qualification and submittal approval process for all systems to ensure conformity and standardization of database creation. Retrofit/Existing Buildings A retrofit or existing building Integrated Systems project is even more complex than new construction when dealing with multiple systems manufacturers, different generations of hardware and software, no standard naming conventions, legacy communications protocols and outdated software platforms. One of the steps that have been typically missed in a project site survey process is an Existing Database Analysis. This is more detailed than collecting the Points List from various systems and needs to include the evaluation of the device naming conventions. Depending on the age of a system and if it has been expanded over the years, it is not uncommon to find different naming conventions in different controllers and databases within the same system. Multiply that over a large campus or portfolio of buildings and the issues can compound the reality of being able to deliver a fully integrated system solution. It is common for the Systems Integrator vendor or contractor to convert all the device names within the IS normalization database. This can extend project schedules dramatically and add costs which causes budget issues. It is better to include the Database Analysis in the site survey process and provide the Systems Integrator with all the device names that would need to be converted as part of the design and procurement process. Depending on the results of the Database Analysis it may be more cost effective to have the system vendor revise the naming conventions to a common standard prior to implementing an Integrated Systems project. Another result of the Database Analysis is validating the operating conditions of the systems. Due to no or limited systems commissioning, expansions and changes to the systems over time, the analysis will validate the physical and data point 3
conditions separate of the typical sequence of operations. This will save many hours, days or months of the implementation schedule and results in lower overall project costs with a better quality solution. Post Commissioning Database and Performance Analysis Part of the goals and objectives of an Integrated Systems project is to reduce the total cost of operation (TCO) over the life cycle of the building(s. The TCO usually includes energy, operations and maintenance costs per square foot, per department, per building or may include a matrix of performance indicators. Systems commissioning has traditionally validated the sequences of operations of all the systems against the design documents but has not included detailed analysis of performance measures from a more holistic perspective. A traditional cooling sequence of operation commissioning would validate that 55 degree air is being delivered by an air handler to the space to maintain a 70 degree comfort level and that 45 degree chilled water is being delivered to that air handler at a specified GPM. What it does not include is the analysis of how many spaces are actually in a cooling load, does the load need 55 degree at a certain CFM and does the load really need 45 degree water at a certain GPM. Determining what percent of CFM and GPM is really required to maintain the load and can those variables be reduced at any given time to reduce energy is a part of the Performance Analysis that should be part of the Integrated Systems Database. The Post Commissioning Database and Performance Analysis would include any algorithms or software based on principles of Fault Detection and Diagnostics for enhanced mechanical and systems performance while reducing the energy costs. The Analysis would also include relational data shared with multiple systems to accomplish specified sequences or performance. All of this would be first identified in the design documents for new and retrofit projects so all systems providers and the client will understand the expectations and there will be validation of the performance above the traditional commissioning. ISPM Coordination and Implementation 4
Any large project may have a Construction Manager in addition to a General Contractor with various sub- contractors especially in new construction. Regardless of the contracting structure the delivery of an Integrated Systems project requires close coordination across all trades to help manage the schedule and costs. The devil is in the details of not only knowing the systems scope but also understanding the technology and delivery of those systems to accomplish the goals and objectives per the schedule and budget. The other aspect is the typical change order issue which is almost a standard by-product of a large complex project. The ISPM process is parallel and equal to the standard contracting process and as a checks and balance should review and approve any change order that would be generated by systems vendors with a special focus on technology and schedule impact for all systems. A mechanical contractor substituting a piece of equipment that has an embedded microprocessor controller that results in the Systems Integrator having to provide a communications gateway or translator and changes the naming conventions that impacts the database generation and increases the SI schedule would not be acceptable. This is one of the roles of the ISPM process that can add significant value to the overall project. But the ISPM cannot be part of the traditional contracting tier because it needs direct communications with the owner, architect and design engineers and cannot be a conflict of interest within the traditional tier. The overall complexity of an Integrated Systems project needs specific focus and autonomy to help deliver the expected end results. Integrated Systems Information Management (ISIM) A fully integrated systems project will result in new levels of additional information just like other financial or business level software systems that will be used by the owner to help manage their business. The ultimate success factor of all integrated systems project is if the raw data from all the systems is delivered in an easy to use and understand Integrated Systems Information Management (ISIM) platform including GUI and Information Dashboards, reporting and performance analysis. In addition to the above objectives of the ISPM, defining and delivering the ISIM for the owner is the final measurable result of the project. All the raw data in all the systems is meaningless unless the owner can use it in way that fits the business and meets the project objectives. The 5
business objectives need to drive the design and delivery processes resulting in a usable tool with validated data regardless of the technology underpinning and methodologies. This single objective is why an Integrated Systems Project Management Process needs to an integral part of every project. For more information, write us at info@smart-buildings.com. 6