If you think about what’s going on in our building automation industry right now, it can be a little overwhelming. IoT, cloud, IP controls, analytics, voice control, integrations, the list goes on and on. For someone who is making recommendations around what should be included or not included in a project, how do you make sense of all the technology and changes that we’re experiencing?

In order to make effective recommendations for your customers related to selecting systems, components, and processes, a project should be grounded in three principles.

Principle One

Start with the end in mind.

Yes, I know Stephen Covey said this in his book “The Seven Habits of an Effective Leader,” but this statement equally applies to those of us who consult within the building automation industry.

We must ask ourselves, what do we really want to achieve and why?

If all we care about is providing 72°F air at the lowest cost per point possible, then there’s a lot of technology that we can eliminate before we ever put them on paper. At the other extreme, if we are looking for the most immersive, frictionless tenant experience possible, then we have a slew of technologies that we can potentially use in our projects. We have to be disciplined about consistently asking ourselves, “What does this technology mean to the end I’m trying to achieve whenever we recommend or specify technology?”

Principle Two

Now we must ask ourselves with principle number two, what are the capabilities of the owner/operator to actually utilize whatever we put together?

Prior to founding my training company, I was responsible for going and creating some really complex integrations, and I can tell you one of the first questions I would always ask was, “What are the capabilities of the local team to actually utilize and maintain what we’re providing them?” Time and time again throughout my career we would come up with these amazing integrations that could do really great things. We would sell the customer on these integrations, only to come back a year or two later and find everything running in manual. That was because as soon as something stopped working, whether it was the software, hardware, or simply a process, the owner would go and put their systems in hand. Honestly, in these situations the customer was better off having a “simple” building. Quite often we’ll go and select technology without thinking of who is actually going to operate it, because the operators are very rarely involved in the construction side of our business.

Principle Three

Principle three is to go and look at the uniqueness of the technology. There are certain technologies that have stood the test of time. I think we could reasonably argue that 1K Nickel OHM temperature sensors probably aren’t going anywhere anytime soon; however, is voice really going to be the technology of choice, or is it going to be hand motion-based, or is the technology of choice for user interfacing simply going to be some sort of phone app, or are we going to use augmented reality?

If that sentence was painful to read because of all the options, imagine how painful it is to sort through all those options as a specifier, oh wait … you don’t have to imagine, you live it every day.

How do you deal with this?

When you start to get further away from the hardware, inputs, and outputs, and you start to move more toward the user-centric technologies, that’s when things get gray.

As someone who is designing technology for a project, we are best served by building the core technology into the project first.

Once that is complete, then and only then can we go and look at the outer layers of the technology. Advanced analytics, cloud-based building automation services, data and compute at the edge — all of these technologies serve a purpose on particular projects; however, all of them are dependent on us having a solid core foundation of technology, and that is what we must focus on first if we are going to actually be able to make sure that our projects achieve what we want them to achieve.

For those of you who skim articles, here is the summary:

1) Identify the use case prior to selecting the system;

2) Select systems that the end user has the ability (in skill, manpower, and desire) to use; and

3) Begin with core systems and then build out to the more advanced systems.

What are the principles you use when specifying control systems? Let us know.