As the demand for energy management software (EMS) grows, the market is rising to meet it. This booming new arena is being supplied by large global companies and small, medium and start-up companies alike, all of whom are involved in some elements of building automation and IT. And new companies are entering the market on a regular basis.

This growing and rapidly changing market -- as well as the complexity inherent in buying and implementing an EMS project -- means that companies facing this process can find it quite 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.

1. 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.