The 5 Most Expensive Sentences in Building Automation
- Nicole Niles
- Jan 27
- 3 min read
Updated: 7 hours ago
If you’ve spent any time in building automation, you start to hear the same phrases over and over again.
They’re almost never said with bad intent. Most of the time, it’s good people trying to keep a project moving.
But over the years, I’ve learned that certain sentences are quiet warning lights. They usually mean we’re about to trade clarity now for pain later. And that pain shows up as rework, confusion, long nights, and strained teams.
Here are five I hear a lot — and what they usually tell me.
1) “It’s just one more point.”
This is often where scope starts to drift without anyone really noticing.
Because that “one point” rarely stays small. It touches programming, graphics, alarms, trends, testing, documentation. If it isn’t acknowledged and tracked, it shows up later as confusion and rework.
Adding the point usually isn’t the problem.
Not managing it is.
What I try to say instead:“ Happy to do it. Are we treating this as a change, or are we replacing something already in the scope?”
2) “We’ll figure it out in programming.”
This usually means the intent hasn’t been fully decided yet.
And I understand why it happens. Construction moves fast. Decisions feel urgent. But when ambiguity gets pushed downstream, programming becomes the place where design decisions get made under pressure. Startup turns into debate instead of verification.
That’s not fair to the programmer — and it’s not good for the project.
What I try to say instead:“ Let’s clarify the intent now, even if it’s a simple version. We can refine it later, but we need something clear to build and test against.”
3) “Can you just…?”
“Can you just…” is almost always coming from someone who’s under pressure.
Not malicious. Just trying to solve a problem quickly.
But that word just has a habit of hiding real effort. What sounds small can turn into hours of unplanned work that no one tracked, prioritized, or accounted for. That’s how teams slowly get stretched thin without realizing it until it hurts.
What I try to say instead:“ Yes — what’s the deadline, and what priority does this replace?”
4) “That’s standard.”
Standard for who?
The engineer. The owner. The GC. The commissioning agent. The maintenance team. The last job. This job.
In building automation, “standard” can be helpful — or it can skip the one conversation that actually matters. When expectations aren’t aligned, you can end up with a system that technically checks all the boxes but doesn’t match how the building will really be operated.
What I try to say instead:“ Here’s how we typically do it. Does that align with how your team will run the building day to day?”
5) “It’s all BACnet, so it’s open — just program it.”
This one causes a lot of frustration because there’s a misunderstanding baked into it.
Yes, BACnet is an open protocol. It allows devices to communicate.
But BACnet does not automatically mean:
everything is exposed the way you expect
everything is writable or configurable
programming access is available (or allowed)
other vendors will share tools, passwords, or sequences
the integration will be clean without coordination
In the real world, open protocol doesn’t always mean open access. When that assumption gets made early, the limits tend to get discovered late — usually when the schedule is tight and everyone is counting on it.
What I try to say instead:“ We can integrate via BACnet. Let’s confirm what’s actually available: which points are exposed, what’s read vs. write, who owns programming access, and who supports it after turnover.”
The funny thing is — I’ve said versions of every one of these myself. Most of us have.
The difference isn’t that good teams never hear these phrases. It’s that they recognize them as signals and slow down just enough to get clear before the project pays for it.
Because in building automation, the biggest costs usually aren’t in the hardware.
They’re in the assumptions no one said out loud.
Nicole Niles
Comments