Over the past couple weeks, I have been getting a lot of questions around Project Management. That’s why I released a Project Management episode, and that led to questions surrounding, “but what about owners”. What do owners do from a project management perspective?
I started to think about it and I thought, I don't necessarily know if project management is the right word, as much as it is project oversight. Now, granted, there are some large organizations, many of whom 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 is overseeing the execution of subcontractors and execution of contracted tasks. Therefore, where this owner comes into play, is more around the area of project oversight.
In this post, 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 in to four kinds of “phase gates:”
These phase gates are:
- Tender Phase
- Specification Phase
- Submittal Phase
- Closeout Phase
I'm going to talk through each phase, and I'm going to talk about the areas of importance that you would want to focus on and consider.
The Tender Phase
The Tender Phase, typically comes after 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.
How I see this breaking out is into two segments:
- Segment One: If you want to have a smart building and you want to have smart building use-cases
- Segment Two: You want to have building intelligence for analytics or operational-efficiency perspectives and you are doing it under maybe a compressed timeline as well.
When you think about that, many of the delivery models like design-build and plan, and spec don't naturally lend themselves to CSI Division 25, or Division 27 easily projects but most projects tend to lend themselves very well to Division 23.
When you start to look at smart buildings that have many interrelations between different contractors, you find that the standard delivery models do not work very effectively. I'm not saying they don't work at all, it's just as you get more complex, and you start to do more use cases that are less focused on basic functionality and 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 having use-case profiles for their different business types. So, you would map out your use-case format, your system diagram, your data-flow diagram, and your physical diagrams. You would have use-cases, the as-is architecture (not normally found on new builds), and then you would have the to-be architecture so you could map all of this out. This would drive your funding because you would develop work packages based on the use-cases you want to implement. 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, with all that said, if you are not doing smart buildings and you are not doing intelligent services like analytics, fault detection, etc., then you’re fine to just follow the normal process of, “Let's just fund this, like we fund every building. Just deliver it plan-and-spec or design-build through div 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 regarding funding, use-case development, work-package development, and selecting which division you want to drive.
Do you want to drive integrated automation in Division 25?
Do you want to focus on communications using Division 27, or do you just want to keep everything in Division 23?
Once you know this you can figure out your delivery model. There’s so much more to this that we could probably do a whole blog post on. If that’s something interesting to you, let me know!
The Specification Phase
Now, where most of you are going to be spending your time is in the Specification Phase. This is why I always stress that owners should have standards; you should have building automation standards.
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.
Now to that point, you have to make a decision:
Do I want to have a performance or prescriptive spec?
A performance spec is focused on the outcome I want to achieve, and it leaves the design more open ended. There is also the possibility for Value Engineering and there is the possibility for going over cost.
Furthermore, there is 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, then it may make sense to have a prescriptive spec.
Additionally if you are a company that has very accelerated timelines, which is the case for some of our students. They work for companies that have very accelerated timelines on their projects. They want to go and implement a 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 the data center craze about eight years ago, where everyone was building data centers. At that time, there was a shift in the market where we started to really expand data centers, and 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?
If you are using a performance spec, you want to decide on your RFI and RFC involvement. Basically, 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, performance specs have a longer specification process. They tend to lend themselves better to design build, or design-assist models rather than plan-and-spec models.
Prescriptive specs tend to lend themselves more to plan-and-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 going to have quite a bit? Are you not going to 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?
Are you 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’s and RFC’s. Neither one is necessarily better than the other. It really just depends on your outcome. There's the project management 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. One of the ways you can drive that pretty hard is with prescriptive specifications.
The Submittal Phase
The Submittal Phase is where I see a lot of owner-involvement start to drop out, which is bad. I see a lot of owners tend to disengage or not be heavily involved in the Specification, or Submittal Phase, and then they come back in the Closeout Phase and ask questions like, “Why are we at where we're at? Why are you implementing what you're implementing?”
It’s because they weren't involved in the Specification and Submittal Phases, and thus, they got a product or a solution that maybe doesn't fit their needs.
Now, if you're building buildings constantly, like some of our customers are, then what you'll tend to find is that you've got a very well defined existing standards and prescriptive spec. You have a team of contractors, at least at the GC, architect and engineer level, that tend to be consistent across those projects. This means you’re getting a consistent drive of specifications, middle development.
However, if that's not the case, then you'll definitely want to step into the Submittal phase. 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, 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. If this project is a critical environment, for example, a critical warehouse or critical hospital, 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 in adherence to the standard, and have people fix it later, perhaps during warranty phase.
However, that's a pain in the butt. If you can avoid that up front, 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, to ensure that your submittals are in meeting the intent of the project?
This is another area that you've got to decide if you want to do growth or MVP, or Minimal Viable Products, submittals. So, you can have growth-based submittals, which build in excess capacity either in the form of expansion or tenant improvements within the design.
Submittals truly are the interpretation of the design-intent by the contractor who will go and execute the project. So, submittals are really your last opportunity. If you are not saying in your specifications that submittals need to be approved prior to material order and project execution, I really would encourage you to include that blurb in your specification.
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 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. In most cases, however, with Coronavirus and us looking at not really knowing what the future looks like for space-use we need flexibility. After-all our space use may be office space, it may be meeting spaces, it may be temporary hotels. Who knows what the future is going to hold for how people want to re-occupy buildings.
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, and 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 in the IO, excess capacity in the trunks, and they have flexibility, maybe greater use, of wireless instead of Wired systems. With that, the costs are a little different, but I’d 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, until folks get to Certificate of Occupancy and ask, “why doesn’t this work,” is interoperability checks. I debated whether even putting these in the specification phase in lieu of the submittal phase. 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, which 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. Especially as we move to smart buildings, 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.
I highly recommend that these be part of the Submittal Phase gate, as well as the Closeout Phase gate. Now, one of the biggest challenges is the lack of involvement during the Specification/Submittal Phase. It's almost as if the owner says, “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, and I'm talking about at the macro level, the majority of projects I see, there's very limited engagement by owners in the Specifications/Submittal Phase, which is rightfully so, because most of those are planned in-spec projects, very prescriptive in most cases.
As you get more complex, either on prescriptive or the performance side, you will definitely need to have that owner-involvement. That being said, though, most owners will come in at the Closeout Phase, and that's where they start to engage.
The Closeout Phase
So, we have to look at that and say, “Well, if you didn't take my advice, and you didn't engage in the Specification, or Submittal 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 Rep?
- Was there a commissioning plan? What is that plan?
You need to basically bring yourself back up to speed with what is going on in this project.
Were there standards that were supposed to be implemented?
That would be the first thing I would check to make sure we're adhering to existing standards. Standards should communicate, not only submittal development, not only sequencing, but also naming graphics, some Operations and Maintenance manuals, training, your actual as-builts; all of these processes that should be dictated.
You can get as granular as down to what wire types you use, and what panels to use. I will tell you that 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, “Ooh, 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 and the more 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.
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, submittals, the as-built submittals actually represent what's in the field.
If you start to see errors, and my rule of thumb is if you see a couple errors, there are most likely more errors, you'll want to go and have a mechanism ready to go and reevaluate what's going on. From a management/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.
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, be it a warehouse, a hospital, an airport, or 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. I want to be crystal clear on that because I get a lot of people that I talk to who say, “It’s fine. If there's issues, we'll just handle them during warranty.” I hear that from the owner-perspective, as well as the contractor-perspective. And in my opinion, in my experience, that is a really bad philosophy.
Here’s why: 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 is it's a hospital, and your purpose of that hospital is to do operations, imaging, patient care, etc. Well, if you have an issue with airflow, pressurization, visualization of data, or even 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 OR when someone's having open heart surgery?
I mean, I know that's kind of a drastic example, but at the same time, we really need to get away from this belief, that warranty is just an extension of the project that lets us 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 concept pretty hard from an owner perspective.
There's things you could do such as liquidated damages, etc. for not having proper project execution and functionality prior to warranty. That being said, once you've done that, you've defined what exactly is going to be your phase gate for Closeout or what is going to be your measurements of success for closeout?
- Is that CX (commissioning)
- Is that point-to-point?
- Is that functional test, etc.
Then you're going to do document reviews. You're going to review your red lines, you're going to review your O and M's. I highly recommend you get an online, as well as a physical version, of your O and M’s. 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 in Closeout that I would once again, look at interoperability.
Specifically, I would focus in on what is the interoperability achieving, whereas in the Tender, Specification, and the Submittal 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 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, it got put in hand.
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 complex data analytics, maybe that's a 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.
That is both the operator as well as maybe the business user as well. You need to ensure that you are developing processes to continue ensuring that that interoperability and integrated-systems function post closeout.
Conclusion
I hope you found this article beneficial. Be sure to use our comment section below to ask any questions you may have. If you are looking to get up to speed with building automation then I encourage you to check out our large library of courses.
