Specifying Energy Management and Integration Software for Buildings
The procurement process for an energy management system (EMS) in new construction would typically use a design-bid delivery method where requirements are specified and the qualified bidder with the lowest bid is awarded the job. It is a process that may work well when the procurement is for hardware or equipment and materials where very specific requirements have been identified or calculated. However, as more software applications, such as energy management, integration platforms and other software monitoring and managing sub-systems are deployed in buildings, , and these applications need to be configured, customized, have special dashboards developed, or require integration into business systems, the procurement of the software through a “low” bid process can become complicated. Existing buildings may use what is likely a better process to procure an EMS, which is, issuing a request for information (RFI) to the marketplace followed by a request for proposal (RFP), and then making an award to a contractor based on price as well as other factors.
Regardless of the process, you will want to present clear software specifications to potential contractors including the quantification of as many variables as possible. What follows are some “do’s and don’ts” in pulling together software specifications in order to truly reflect the client’s needs and environment, and clearly convey the information to the potential contractors.
- Defining What the Software Is Supposed to Do
Some software for specific applications may be “out of the box” or “one size fits all” applications, while other software, especially enterprise-level products and those involving system integration, will take some customizing. In addition to integration and energy management software applications, clients may need applications such as fault detection and diagnostics, predictive analytics, alarm management, trending, automated demand response scenarios and document management. Clients may benefit from obtaining additional information and education regarding the marketplace to get a sense of what is available and doable; however, they should realize their requirements are not marketing wish lists. This “programming” exercise needs to include various groups within the client’s organization such as facility management, facility engineers, IT, the design team and possibly business executives. The result of this effort should delineate what the software has to do, clearly and concisely identifying the functionality that the client wants in the software.
This piece of the procurement project is critical; vagueness in stating your functional requirements will not only drive up the price as bidders assume more risk but it will also, and more importantly, probably result in a less than successful software implementation. A study by the Standish Group found about half of IT projects were “challenged,” that is over-budget, over schedule and with less functionality. Why were they challenged? Incomplete requirements and specifications, lack of user input and changing requirements and specifications — all of which are related simply to not doing it right in the first place.
- Identify the Required Dashboards or User Interfaces
This is really an exercise in identifying who in the organization needs or can use the building data or energy information generated by the software. For energy management, this could mean everyone from the facility engineer to the business executive to the general public; each group will need varying information displayed in different ways. Many vendors will have standard dashboards or at least the dashboards created for their last client; this may be a starting point in deciding on what you require. Make a list of all the dashboards required, including those for each individual piece of equipment, summary dashboards, drill down dashboards, those for particular spaces or zones and special dashboards. The dashboards are what many clients see as the project deliverables.
- Identify the Integration or External Interfaces Required
If the software is focused on energy management, you will need to connect into the BMS, a power management system and metering for electric, natural gas, steam and water. You may need network controllers, additional software or even an upgrade to the latest software for a BMS to access its database. Beyond that, however, you will probably need data from external systems such as weather data, energy budgets and costs from the organization’s financial software, utility rate structures, occupancy data and schedules — all of which require some external interface. The bidder must know how to interface into all these systems, which party is responsible for additional hardware or software related to interfacing systems and the format of the data.
- Provide a Basis for a Bidder to Estimate Costs
This is where a “hard” bid is different than an RFP. If the award of a contract is based solely on price, you want to make sure that as much information as possible is quantified so the bids reflect similar efforts and deliverables. You will want to identify the number of data points, the number of dashboards, the number of applications, the hardware requirements, the availability of control drawings, what is to be supplied by the client’s IT department, the IT department’s standards for hardware and software, the specifics of the energy control systems, other sub-systems to be integrated, the responsibilities and required coordination of contractors for the sub-systems and the project schedule. The number of data points is fundamental to pricing many software applications because each point needs to be configured in the software. This is a task to quantify the requirements of the programming document as much as possible.
- Identify the Required Performance of the Software
There are several performance indicators you will want to identify:
- User Response Time
This is the top concern for most users; the dashboards may look great, but if it takes a while to respond users are impatient and unhappy. Response time may be affected by whether the software is a remote hosted solution or on site.
- Throughput on the System
The issues here are network bandwidth, latency, transmission overhead and the performance of the network. It is not uncommon for a decent size building to have tens of thousands of data points or for a campus or enterprise to have hundreds of thousands of data points. Depending on the polling interval and the method of obtaining data, acquisition of the data from a site could be affected by inadequate network throughput.
- Scalability of the System
Most enterprise-wide deployments start on a small scale such as a pilot project and upon acceptance of the results are ramped up to a campus or all buildings in the real estate portfolio. You need to know how both the hardware and software scale, with special attention to the scaling of the database.
This deals with redundancy, recovery time of software functions, resource utilization, backups of hardware and software, data loss and connectivity. If you are using a hosted solution on an enterprise basis and lose connectivity to a building, what happens to the building’s data?
- Identify the Testing, Acceptance and Handoff Process
Much of what happens during the close-out and handoff of the software implementation is simply related to good project management. Here are a few suggestions: (a) Establish a review and approval process for customized dashboards as to not get caught in an endless loop of revisions and reviews. (b) If the installers are different than the manufacturer of the software, get the manufacturer’s representative to manage startup of the completed system. (c) Address the warranty period including emergency and non-emergency services, vendor response times and software upgrades and changes. (d) Have the contractor provide initial formal training and refresher training during the warranty period. (e) Require that the vendor prepare a user manual specific to your configuration. (f) Obtain all hard and soft copy documentation related to the installation, including record submittals.
In a growing and rapidly changing marketplace for energy management and integration software, it is important to take a methodical approach in the procurement and deployment of an EMS and focus not so much on the marketplace but rather your unique requirements and building operations.
Jim Sinopoli is the managing principal at Smart Buildings, which provides engineering and consulting services for the design and operation of integrated building technology systems. His background is in construction practices, design, procurement, project management, and building systems and operation, with a particular focus on monitoring and managing a building’s performance.
He has a bachelor of science degree in aeronautical engineering from Purdue University and a master of arts in applied science and environmental management degree from Governor’s State University. He is a licensed professional engineer, an accredited LEED professional and a registered Communications Distribution Designer.
- Operationalizing EHS Management: Bridge the Gap from Strategy to Execution
- 2016 Energy and Sustainability Predictions Findings from Facilities Professionals
- There’s Money in the Trash
- Advanced Rooftop-Unit Control (ARC) Retrofits: Field Demonstrations Validate Energy Savings
- Choosing the Correct Emission Control Technology
- The Corporate Sustainability Professional's Guide to Better Data Management
- Four Key Questions to Ask Before Your Next Energy Purchase
- Approaches to Managing EHS&S Data
- 2015 Insider Knowledge
- eBook: Five Key Considerations for Integrating Renewables into Your Procurement Strategy