1) No one wants to absorb the risk associated with “smart building” infrastructure; and

2) Because IT infrastructure is often not installed until right before occupancy, how can you test your “technologies?”

Addressing the elephant in the room

The next time XYZ company talks to you about its smart building technology or platform, ask that company’s leaders how many sites the technology was sold to at a profit. This is the dirty little secret behind many technologies. The marketing would suggest that if you’re not specifying advanced smart buildings, then you’re behind the times. The reality is most of the market is barely adopting technology into their specifications.

I’m taking the time to point this out so that you don’t spend every waking hour worrying that a lack of “smart building” specifications precludes you from winning out in the market.

At this point you may be thinking, “OK, Phil, what does this have to do with specifying technology?”

Everything…

Picking the winner

Specifying, or rather trying to specify technology on a plan and spec project, is just plain dumb. When you approach a technology-centric project or at least a use case that requires technology to execute it, you need to make sure you stack the chips in your favor.

First, you need to ensure the project delivery model will support multiple iterations. We all know (at least I think we do) that the path from concept to CDs can take years. The rate of change within our space is quick — not fast but quick. This means you must adopt or influence the adoption of a delivery model that will support the multiple iterations that are required for technology.

Second, you need to ensure that the budget has flexibility for both material and labor. Often, technological costs will decrease, but that isn’t always the case. It is, however, my experience working on hundreds of projects that commissioning and testing of technology is almost always a cost overrun. You cannot utilize the same cost model for traditional functional testing in a technology project.

But, specifiers don’t have to worry about project costs, right? After all, that’s why we have the bid system. If only that were true. The issue is that you will be called out when projects get value engineered and systems don’t work. And, ultimately, these callouts will diminish your already low profit margin percentage.

Let’s get tactical

Here is a two-step approach that has worked for me.

1) Step one: engage the owner. You rarely specify a technology just because. Technologies are often specified to fulfil a use case. Therefore, engage the owner from a holistic standpoint. If they want an integrated CMMS suite that also supports mobile work order tickets throughout the campus, then it makes sense to engage corporate IT and ensure they have the Wi-Fi, BYOD, and other infrastructures to support the solution

2) Step two: use work packages. Write up a use case and create a technology matrix that defines the technologies required by the use case. Put the work package out for bid. Have the respondents’ architecture the solutions including the spec language. Bonus points if you have the work package respondents coordinate IT infrastructure conversations with the owner.

I know that seems simplistic, but trust me, this works so much better than simply going and grabbing reference architectures and cut sheet data. I know, I know, you’d never do that, but many engineers are doing that exact thing. I’ve seen a fair bit of specifications lately that include copy-and-paste architecture diagrams directly off technology manufacturers’ websites.

In our next article, I will be discussing one of the most exciting technologies you should seriously be considering adding to your designs, and if you do this right, you have the potential to open up a reoccurring line of revenue that will help you generate predictable revenue long past the construction phase of your engagement.

As always, feel free to reach out and let me know what questions and thoughts you have on the topic.