There’s a pattern we’ve noticed over years of working on building automation and controls projects across New Zealand. The projects that go smoothly, the ones where the building performs the way it was designed to, where the client is happy, and where the team leaves knowing the work was done properly, almost always had the right conversations early.
And the ones that didn’t go smoothly? Often, you can trace the problems back to conversations that never happened.
It’s not always about technical complexity. Some of the trickiest situations we’ve worked through weren’t technically difficult at all. They were the result of assumptions, things that seemed obvious to one person in the room but meant something completely different to another. Or questions that felt premature in week one but became urgent in week ten.
So here are the three conversations we try to have on every project, and why we think they matter.
Conversation One: “What Are We Actually Trying to Achieve?”
It sounds almost too obvious to say out loud. Of course everyone knows what the project is trying to achieve. Except, often, they don’t, not in the same way.
What we’re really asking when we ask this question is: what does success actually look like? Not the spec, not the line items, but the outcome. A building that’s comfortable to work in? An energy target that needs to be hit? A system that the facilities team can actually understand and operate without calling us every week?
One of the most common mistakes we see at the start of a project is rushing toward solutions before the problem is fully understood. There’s a tendency to get into the details early, which equipment, which controls strategy, which integration approach, before everyone in the room has agreed on what they’re actually trying to achieve. That misalignment tends to compound. Decisions get made, hardware gets specified, and then somewhere down the track it becomes clear that the solution being built no longer fits the goal, or never did.
There’s also a financial dimension to this conversation that gets missed more than it should. Cost savings at the project level don’t automatically translate into cost savings over the life of the building. Clients sometimes strip things out of the design to reduce the upfront number, staying with older controls equipment, for instance, or selecting third-party hardware on price, without fully accounting for what that means in commissioning time, integration headaches, or long-term performance. Part of our job is to have that conversation directly, even when it’s not entirely comfortable.
The question we’re really asking is: who will operate this system, and what do they need it to do? Those aren’t complicated questions. But as one of our engineers put it: “They’re just rarely asked at the start. And by the time they are, the decisions that answer them have already been made.”
Conversation Two: “How Will This Building Actually Be Used?”
Design intent and operational reality are two different things. This gap is one of the most consistent sources of building performance problems we encounter, not because anyone made a mistake, but because buildings change, and systems don’t always change with them.
The most straightforward version of this is occupancy. How and when a building is actually occupied has a direct effect on energy use and occupant comfort. But it’s often underestimated in the design phase, when the focus is on what the building will look like rather than how it will be lived in. HVAC controls strategy, setpoints, scheduling, these all need to reflect how the building will actually operate day-to-day, not just how it looks on paper.
Accessibility is another one that gets overlooked repeatedly. Equipment ends up in places that make sense architecturally but are genuinely difficult to reach for servicing or commissioning, valves behind finished ceilings, plant in tight spaces that weren’t tight when the drawings were done. It seems minor early in a project, and it becomes very not-minor once the building is finished and someone needs to get in there.
Then there’s what happens after the project is handed over. We’ve seen situations where a wall gets removed, a renovation, a reconfiguration, something that seemed minor and nobody thought to tell us. What had been two separate HVAC zones became one space. The building automation system didn’t know that. Two controllers, each doing exactly what they were designed to do, were now fighting each other: one heating, one cooling, neither winning. The occupants were cold, and confused, and frustrated and the system was technically working perfectly.
Buildings outlast the people who designed them and the people who commissioned them. The person who was trained on the system, who understood its quirks, who knew which setpoint did what, they move on eventually. What we’ve found makes a real difference is having a site champion: someone on the client’s side who takes ownership of the system, stays curious about it, and maintains an ongoing relationship with us. When that person exists, small issues get caught early. When they don’t, systems drift.
Conversation Three: “Where Could Things Go Wrong?”
No one likes this conversation. It can feel pessimistic, or like an invitation to scope-creep. But the engineers who’ve been doing this for a while have a healthy respect for what can go wrong when this question isn’t asked.
The most consistent source of project problems is coordination, or the lack of it. When contractors aren’t talking to each other, information falls through the gaps. People show up at the wrong time. Assumptions get made about who’s responsible for which interface, which integration, which piece of equipment. We’ve turned up to sites where the hardware had already been chosen and the wiring already run, and our job became making it work with what we were given rather than building it right from the start. You can usually get there, but there’s a meaningful difference between those two outcomes.
Documentation is another one. It seems small, a form not filled in, a sensor not recorded, a piece of plant not formally tested. Nothing that stops the job from reaching practical completion. But months later, when something needs to be diagnosed or replaced, that missing information becomes a real problem. And by then, the team that installed it has moved on to the next job.
Security sits in this category too. Building automation has historically treated cybersecurity as an afterthought, which made a kind of sense when these systems were isolated. They’re not isolated any more. Smart building systems are networked, often cloud-connected, and the gaps that seemed small a few years ago have a way of becoming significant vulnerabilities. It’s something we take seriously now in ways the industry didn’t used to.
What separates good projects from great ones, in our experience, comes down to a few things: good tradespeople who are properly supported, contractors who are willing to share information across the team, and a client who trusts you enough to bring you problems early, even problems they’re not sure are solvable. The best projects we’ve worked on started with a client walking in and saying, essentially, “we have a problem and we don’t know if it can be fixed.” That kind of trust doesn’t appear from nowhere. It gets built through the conversations you have from day one.
Why It Always Comes Back to People
Building management systems, HVAC controls, building automation — all of it is ultimately in service of people using spaces. Comfortable, efficient, well-performing buildings don’t happen because the technology is sophisticated. They happen because the right questions were asked early, the right people were in the room, and someone took the time to understand not just what was being built but how it would actually be used.
The three conversations above aren’t a methodology or a checklist. They’re just what experience has taught us to pay attention to. Every project is different, but the gaps that cause problems tend to look the same. And the ones that go well tend to start the same way too, with someone slowing down long enough to ask the right questions before the decisions are already made.
Setpoint Solutions works with clients across New Zealand on building automation, BMS design and installation, smart building integration, and ongoing building performance optimisation. If you’re at the start of a project and want to talk through what it actually involves, we’d be happy to have that first conversation.
