Are you a building owner trying to figure out what actions you should be taking during new construction or major retrofit projects? If so this week's episode is for you.
In this episode, we are going to discuss how to oversee a building automation project from the perspective of the owner.
As I see it there are four phase gates for an owner to focus on
- Tender Phase
- Specification Phase
- Submittal Phase
- Closeout Phase
Click here to download or listen to this episode now.
Resources mentioned in this episode
Show notes
Phil Zito 00:00
This is the smart buildings Academy podcast with Phil Zito Episode 221. Hey folks, Phil Zito here and welcome to Episode 221 of the smart buildings Academy podcast. In this episode, we are going to be discussing project oversight for owners. You know, over the past couple weeks, I've been getting a lot of questions around project management. So naturally in Episode 220, released a project management episode, and that led to questions around but what about owners? What do owners do from a project management perspective, and I started to think about it. And I was like, Well, I don't know if necessarily project management is the right word, as much as it is project oversight. Now, granted, there are some large organizations, many of which are customers of ours, who do have project management roles. But for a good majority of them, they are actually truly in a project oversight role. They still have a general contractor, who's overseeing the execution of subcontractors and execution of contracted tasks. So really where this owner comes into play is more around the area of project oversight. So in this area, we are going to discuss or in this area. In this episode, we're going to discuss how to oversee a building automation project from the perspective of an owner. Now, as far as I can tell, from my experience working on a lot of different projects, from an owner perspective, project oversight really tends to come into four kind of phase gates for lack of a better word. And those are the tender phase, the specification phase, the submittal phase and the Closeout phase. So I'm going to talk through each one of those. And I'm going to talk about kind of the areas of importance that you would want to focus in on the things you would want to consider. Things you may be thinking of things you may not be thinking of. So during the tender phase, this is where we are typically, we've come out of Capital Planning, we know how much we are going to fund for a project, or at least we have an idea. And we start going about funding the project. This is an important area for owners who are really concerned about having smart buildings. So how I see this breaking out is kind of two buckets if you want to have a smart building, and you want to have smart building use cases, or you want to have building intelligence, maybe for like some analytics perspective, or operational efficiency perspectives. And you're doing it under maybe a compressed timeline as well. Those are kind of the two buckets I would look at. And when you think about that, many of the delivery models design, build plan and spec, they don't naturally lend themselves to dev 25, or maybe dev 27 projects, they lend themselves very well to div 23. But when you start to look at smart buildings that have many interrelations between different contractors, the standard delivery models do not work very effectively, I say do not work very effectively. I'm not saying they don't work at all. It's just as you get more complex. As you start to do more use cases that are less focused on basic operations and more or basic functionality and are more focused on extended operations, you tend to have more difficulty implementing the technologies and use cases. So the first thing I really recommend folks do is map out the use cases they want up front. A lot of companies are getting really good at this at having use case profiles for their different business types. And there
Phil Zito 03:55
are different building types. But it's something that can always be improved. And this would be things that would have use case maps maybe in like UML format, which is just a use case mapping format that is often used by the IT industry. So you would map out your use case format, you would map out your system diagram, your data flow diagram, your physical diagrams, you would have essentially use cases and you would have the as his architecture, if there even is any often there isn't on new builds, and the to be architecture and you would map all this out and this actually would drive your funding because you would develop work packages based on the use cases you want to implement. And then based on that you would also decide Am I going to use commissioning agents? Are they going to be owners reps are they going to be under the GC? How am I going to do smart building commissioning? Now, all that said, if you're not doing smart buildings and you are not doing you know intelligent services like analytics, fault detection etc, then really, you're pretty fine to just follow the normal process of, hey, let's just fund this, like we fund every building, just deliver it plan and spec or design build through dev 23 and call it a day. But if you want to do smart technologies, there is a little bit more to be done before you get to the specification phase, specifically around funding use case development, work package development, selecting which div div you want to at least on the United States, when you're using the CSI model, what do you want to drive? Do you want to drive like integrated automation in 25? Do you want to focus on communications and 27? And make sure you have like a common communication background backbone? Or do you just want to keep everything in dev 23, those are all decisions to be made. And obviously, you'd figure out your delivery model. There's much more to this, we could probably do a whole podcast episode on use case development, work package development, proper selection of divisions into specifications and proper use of delivery models, if that's something that's interesting to y'all let me know. And we'll discuss that on a future podcast episode. Number where most of you are going to be spending your time is in the specification phase. This is why I hammer all the time owners should have standards, you should have building automation standards, I guarantee your IT group has it standards, you probably have electrical and mechanical standards, you probably have all sorts of standards. From an architectural perspective, we want this color trim, we want this kind of paint, we want this layout etc. You should have standards around building automation and smart buildings. And those standards should drive the specification you should not let the specification drive the standards, these standards should drive the specification. Now to that point, you have to make a decision at at this point do I want to have a performance or prescriptive spec or performance spec is this is the outcome I want to achieve. And it leaves it more open ended, there is the possibility for Value Engineering, there is the possibility for going over cost. There's the possibility for implementing something that you don't necessarily want. But there's also the possibility that you get everything you want, and you can have a lower price. So performance specs can be good from that perspective. And they can expose you to contractors who may not have qualified if you had a more prescriptive spec. Now if you have standards, and you're very specific on your standards, from a wiring perspective, graphics perspective, submittals perspective programming, naming, etc, which I would argue if you are a company that has very accelerated timelines, which some of our students, they work for companies that have very accelerated timelines on their projects, they want to go and implement new warehouse and they want that warehouse built in a matter of months, so that they can start moving product through it. So because of that, you would do well, to have a prescriptive spec, a prescriptive spec is something that designed once based on standards can be repeated. And it basically becomes a cookie cutter process. You saw this in kind of the data center craze was that about eight years ago, where everyone was building data centers, I mean, everyone still is building data centers. But there was like a shift in the market where we started to really expand data centers.
Phil Zito 08:23
And though you would see a lot of very prescriptive specifications for that. So you want to decide, am I going to be using a performance or prescriptive spec. And then if you are using a performance spec, this isn't so much on the prescriptive spec side because those tend to be very clear if you've developed them based on standards, but from a performance specification perspective, you want to decide on your RFI and RFC involvement, like how involved are you going to be on request for information and request for clarification, especially if you have a vague performance spec. So whenever you have performance specs in my experience, and all I can go by my experience, but in my experience, performance specs have a longer specification process, they tend to lend themselves better to oh my gosh, I'm having a brain fart here to design build, or design assist models rather than plan and spec models. prescriptives tend to lend themselves more to plan to spec models in some cases. So with that being said, you as the owner have to decide how much RFI and RFC involvement Are you going to have? Are you gonna have quite a bit? Are you not gonna have quite a bit Are you going to have an onboarding process where people are brought into understanding your standards from day one, and they're going to understand this is the way we do things. And you're going to drive a very prescriptive spec that probably will lead to less RFI and RFCs. In the case of a performance spec, you'll tend to get more RFI as an RFC. Neither one is necessarily better than the other. It really just depends on your idea. Come, there's the old project management timeline or triangle, which is quality, time and cost. And depending on if you're willing to accept higher costs, then you can contract timelines and keep quality going. And one of the ways you can drive that pretty hard is with prescriptive specifications. Then we move to the submittal phase, and this is where I see a lot of owner involvement start to drop out. And this is bad, you know, I see a lot of owners tend to disengage, actually, after the tender phase, they tend to disengage or not heavily involved in the specification, or this middle phase, and then they come back into engagement in the Closeout phase. And they're like, why are we at where we're at? Why are you implementing what you're implementing, because you weren't involved in the specification, submittal phase, and thus, you got a product or a solution that maybe doesn't fit your needs. Now, if you're building buildings constantly, like some of our customers are, then what you'll tend to find is you've got a very drafted existing or very well defined existing standards and prescriptive spec. And you have a team of contractors, at least at the GC level, and architect and engineer level that tend to be consistent across those projects. Sure, getting a consistent drive of specifications, middle development. However, if that's not the case, then you'll definitely want to step into the middle phase, you'll
Phil Zito 11:32
How do I say this without offending people trust but verify that the submittal is being adhered to. And the standard is being adhered to, yes, you have consulting engineers and design engineers, and you have a contracting tier that should be overseeing that the submittals that are being developed are accurate, and are representing the intent. That being said, some contractors and engineers are better than others. And if this is something that's a critical environment, maybe you know, it's a critical warehouse critical hospital, critical facility of some sort, then you really want to ensure that submittal adherence and standard adherence is taking place. Sure, you can come back and say that this is not within spec, it is not adherence to the standard, and have people fix it later, maybe during warranty phase even. But that's a pain in the butt. And if you can avoid that upfront, then why not avoid that upfront? Why not go through and have a common checklist of submittal adherence items, and standard adherence items. And check for these and ensure that your submittals are in meeting the intent of the project. And this is another area that you've got to start to think about is whether you want to do growth or MVP or minimal viable products middles. So you can have growth based submittals and growth based submittals or simply submittals that build in excess capacity, either in the form of expansion or tenant improvements within the design. So submittals truly are the the executed Nautilus executed, the implemented, oh, what's the words I'm looking here for there the interpretation of the design intent by the contractor who will go and execute the project. So submittals are really your last opportunity. And if you are not in your specifications, saying that submittals need to be approved prior to material order and product execution or project execution, I really would in courage you to include that blurb in your specification. Because if you agree with me, that submittals are the understanding of the design intent by the controls contractor, then it is very important that that understanding of the design intent is indeed accurate. So you need to make sure that you are approving those prior to execution. What I like to focus on is either growth or an MVP submittal. Now minimal viable product does not necessarily mean crap does not necessarily mean bad, value engineered or poor. It just means it strictly meets the intent of the design. And that's it, there's no excess capacity. They're optimizing the use of every IO on the controller, they're optimizing the use of every potential slot on that network bus. They are not designing these submittals to develop a system that is flexible, that can meet rapid tenant improvement changes that can meet expansion changes, etc. Now, I would say in the past, you could pretty much get away with MVP submittals minimal viable products middles. In most cases, however, with Coronavirus and others Looking at not really knowing what the future looks like for space use, I mean, our space use may be office space, it may be meeting spaces, it may be temporary hotels, I mean, who knows what the future is going to hold for how people want to reoccupy buildings. I mean, you have one camp that firmly says people aren't going to re occupy buildings, you have another camp that says people are going to re occupy buildings, you have some people who say, we're going to take all our buildings, and we're going to turn them into residential, we have some people who say we're going to take our commercial buildings, turn them into data centers. So you've got all of this, just confusion in the market right now one of the best ways to deal with confusion is to have flexibility. So I believe we will see many more growth based submittals that have excess capacity and i O, they have excess capacity in the trunks, and they have flexibility, maybe greater use of wireless instead of Wired systems. And with that,
Phil Zito 15:56
yeah, the costs are a little different. But rather, you bear some higher potential upfront capital costs for much lower operational and retrofit costs down the lifecycle of the building. So that's a decision you need to make one thing I do not see included in so many projects in the submittal phase. And then folks get to certificate of occupancy are right there. And they're like, crap, why doesn't this work is interoperability checks. I debated whether even putting these quite honestly in the specification phase in lieu of the submittal phase. But typically, what I like to see is interoperability checks. Now, this does not have to be a pilot. This does not mean that the building automation system needs to be installed in like one floor. And then we do a pilot to make sure that the lighting system works with it. Most of the time, interoperability checks can be done on paper, this can be as simple as making sure the data model matches up. This can be as simple as making sure that the use case aligns with whatever was developed during the tender phase. But interoperability checks especially as we move to smart buildings, especially as we move to integrated systems, as we're trying to reduce our operational costs to through the use of integrated systems, we really need to have interoperability checks. And I highly recommend that these be part of the submittal phase gate, as well as the Closeout phase gate. So we really want to do that. Now, one of the biggest challenges, right, as I said, is the lack of involvement during the specification, submittal phase, it's almost as if the owner say, okay, we funded the project, we're going to disengage until the Closeout phase. Now I know that's not all owners. So please, if you do engage in the specification, submittal phase, don't send me angry emails telling me that I'm absolutely wrong, and that I have no idea what I'm talking about, because you're always engaged, I get that some people are, I'm talking about at the macro level, the majority of projects, I see there's very limited engagement by owners in the specifications, middle phase, which is rightfully so because most of those are planned in spec projects, they're very prescriptive in most cases, and they just hate a cookie cutter
Phil Zito 18:17
would be a good word for them. But as you get to more complex, either on prescriptive or the performance side, you will definitely need to have that owner involvement. But that being said, though, most owners will come in to the Closeout phase. And that's where they start to engage. And so we have to look at that and say, all right, well, if you didn't take my advice, and you didn't engage in the specification, or this middle phase, how can you properly engage in the Closeout phase? First thing you have to ask yourself is how are we even closing out this project? Is there functional testing? Is there a point to point testing? Is there a commissioning agent? Is that commissioning agent our rep? Is it the general contractors wrap? was their commissioning plan? What is that plan? You need to basically bring yourself back up to speed with what is going on on this project? Were there standards that were supposed to be implemented? I mean, that would be the first thing I would check is make sure we're adhering to existing standards standard should communicate, not only submittal development, not only sequencing, but also naming graphics, some oh and EMS training, your actual as built all of these processes that should be dictated. You can get as granular as down to what wire types you use, and what panels use. I will tell you for some of our customers who are critical facilities, it makes complete sense to have a wiring standard so that literally, their people can go and look in a panel and say oh, orange wire means this red wire means that blue wire means this and by looking at that they can instantly tell what's going on. So the more prescriptive you get, the more simple systemized you get, the less effort will have to be taken by the operational side, to troubleshoot to train to learn how to operate their buildings, if every building looks exactly the same, is wired exactly the same, the systems function exactly the same, then your onboarding process for your operational team is going to be you train them once on how to use these systems. And then it's always the same. So there is something to be said about standardization and implementation of standards. That being said, once you understand what is supposed to be done, now you start to go through it. This is where you can request Point to Point documents, and you can validate them. You can request functional test sheets, and you can validate them, you can work alongside the commissioning agent and validate that systems are actually functioning. This is where I recommend doing document reviews, ensuring that red lines are properly managed and that those red lines are being gathered, properly sourced and represent what is actually installed in the field. This may mean you have to do some walkthrough and validation that the O and M's the red lines, middles, the ad is spelt submittals actually represent what's in the field. And if not, if you start to see errors, and my rule of thumb is if you see a couple errors, there's most likely more errors. So you'll want to go and have a mechanism to go and reevaluate what's going on. So from a management from an owners perspective, you are going to really be engaging heavily here, because this is your last chance, typically to capture things prior to moving into warranty, which I will tell you, it is much easier to resolve issues prior to the warranty phase, because you're operating the building at that point, whatever your business use case is for that building, maybe it's a warehouse, maybe it's a hospital, maybe it's an airport, maybe it's a school, when you start to have issues in the warranty phase, you are having issues that impact the business use case of that building. So I want to be crystal clear on that. Because I get a lot of people that I talked to who say, that's fine. If there's issues, we'll just handle them during warranty. And I hear that from the owner perspective, as well as the contractor perspective. And in my opinion, my experience, that is a really bad philosophy. Because here's the deal. Prior to certificate of occupancy prior to warranty phase, the business use case of the building is not being executed. Let's say that the business use case it's a hospital. And your purpose of that hospital is to do operations to do imaging to do patient care, etc. Well, if you have an issue with airflow or pressurization or a visualization of data, or test and balance, whatever the issue is, would you rather catch that prior to certificate of occupancy? Or would you rather figure out that there's an airflow or humidity issue in the LR when someone's having open heart surgery? I mean, I know that's kind of a drastic, you know, example there. But at the same time,
Phil Zito 23:16
it we really need to get away from this belief, that warranty is just an extension of the project that lets us kind of clean up everything, we really should have projects closed out prior to project closeout. Now I know intellectually, everyone agrees with that. But in practice, it seems to be something that people don't necessarily agree with. So if I had to pick a line in the sand, I would really hammer that pretty hard from an owner perspective. There's things you could do liquidated damages, etc. for not having proper project execution and functionality prior to warranty. That being said, once you've done that, right, you've defined what exactly is going to be your phase gate for closeout. What is going to be your measurements of success for closeout is that CX is that point the point is that functional test, etc cx being commissioning, then you're going to do doc reviews. As I mentioned, you're going to review your red lines, you're going to review your o and M's highly recommend you get an online as well as a physical version of your own EMS. And then you're going to do your training closeout ideally, your training requirements would be dictated in the standards and included in the specification and you would have a clear expectation of training deliverables. That being said, in some cases, that does not happen and this is your last opportunity to ensure that your operational team is able and capable to execute whatever tasks they need to do utilizing the building systems that were put in place. It's also at this point and close out that I would once again, look at interoperability. Specifically, I would focus in on what is the interoperability achieving. Whereas in the specification in this middle phase, we're primarily focused and I would say tender phase, we're primarily focused on the use case and how it gets implemented. In the Closeout phase, this is where I tend to find that if you, if you miss this, within a year, maybe two tops, whatever integrations you've done, are going to be in hand and they're going to be disabled. I know that's a bold statement to make. But I've seen it time and time again, I've seen it at some of the most renowned airports and data centers and hospitals in the world, where they had these really awesome interoperability use cases, they did not properly explain the purpose, the business value and how to operate this to the operational team. warranty phase came and went, they decided to no longer continue a service contract with the controls contractor. And as soon as an API changed, or there was a version update, that broke the integration, rather than figuring out why that's not working, and getting that integration to work again, guess what it got put in hand. And that is just the reality of the world we live in. So if you want to ensure that interoperability continues, and maybe that's just simply a lighting to building automation, integration, maybe that's a complex data analytics, maybe that's a, you know, digital twin, maybe that's work order management, and actual fault detection and building automation working together. Maybe that's a smart conference room use case, whatever it is, if you want to ensure that this functionality continues, you need to both explain the purpose and business value to the end user. And that is both the operator as well as maybe the business user as well. And you need to ensure that you are developing processes to continue ensuring that that interoperability and integrated systems function post closeout so I know this was a lot there's a lot to take in I kind of jammed in a lot of concepts. Some of them I explored in a little bit of detail. Some of them I just touched on briefly. What I ask of you coming out of this episode is that if you were like man, I'd really like Phil to touch on. Whatever, then let us know send an email to support at smart buildings academy.com go to smart buildings Academy calm and hit us up in the chat. Go to podcasts that smart buildings academy.com for slash two to one and let us know for this episode what you think. If this is on YouTube or LinkedIn post in the comments, I really want to hear from you. Let us know what you would like greater detail on in the future and we'll be sure to include it
Phil Zito 28:14
in our podcast episodes. Moving forward. Next week's episode, we're gonna have Tyson Souter from Siemens Europe, and we're going to be talking through smart buildings. We're gonna be talking about smart buildings use cases implementing smart buildings, will there ever be a open source building automation system, why that may or may not happen? What would have to happen for that to happen? Should we be pushing all this technology on commercial building owners right now and they can barely keep their doors open because their tenants aren't paying their bills, and a lot more. So we'll start to take a look at all of that in next week's episode. So with that being said, Thanks a ton for being here. I hope you're enjoying these kind of new concepts we're starting to explore. It's all because of you, our students and our listeners who are telling us Hey, could you talk more about this? Could you talk more about that? That's where we're getting these ideas from. So the more information you give us, the better content you will receive. Make sure we have a integration for building automation webinar coming up on the 14th it's completely free. You can find some information about it at podcast dot smart buildings Academy comm four slash two to one, you will see a link to the podcast or to the webinar to sign up. We are also working on our consultative sales for building automation course. So this course the sole purpose around this is to take salespeople, development engineers, etc. and teach them what is the consultative sales process from a building automation perspective? How do we identify Find the problems that exist. And my goal in this course is to look at three specific verticals, healthcare, commercial, real estate and education. And the reason I chose those is healthcare is like critical facilities. So if we start to identify problems that would exist for health care, a lot of those problems will carry over for data centers, FDA labs, etc. Other critical environments, if we start to look at commercial real estate, those would carry over to, you know, corporate real estate, etc. And if we look at education, that's going to cover a lot of different K through 12, hire etc, they're slightly different, but most of the problems will be very similar. So we'll teach you how to identify problems, how to determine the cost as well as the opportunity cost of these problems, how to then define success in the form of benchmarks and KPIs. And then how to create a solution based proposal for the owner. So basically, you'll be able to go in and do a consultative sale to an interview, understand what's going on, understand the opportunities and the pain points, deliver a solution. So this is going to be quasi technical slash quasi sales is going to be sales in the form that it's going to be very much about solution selling. And it's going to be very focused on problem and solution identification. However, it's going to be technical in that this is going to be specific to building automation, this is going to be specific to smart buildings. And we're going to be looking at that. So I'm going to assume you have basic sales knowledge coming into this course. So if you want to know more about that definitely reach out to us. You should see something coming out about that within the next month. So this is a course that we would develop run live and then we would re record based on the first cohorts feedback. All right, with that being said Thanks a ton for being here folks. Like I said everything is going to be available at podcast dot smart buildings. khadem e comm forward slash two to one. Thanks a ton and take care
