Specifying Energy Management & Integration Software In a growing and rapidly changing marketplace for energy management and integration software, it’s 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.  “The energy of the mind is the essence of life.” Aristotle

Jim Sinopoli PE, RCDD, LEED AP Managing Principal, Smart Buildings LLC Contributing Editor

The market for energy management software (EMS) with integration capabilities is vibrant and growing. Demand is certainly there as building owners and facility managers need the data and information to manage energy usage. The market is being supplied by large global companies as well as small, medium and start-up companies involved in building automation and IT. New companies are entering the marketplace on a regular basis. Buying into this relatively new fluid space can be perplexing.

The procurement process for 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’s 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 are deployed in buildings such as energy management, integration platforms and other software monitoring and managing sub-systems, 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 very 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), then making an award to a contractor based on price as well as other factors.

Regardless of the process you’ll 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.

Define 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 by obtaining additional information and education regarding the marketplace to get a sense of what’s 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 more importantly will 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 to simply 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’ll 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’ll 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 a RFP. If the award of a contract is solely based on price you want to make sure that as much information as possible is quantified so the bids reflect similar efforts and deliverables. You’ll 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’s 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.

[an error occurred while processing this directive]Identify The Required Performance Of The Software. There are several performance indicators you’ll 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’s 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.
• Reliability - 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’s 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.

For more information, write us at info@smart-buildings.com.