Episode 10, “Embedding Smart Buildings Technology Strategy Early in the Design Process”
Embedding Smart Buildings Technology Strategies Early in the Design Process
Hello and welcome to Expanding the Possible, I’m Kirsten Nielsen.
This podcast from HH Angus explores how engineering is advancing the built environment. From innovations in building systems, to the Internet of Things … from digital services connecting the modern workplace to combating the impact of climate change, we delve into exciting developments in today's and tomorrow's building infrastructure.
Today on Expanding the Possible, we're talking about smart buildings technology strategies, and why it's so important to embed this strategy early in the design process, in order to create buildings that are smarter and more sustainable.
Joining us today are Akira Jones and Kelly Henderson. Akira is Director of HH Angus' Digital Services Division and Kelly is an Associate Director in our Angus Connect Division. Before we jump into the topic, I want to ask you both for the elevator pitch about the type of work your division focuses on to give our listeners a better sense of how your team contributes to smart buildings. Akira, I'll start with you. Tell us a little bit about the Digital Services division at HH Angus.
Akira - Our Digital Services division is most easily described as a group of people that create digital products in and around the acquisition, storage, and management visualization analytics of building data. Whether that's from legacy-type building systems, like building automation systems and lighting control systems, or from other types of newer technologies, IoT devices, and edge devices that collect different data points within buildings, we bring all those data sets together and create custom dashboards and analytics and insights for our clients and we build those products on Amazon Web Services.
Kirsten - It's interesting to me that your division didn't exist until a few years ago, so this is all very cutting-edge, leading-edge type of design and planning and strategy. So that's a very exciting development in your team. And the same for you, Kelly. Tell us a little bit about the work of the Angus Connect division.
Kelly - Angus Connect delivers a full spectrum of technology consulting services across all the divisions HH Angus delivers in; for example, we're doing IMIT and security system design across healthcare, energy, commercial, and mission critical. But we're also providing management consulting services with a technology lens. And so that means we're producing digital strategies, roadmaps, process redesign, and operational readiness services, as well as system integration consulting for smart building technologies. And we're really striving to provide services for our clients across the full life cycle of the building, from initial planning and business case through to ongoing maintenance, retrofits, upgrades, and continuous improvement.
Kirsten - Thank you. You both recently appeared at the Royal Architecture Institute of Canada's Conference on Architecture. It was in Vancouver, and you were presenting on the subject of today's podcast, which is embedding a strategy for smart buildings technology early in the design process. Kelly, let's talk about some of the factors that drive the need for this kind of strategy.
Kelly - This work-around strategy came out of us having challenges on client projects where they were being asked to make decisions about technology once we were into design, and came to the realization that they really didn't have the right information to be making those informed decisions. And so, we started introducing the idea of doing these strategies to bring all the right players together earlier in the process to help set directions. So that means you're often in capital redevelopment, you have a team that's focused on redevelopment, but you have the operations team receiving the building at the end of the day. And when you don't have those operations people [involved] early in the process to help guide decision making, you often miss opportunities to deliver what they need to optimally operate or have the best experiences possible in the facility, based on those intended outcomes. So that's one of the main factors for why we were suggesting bringing strategy earlier in the design process.
Kirsten – When you say early, how early is early?
Kelly - What we like to do is have our strategies done before the design process is started. So that would be before you're into schematic design. Often when we are engaged, it's during schematic design. But with our healthcare clients, we're also working at the business case and functional programming level as well. So that's years before the design team would be engaged.
Kirsten - Akira, what have you seen in your experience on the ramifications if clients and building designers are not thinking proactively about embedding a technology strategy?
Akira - Kelly touched on [it] a little bit, but ultimately it comes down to two things. It is added cost - like all things in construction, if you don't think about it ahead of time, it's not that it's not possible, it's just going to cost you a lot more money. And then it's also, with smart building technology in general, it's the missed outcomes - you're spending money on technology and you're not getting out of it what you're looking for. So ultimately, thinking about those things, they can manifest themselves in a lot of different ways. If I think about people wanting integrated building systems with building automation and lighting control, if the things aren't in the specs for those systems to allow for integration, how you bring those data sets together, or how you set up your network infrastructure so that you have a converged network, or thinking about whether or not you want your operational technology and your other systems on separate networks. These things have to be sorted out beforehand. Otherwise, it's really difficult to deal with that in the future. So I think a lot of it is making sure that the specifications for all of the other things that we're working with (because ultimately a smart building isn't like this thing on its own, you're bringing together a bunch of different systems and data sets), so if those other systems don't have the things in place that allow for bringing the data together, it's not that you can't do it in the future, it's just going to be a huge added cost and there's going to be a big sticker shock for the client. This happens often in situations where the intention is to have some kind of smart building or integration in the future, but when they address it down the road or towards the end of the project, there is a huge price tag that comes with it and often makes the implementation very cost prohibitive.
Kirsten - That leads into my next question, which is about the industry challenges around designing smart buildings and certainly getting people on board with this initial planning stage would be the first one I would say, but beyond that, what kind of challenges are you seeing?
Akira - I would say that the smart buildings sector as a whole is very fragmented. So, you have a lot of different players doing a lot of different things and there's the overall integrations that you need to bring the systems together. But then within that, you have subsets of different companies, whether that's tech or professional services or otherwise, that provide different solutions, whether that's a hardware that comes with a software platform, cloud infrastructure. So, it's a lot for people to sort out and understand what they need to bring together to get the outcomes that they're looking for.
I think one of the biggest challenges is that there's just so much stuff out there. There are so many different verticals in the market in terms of use cases. Within occupancy and presence, you have devices that will tell you whether a room's occupied, how many people are in the room. Some of them are used for smart washroom solutions and some of them are not. How you drive value from this is difficult to understand. And that leads me to my next point - that every sector will derive value from a smart building in a different way. A healthcare facility will have very different needs and requirements and things driving that business. They're often patient outcome-focused, and the things that they need to make their building smart to enhance the patient outcomes or make those better are going to be very different than, let's say, an industrial warehouse, which may be looking more from a safety point of view, a logistics point of view, an optimization point of view. Or a commercial building, which may be looking to either improve the efficiency of their building from an energy standpoint, but also improve the experience of the tenants within those buildings, or to retain the tenants and the companies that are leasing their space.
So, there's no ‘one size fits all’ solution for a smart building. And this is a big challenge that we run into in communicating the capabilities of our Digital Services team, and on the Connect side, what a strategy might look like. Because we get into this loop of conversation where we're like, “what would you like your smart building to do”? And they're like, “well, what can a smart building do for us?” And you get stuck in this in this loop, because there is no ‘one size fits all’.
I would say that ultimately, the things that we're trying to avoid is missing the outcomes that you're looking for. I was speaking with some folks from a technical college here in Ontario just yesterday and, pre-COVID, they had gone down the road and done some smart buildings pilots. And they missed the outcomes. They didn't derive the value. They don't use the thing that they paid for, which were some basic occupancy and presence monitoring, and also garbage monitoring - monitoring the levels of garbage and different garbage cans and stuff like that. So I asked them, I said, “So why do you think this was a failure?” And they're like, “we don't use the thing today, we paid for it, and we don't use it.” And that is a perfect example of a missed outcome. And that is detrimental to any person or group within an organization that is trying to get to a smart building, because you spend money [but] you miss the outcome.
At the higher level, at the management level, they're saying, “what is this smart building stuff, it doesn't do anything for us, it hasn't driven any value.” So ultimately, the goal from both the strategy and the use case development and implementation is to make sure that you hit that outcome. And you drive some value for the organization. Otherwise, you're just heading down the wrong road, and you enter a negative feedback loop, and you don't get to where you want to go.
Kelly - I would add as well on the consulting side, one of the challenges we see and experience and are trying to work through is the market fragmentation. You need steps A through Z and products A through Z on board in order to get to those outcomes. But there's so many different ways and different companies that offer different components of that full process and technology system that it isn't possible to design it fully and have oranges and oranges brought to you to assess and make your decisions on. You're getting oranges, apples, trees, a car … and you're having to figure out which one of those is going to be best for your client to get them where they need to go that is most cost effective and has all the operational benefits that they're seeing. And so, it's like the Wild West of figuring out the best way to document what it needs, allowing the flexibility for the market to respond, and then working with clients to figure out the best way to assess it. And there isn't one way to do it. We're evolving, technology's evolving, so it's this constantly changing market that is thrilling to work in, but it's also hard to sort of keep up all the time with new players coming to the table, new offerings.
Kirsten - And I just want to add in here because I think it's an important point, and it jumps off what you were talking about, Kelly, and that is HH Angus and all our divisions are vendor neutral. And I think that's important to mention. Talk to me a little bit about how you convey that to clients and how that helps us.
Kelly - I think that's what Akira and I like about the work that we do, because it's coming out of a consulting practice where we're there to help our clients get the best solution for them, it allows us to be vendor agnostic, and we work with all of the different players in the market and can assess their strengths and weaknesses and then align that to what the outcomes are that we're trying to achieve. I think that does make it appealing for clients where often, again to what I was saying before, you could go to a specific integration player that has their own product offering, that's then tied to that product line. And you'll be able to get close to what you're looking for, but it's those little bits of customization or where it doesn't necessarily fit in their roadmap that you get stuck on and end up missing those outcomes that you wanted because you're not able to get to exactly what you needed.
Kirsten - So to pick up on what Akira was talking about, Kelly, what are some of the main elements that go into developing a strategy? I think from what you've both said, the first one is figuring out the value proposition, but how do you determine that? And once you've done that, where do you go with the client next?
Kelly - We break it down by first understanding the current state. You're always starting from somewhere. So as Akira was saying, “Have you tried this before? Have you had some failures? What has worked? What hasn't worked? Do you have systems you want to be leveraging?” And then from there, we're doing some market research that's specific for this client. Because technology changes so much, you really have to do a deeper dive on the technologies they're looking for every time just to make sure you're up to date. And then we're bringing that forward and seeing which of those offerings is resonating, or if we're bringing examples of other companies in the industry that have seen success in their outcomes and figuring out what sticks with them. And then from there, we pull together a vision statement of ‘where is this project headed’? And then we start going into the use cases. We need to get to the specifics of the outcomes. And that then informs larger standards, what Akira was mentioning earlier as well.
Once you have your use cases described, you're able to break down the technologies a little bit more. And then you have to set the standard. We're working across all disciplines, so there will be elements that mechanical team needs to understand. There'll be elements of electrical [systems] and then security systems and AV systems. As well, the client's going to have a bunch of operational systems. Their accounting, financial systems, maybe if it's a university or post-secondary, they have a student portal of some sort. You have to have an understanding of all of that in order to make sure you're setting standards that each system is going to be able to feed into the same sort of network of information exchange and information sharing that you can begin to build those use cases from.
Kirsten - I think one of the things that's interesting about the work that both your teams do is working across a variety of industry sectors, because there's the commercial sector, there's education, there's healthcare, then utilities. You're learning from all of these clients as you go along. So let's talk a little bit more, then, about use cases. Akira, you've worked on projects that have implemented strategies for smart building technologies. What would you say are the characteristics of successful use cases?
Akira - Kelly touched on it in the strategy piece. It's being specific. Specificity on the use case allows you to have a use case that you can tie some kind of direct value to. For any kind of commercial organization, for instance, it's like any other part of that business. Unless there's some ROI that you can calculate, why would any business spend money on it? And that's really ultimately what it comes down to. You have to be able to tie some value to it. And if the use case isn't specific, that's really hard to do. So, to me, that's the key element. And I think a good example of this is one of the commercial clients we work with came to us (and we work with an occupancy and presence solution for two of their buildings, one in Ontario and one in Quebec); so, when they came to us, they said, “we want to understand the presence and occupancy in the building.” But what does that mean exactly? Because that can mean a lot of different things. And the question for us was, “why do you want to understand this?”
And after many conversations, there were much more specific things that came out of that - being able to understand how many people were on the floors at any given time, being able to understand what rooms were occupied and what rooms were not occupied, being able to compare whether or not the meeting room distribution that they had made sense for the building. So if they had a whole bunch of large meeting rooms and small meeting rooms, were those being used by the right number of people? Did they right-size or plan their layout in the correct way? They also wanted to be able to understand the building population at any given time to provide that data to their cafeteria, to look at right-sizing [the] amount of food that they might have, or notice trends in any amount of food that people were purchasing. They also wanted to be able to test ‘return to office’s initiatives. If they implemented a ‘return to office’ initiative or changed the in-office requirements or mandates, they wanted to be able to see, “Okay, we've done this for a month. What was the impact of that in the actual occupancy of the building? Did it change? Did the money that we spent on the return to office initiative make sense?” So, each of these things was answering specific questions or driving specific value for the client. But simply to say, “oh, well, we just want to get occupancy.”, that's a place to start, but we have to dive down much more deeply to understand, okay, what are the specific data points and insights that you're looking for?
Kelly - I can add that, on the healthcare side, one of the things we've found in the use cases we've been requiring on some of our larger redevelopment projects, one of the biggest lessons learned is that through our process, you come up with a large list of potential future use cases you'd like to see implemented. But when it comes to opening day, it becomes more important to really whittle down those essential ones that you need because the biggest piece of feedback we have now is, when you go from a traditional building to a smart building, you can get overwhelmed with information. Where you may have five use cases that are really important and could drive great value, if there's 15 that are sort of diluting the experience, it brings the whole thing down. And so that's why we're focusing now on honing in on those really important ones and doing them well and trying to edit the requirements a bit to make sure that we avoid that.
Akira - And I would add that from our side of it as well, we have found the most success starting with a single use case with an organization because, to Kelly's point, it lets you wrap your head around it and figure out how to use this new tool. Like any new thing in our life, we have to figure out how to use it. And then the other part of it is then it's much easier within the organization itself to say, “we did this thing, it's a nice little box with a bow on it, it has this value and it shows the value to the rest of the organization.” And the best part about it is the approach that we typically take is something that is scalable so that you can add use case after use case, bring in new technologies, bring in data sets from other parts of the organization. But to boil the ocean, to use that colloquialism, it just usually ends up in failure.
Kirsten - Good advice. So, in closing, I'm going to ask you both to share with us either a key takeaway for you in what you want people to know about the importance of early stage planning for smart building technologies, or what do you wish clients knew better about the importance of this? Kelly, I'll start with you.
Kelly - So this is something I hear Akira say, which I love, is that we have this wealth of buildings in the world. 99% of the built facilities that we have are existing buildings. And I think people might get stuck in thinking about smart buildings as being only your new buildings when you get to start from scratch. But there's a lot of really exciting work you can do in the existing buildings. And the approach that Akira was mentioning around ‘start with one use case, find that one, what problem do you have in your existing building that you want to solve?’ It's not, it's the turtle or the hare, you know - through the turtle approach, you're going to get to success faster in the end than doing a big bang.
Kirsten – And Akira, your thoughts?
Akira - I would say, and it's kind of in a similar vein, and it's very much related to smart buildings. A) things seem to converge on the digital design, construction, buildings, and whatnot. You know, everybody's talking about digital twins. People get fixated on this thing, and they're like, “we need a digital twin”. And what does that mean? A digital twin can be a lot of different things. And B), a lot of people have an image that there's some visual aspect to it, like you have a 3D model of your building. Is that a digital twin? It's part of a digital twin. But, you know, a true digital twin is something that has enough data enriched within it, that it represents in a digital space, the physical element. So you can start simulating and making decisions from that digital twin. But a lot of people are like, “oh, I got to get this digital twin”. But that is a massive undertaking for most organizations, especially, to Kelly's point, all these existing buildings, right? All of these buildings are existing. Are they all going to have digital twins? Maybe someday. Is there value in that? I don't know. So, the point really is stop thinking about the digital twin, and start thinking about ‘how can I get one piece of value from a smart building technology’, and start from there. I think often organizations are paralyzed in terms of how they start, because they see all these cool presentations at conferences, or they see Autodesk, or a whole other host of vendors talking about these very complex digital twin objects and integrations. My opinion is, and I think Kelly would agree, is not where to start. Start with the one thing, and go from there. Otherwise, again, like anything in our lives, if it's too complicated, or we can't see the value in it, then it's not going to go anywhere.
Kirsten - Very true. And I think very safe to say that having a strategy, a clarified strategy for smart building technologies is really important in meeting the needs of the occupants and in supporting the design vision. Kelly, Akira, thank you so much for sharing your experiences and your expertise today, for our look at smart building technology strategies, and why it's important to make these an early and integral part of the design process.
Our guests today have been Akira Jones and Kelly Henderson from HH Angus' Digital Services and Angus Connect Divisions respectively.
To all our listeners, thank you for joining us today. If you're interested in connecting with our experts about any aspect of smart building design and technology, you can reach us anytime through our contact page at hhangus.com. Again, that's hhangus.com. I'm Kirsten Nielsen - we look forward to connecting with you again on our next podcast here on Expanding the Possible. Have a great day!
Hello and welcome to Expanding the Possible, I’m Kirsten Nielsen.
This podcast from HH Angus explores how engineering is advancing the built environment. From innovations in building systems, to the Internet of Things … from digital services connecting the modern workplace to combating the impact of climate change, we delve into exciting developments in today's and tomorrow's building infrastructure.
Today on Expanding the Possible, we're talking about smart buildings technology strategies, and why it's so important to embed this strategy early in the design process, in order to create buildings that are smarter and more sustainable.
Joining us today are Akira Jones and Kelly Henderson. Akira is Director of HH Angus' Digital Services Division and Kelly is an Associate Director in our Angus Connect Division. Before we jump into the topic, I want to ask you both for the elevator pitch about the type of work your division focuses on to give our listeners a better sense of how your team contributes to smart buildings. Akira, I'll start with you. Tell us a little bit about the Digital Services division at HH Angus.
Akira - Our Digital Services division is most easily described as a group of people that create digital products in and around the acquisition, storage, and management visualization analytics of building data. Whether that's from legacy-type building systems, like building automation systems and lighting control systems, or from other types of newer technologies, IoT devices, and edge devices that collect different data points within buildings, we bring all those data sets together and create custom dashboards and analytics and insights for our clients and we build those products on Amazon Web Services.
Kirsten - It's interesting to me that your division didn't exist until a few years ago, so this is all very cutting-edge, leading-edge type of design and planning and strategy. So that's a very exciting development in your team. And the same for you, Kelly. Tell us a little bit about the work of the Angus Connect division.
Kelly - Angus Connect delivers a full spectrum of technology consulting services across all the divisions HH Angus delivers in; for example, we're doing IMIT and security system design across healthcare, energy, commercial, and mission critical. But we're also providing management consulting services with a technology lens. And so that means we're producing digital strategies, roadmaps, process redesign, and operational readiness services, as well as system integration consulting for smart building technologies. And we're really striving to provide services for our clients across the full life cycle of the building, from initial planning and business case through to ongoing maintenance, retrofits, upgrades, and continuous improvement.
Kirsten - Thank you. You both recently appeared at the Royal Architecture Institute of Canada's Conference on Architecture. It was in Vancouver, and you were presenting on the subject of today's podcast, which is embedding a strategy for smart buildings technology early in the design process. Kelly, let's talk about some of the factors that drive the need for this kind of strategy.
Kelly - This work-around strategy came out of us having challenges on client projects where they were being asked to make decisions about technology once we were into design, and came to the realization that they really didn't have the right information to be making those informed decisions. And so, we started introducing the idea of doing these strategies to bring all the right players together earlier in the process to help set directions. So that means you're often in capital redevelopment, you have a team that's focused on redevelopment, but you have the operations team receiving the building at the end of the day. And when you don't have those operations people [involved] early in the process to help guide decision making, you often miss opportunities to deliver what they need to optimally operate or have the best experiences possible in the facility, based on those intended outcomes. So that's one of the main factors for why we were suggesting bringing strategy earlier in the design process.
Kirsten – When you say early, how early is early?
Kelly - What we like to do is have our strategies done before the design process is started. So that would be before you're into schematic design. Often when we are engaged, it's during schematic design. But with our healthcare clients, we're also working at the business case and functional programming level as well. So that's years before the design team would be engaged.
Kirsten - Akira, what have you seen in your experience on the ramifications if clients and building designers are not thinking proactively about embedding a technology strategy?
Akira - Kelly touched on [it] a little bit, but ultimately it comes down to two things. It is added cost - like all things in construction, if you don't think about it ahead of time, it's not that it's not possible, it's just going to cost you a lot more money. And then it's also, with smart building technology in general, it's the missed outcomes - you're spending money on technology and you're not getting out of it what you're looking for. So ultimately, thinking about those things, they can manifest themselves in a lot of different ways. If I think about people wanting integrated building systems with building automation and lighting control, if the things aren't in the specs for those systems to allow for integration, how you bring those data sets together, or how you set up your network infrastructure so that you have a converged network, or thinking about whether or not you want your operational technology and your other systems on separate networks. These things have to be sorted out beforehand. Otherwise, it's really difficult to deal with that in the future. So I think a lot of it is making sure that the specifications for all of the other things that we're working with (because ultimately a smart building isn't like this thing on its own, you're bringing together a bunch of different systems and data sets), so if those other systems don't have the things in place that allow for bringing the data together, it's not that you can't do it in the future, it's just going to be a huge added cost and there's going to be a big sticker shock for the client. This happens often in situations where the intention is to have some kind of smart building or integration in the future, but when they address it down the road or towards the end of the project, there is a huge price tag that comes with it and often makes the implementation very cost prohibitive.
Kirsten - That leads into my next question, which is about the industry challenges around designing smart buildings and certainly getting people on board with this initial planning stage would be the first one I would say, but beyond that, what kind of challenges are you seeing?
Akira - I would say that the smart buildings sector as a whole is very fragmented. So, you have a lot of different players doing a lot of different things and there's the overall integrations that you need to bring the systems together. But then within that, you have subsets of different companies, whether that's tech or professional services or otherwise, that provide different solutions, whether that's a hardware that comes with a software platform, cloud infrastructure. So, it's a lot for people to sort out and understand what they need to bring together to get the outcomes that they're looking for.
I think one of the biggest challenges is that there's just so much stuff out there. There are so many different verticals in the market in terms of use cases. Within occupancy and presence, you have devices that will tell you whether a room's occupied, how many people are in the room. Some of them are used for smart washroom solutions and some of them are not. How you drive value from this is difficult to understand. And that leads me to my next point - that every sector will derive value from a smart building in a different way. A healthcare facility will have very different needs and requirements and things driving that business. They're often patient outcome-focused, and the things that they need to make their building smart to enhance the patient outcomes or make those better are going to be very different than, let's say, an industrial warehouse, which may be looking more from a safety point of view, a logistics point of view, an optimization point of view. Or a commercial building, which may be looking to either improve the efficiency of their building from an energy standpoint, but also improve the experience of the tenants within those buildings, or to retain the tenants and the companies that are leasing their space.
So, there's no ‘one size fits all’ solution for a smart building. And this is a big challenge that we run into in communicating the capabilities of our Digital Services team, and on the Connect side, what a strategy might look like. Because we get into this loop of conversation where we're like, “what would you like your smart building to do”? And they're like, “well, what can a smart building do for us?” And you get stuck in this in this loop, because there is no ‘one size fits all’.
I would say that ultimately, the things that we're trying to avoid is missing the outcomes that you're looking for. I was speaking with some folks from a technical college here in Ontario just yesterday and, pre-COVID, they had gone down the road and done some smart buildings pilots. And they missed the outcomes. They didn't derive the value. They don't use the thing that they paid for, which were some basic occupancy and presence monitoring, and also garbage monitoring - monitoring the levels of garbage and different garbage cans and stuff like that. So I asked them, I said, “So why do you think this was a failure?” And they're like, “we don't use the thing today, we paid for it, and we don't use it.” And that is a perfect example of a missed outcome. And that is detrimental to any person or group within an organization that is trying to get to a smart building, because you spend money [but] you miss the outcome.
At the higher level, at the management level, they're saying, “what is this smart building stuff, it doesn't do anything for us, it hasn't driven any value.” So ultimately, the goal from both the strategy and the use case development and implementation is to make sure that you hit that outcome. And you drive some value for the organization. Otherwise, you're just heading down the wrong road, and you enter a negative feedback loop, and you don't get to where you want to go.
Kelly - I would add as well on the consulting side, one of the challenges we see and experience and are trying to work through is the market fragmentation. You need steps A through Z and products A through Z on board in order to get to those outcomes. But there's so many different ways and different companies that offer different components of that full process and technology system that it isn't possible to design it fully and have oranges and oranges brought to you to assess and make your decisions on. You're getting oranges, apples, trees, a car … and you're having to figure out which one of those is going to be best for your client to get them where they need to go that is most cost effective and has all the operational benefits that they're seeing. And so, it's like the Wild West of figuring out the best way to document what it needs, allowing the flexibility for the market to respond, and then working with clients to figure out the best way to assess it. And there isn't one way to do it. We're evolving, technology's evolving, so it's this constantly changing market that is thrilling to work in, but it's also hard to sort of keep up all the time with new players coming to the table, new offerings.
Kirsten - And I just want to add in here because I think it's an important point, and it jumps off what you were talking about, Kelly, and that is HH Angus and all our divisions are vendor neutral. And I think that's important to mention. Talk to me a little bit about how you convey that to clients and how that helps us.
Kelly - I think that's what Akira and I like about the work that we do, because it's coming out of a consulting practice where we're there to help our clients get the best solution for them, it allows us to be vendor agnostic, and we work with all of the different players in the market and can assess their strengths and weaknesses and then align that to what the outcomes are that we're trying to achieve. I think that does make it appealing for clients where often, again to what I was saying before, you could go to a specific integration player that has their own product offering, that's then tied to that product line. And you'll be able to get close to what you're looking for, but it's those little bits of customization or where it doesn't necessarily fit in their roadmap that you get stuck on and end up missing those outcomes that you wanted because you're not able to get to exactly what you needed.
Kirsten - So to pick up on what Akira was talking about, Kelly, what are some of the main elements that go into developing a strategy? I think from what you've both said, the first one is figuring out the value proposition, but how do you determine that? And once you've done that, where do you go with the client next?
Kelly - We break it down by first understanding the current state. You're always starting from somewhere. So as Akira was saying, “Have you tried this before? Have you had some failures? What has worked? What hasn't worked? Do you have systems you want to be leveraging?” And then from there, we're doing some market research that's specific for this client. Because technology changes so much, you really have to do a deeper dive on the technologies they're looking for every time just to make sure you're up to date. And then we're bringing that forward and seeing which of those offerings is resonating, or if we're bringing examples of other companies in the industry that have seen success in their outcomes and figuring out what sticks with them. And then from there, we pull together a vision statement of ‘where is this project headed’? And then we start going into the use cases. We need to get to the specifics of the outcomes. And that then informs larger standards, what Akira was mentioning earlier as well.
Once you have your use cases described, you're able to break down the technologies a little bit more. And then you have to set the standard. We're working across all disciplines, so there will be elements that mechanical team needs to understand. There'll be elements of electrical [systems] and then security systems and AV systems. As well, the client's going to have a bunch of operational systems. Their accounting, financial systems, maybe if it's a university or post-secondary, they have a student portal of some sort. You have to have an understanding of all of that in order to make sure you're setting standards that each system is going to be able to feed into the same sort of network of information exchange and information sharing that you can begin to build those use cases from.
Kirsten - I think one of the things that's interesting about the work that both your teams do is working across a variety of industry sectors, because there's the commercial sector, there's education, there's healthcare, then utilities. You're learning from all of these clients as you go along. So let's talk a little bit more, then, about use cases. Akira, you've worked on projects that have implemented strategies for smart building technologies. What would you say are the characteristics of successful use cases?
Akira - Kelly touched on it in the strategy piece. It's being specific. Specificity on the use case allows you to have a use case that you can tie some kind of direct value to. For any kind of commercial organization, for instance, it's like any other part of that business. Unless there's some ROI that you can calculate, why would any business spend money on it? And that's really ultimately what it comes down to. You have to be able to tie some value to it. And if the use case isn't specific, that's really hard to do. So, to me, that's the key element. And I think a good example of this is one of the commercial clients we work with came to us (and we work with an occupancy and presence solution for two of their buildings, one in Ontario and one in Quebec); so, when they came to us, they said, “we want to understand the presence and occupancy in the building.” But what does that mean exactly? Because that can mean a lot of different things. And the question for us was, “why do you want to understand this?”
And after many conversations, there were much more specific things that came out of that - being able to understand how many people were on the floors at any given time, being able to understand what rooms were occupied and what rooms were not occupied, being able to compare whether or not the meeting room distribution that they had made sense for the building. So if they had a whole bunch of large meeting rooms and small meeting rooms, were those being used by the right number of people? Did they right-size or plan their layout in the correct way? They also wanted to be able to understand the building population at any given time to provide that data to their cafeteria, to look at right-sizing [the] amount of food that they might have, or notice trends in any amount of food that people were purchasing. They also wanted to be able to test ‘return to office’s initiatives. If they implemented a ‘return to office’ initiative or changed the in-office requirements or mandates, they wanted to be able to see, “Okay, we've done this for a month. What was the impact of that in the actual occupancy of the building? Did it change? Did the money that we spent on the return to office initiative make sense?” So, each of these things was answering specific questions or driving specific value for the client. But simply to say, “oh, well, we just want to get occupancy.”, that's a place to start, but we have to dive down much more deeply to understand, okay, what are the specific data points and insights that you're looking for?
Kelly - I can add that, on the healthcare side, one of the things we've found in the use cases we've been requiring on some of our larger redevelopment projects, one of the biggest lessons learned is that through our process, you come up with a large list of potential future use cases you'd like to see implemented. But when it comes to opening day, it becomes more important to really whittle down those essential ones that you need because the biggest piece of feedback we have now is, when you go from a traditional building to a smart building, you can get overwhelmed with information. Where you may have five use cases that are really important and could drive great value, if there's 15 that are sort of diluting the experience, it brings the whole thing down. And so that's why we're focusing now on honing in on those really important ones and doing them well and trying to edit the requirements a bit to make sure that we avoid that.
Akira - And I would add that from our side of it as well, we have found the most success starting with a single use case with an organization because, to Kelly's point, it lets you wrap your head around it and figure out how to use this new tool. Like any new thing in our life, we have to figure out how to use it. And then the other part of it is then it's much easier within the organization itself to say, “we did this thing, it's a nice little box with a bow on it, it has this value and it shows the value to the rest of the organization.” And the best part about it is the approach that we typically take is something that is scalable so that you can add use case after use case, bring in new technologies, bring in data sets from other parts of the organization. But to boil the ocean, to use that colloquialism, it just usually ends up in failure.
Kirsten - Good advice. So, in closing, I'm going to ask you both to share with us either a key takeaway for you in what you want people to know about the importance of early stage planning for smart building technologies, or what do you wish clients knew better about the importance of this? Kelly, I'll start with you.
Kelly - So this is something I hear Akira say, which I love, is that we have this wealth of buildings in the world. 99% of the built facilities that we have are existing buildings. And I think people might get stuck in thinking about smart buildings as being only your new buildings when you get to start from scratch. But there's a lot of really exciting work you can do in the existing buildings. And the approach that Akira was mentioning around ‘start with one use case, find that one, what problem do you have in your existing building that you want to solve?’ It's not, it's the turtle or the hare, you know - through the turtle approach, you're going to get to success faster in the end than doing a big bang.
Kirsten – And Akira, your thoughts?
Akira - I would say, and it's kind of in a similar vein, and it's very much related to smart buildings. A) things seem to converge on the digital design, construction, buildings, and whatnot. You know, everybody's talking about digital twins. People get fixated on this thing, and they're like, “we need a digital twin”. And what does that mean? A digital twin can be a lot of different things. And B), a lot of people have an image that there's some visual aspect to it, like you have a 3D model of your building. Is that a digital twin? It's part of a digital twin. But, you know, a true digital twin is something that has enough data enriched within it, that it represents in a digital space, the physical element. So you can start simulating and making decisions from that digital twin. But a lot of people are like, “oh, I got to get this digital twin”. But that is a massive undertaking for most organizations, especially, to Kelly's point, all these existing buildings, right? All of these buildings are existing. Are they all going to have digital twins? Maybe someday. Is there value in that? I don't know. So, the point really is stop thinking about the digital twin, and start thinking about ‘how can I get one piece of value from a smart building technology’, and start from there. I think often organizations are paralyzed in terms of how they start, because they see all these cool presentations at conferences, or they see Autodesk, or a whole other host of vendors talking about these very complex digital twin objects and integrations. My opinion is, and I think Kelly would agree, is not where to start. Start with the one thing, and go from there. Otherwise, again, like anything in our lives, if it's too complicated, or we can't see the value in it, then it's not going to go anywhere.
Kirsten - Very true. And I think very safe to say that having a strategy, a clarified strategy for smart building technologies is really important in meeting the needs of the occupants and in supporting the design vision. Kelly, Akira, thank you so much for sharing your experiences and your expertise today, for our look at smart building technology strategies, and why it's important to make these an early and integral part of the design process.
Our guests today have been Akira Jones and Kelly Henderson from HH Angus' Digital Services and Angus Connect Divisions respectively.
To all our listeners, thank you for joining us today. If you're interested in connecting with our experts about any aspect of smart building design and technology, you can reach us anytime through our contact page at hhangus.com. Again, that's hhangus.com. I'm Kirsten Nielsen - we look forward to connecting with you again on our next podcast here on Expanding the Possible. Have a great day!