Episode 11, “Improve Project Outcomes with ISO 19650”
Kirsten Nielsen:
Hello and welcome to Expanding the Possible, I'm Kirsten Nielsen. In today's conversation, we're exploring how digital requirements can lead to better project outcomes and how industry frameworks like ISO 19650 can support this in the Canadian market. Our guest today is Krigh Bachmann, design technology leader at HH Angus.
Krigh has 20 plus years of design experience and technical expertise. And along the way over those 20 years, he's developed somewhat of a passion and compelling vision for integrating digital technology to successfully design and deliver building infrastructure. Welcome, Krigh.
Krigh Bachmann:
Thank you for having me.
Kirsten:
Before we jump into our topic for today, tell us a little bit about your work as design technology leader. What does that mean and what are you working on?
Krigh:
Well, design technology is kind of an expanding field where many of us, you know, have sort of been in the industry and grown up with CAD, which evolved into BIM. But design technology really kind of looks at things much broader than that, is that the amount of tools and processes that we're looking at as we leverage technology in the process of design is really expanded. And so we're expanding that term to kind of look at things holistically.
I joined HH Angus earlier this year as part of an expanding and awesome team here. And really my focus within the firm is to look at things sort of holistically across the firm at sort of a strategic level to kind of say what processes are we using across the board or what technology can we look at that applies to larger teams or whole disciplines and sort of a step back and sort of look at it at a strategic level so that we can ensure that our teams can deliver what they really need to in the end.
Kirsten:
Thanks for that. So you've worked on a lot of different types of projects, including incorporating into the design process concepts such as, and I'm going to read this so I don't miss any, smart buildings, digital delivery contract language, generative artificial intelligence and digital twins. Tell me about the relevance of the digital requirements in the context of your work.
Krigh:
I think when it comes to the, like, with the tools that we're starting to look at, it's expanded beyond just, you know, producing drawings and trying to document stuff. It's that really what we're looking at in the whole process is the information that we're managing during the process, how we're leveraging data. And that bigger piece of when you start to think about managing larger pieces of information and information through a process, you start to, you know, really have to set out your goals ahead of time to really be able to deliver and successfully sort of deliver them. I think that, you know, traditionally when we think about delivering design, we think about, okay, if you start a project, you know, you have to define the design up front, is that if you want to build a building, you really have to know what is it that we're building. You can't just say, I want a hospital or I want a commercial centre, is you really have to define what those requirements are.
When it comes to digital deliverables, that same sort of philosophy is true, is that we really want to start with kind of defining that up front. And as all of these increasing different processes and tools, and I think, you know, a lot of people get caught up in buzzwords like AI these days, but I think really when it comes to it, these things are increasing our awareness of how important the digital aspect of what's happening in our projects is. And so with that, we are trying to work to sort of better define what those outcomes are up front and so that we can actually deliver them properly on projects.
Kirsten:
Where should people start with defining their requirements? Are there standard documents? Are there templates they can use to kind of begin that process?
Krigh:
I think that it can seem a bit daunting when you first get into looking at this, is because we're so used to kind of understanding the physical aspects of projects, but really the digital realm can be very, you know, unlimited. And at the same time, there's a lot of people that also have that aspect of, oh, well, it's digital, so do we really have to define it up front? It's so easy to just kind of click buttons and suddenly something new happens on a project.
I think when it comes to defining those digital requirements, there are standards and places that can help people. And you can jump right into standards and kind of get caught up in things. And as you mentioned, the ISO-19650 standard, for example, is one example of that. But I also like to sort of express to people to understand the philosophy of them, is that, for example, the ISO-19650 standard is, I consider it as a framework. It kind of explains to you, it doesn't give you, you should deliver exactly this. It sort of says, these are the steps that you need to start with. As an example, in the 19650 standard, the piece that I really took away from it and that I like to express to people is the philosophy of it. It sort of starts by saying, what are your business drivers? What are you trying to achieve on a project? And you start with kind of those high-level organizational objectives. It's how do you want to design this project? How do you want to maintain the project afterwards? And those then will drive how you're actually going to do that, which then will inform what's the pieces of information that you need delivered or what are the processes digitally that you want to work as part of it.
And so, with that in mind, those different steps, if you kind of understand it as a philosophy or a framework, it actually makes quite a bit of sense. And then if you actually dig into it and actually get into the ISO standard, you realize, okay, we've actually got acronyms that we can put to those and everyone can kind of get around standard definitions of how to capture them. But really, it's kind of understanding those first steps that you need to do to engage in it and to start with them. And I think that's why I like the ISO standard so much and why I've been recommending it to others.
Kirsten:
I absolutely love that you're bringing philosophy into ISO standards. I think that really warms it up for a lot of people. What's your sense of how widely ISO-19650 is being adopted across the AEC industry in Canada? Do you think there's a broad awareness of it among AEC professionals?
Krigh:
I think amongst the firms that are designing it and the construction teams, I think a lot of people have heard of it. I don't necessarily think a lot of them are using it fully at this point. And I think that the main driver of that is that on the end client side of things, there are a lot fewer people that understand it and have gone into it. And I think really when I started learning about BIM Level 2, which was its predecessor before it became an ISO standard, I was in the UK when they rolled it out as a government mandate. I think that it was one of those ones that we really started to realize that this is something that needs to be kind of driven on the client side of things. But at the same time, even within our own firm, we can sort of look to use it as a framework for how we want to define things and work with it.
I think that there is a growing awareness within the Canadian market. I think there's a lot more people that have started to realize, as I've sort of said, if you take a step back and you kind of look at it and say, okay, less so as an exact word for word, but if you understand the philosophy of it, who wouldn't want a project where things are defined better up front? It leads to better delivery, leads to better understanding of pricing for your project. If you understand what the digital outcomes are of it, you understand how your team has to be set up for success and be able to deliver exactly what the client wants in the end.
Kirsten:
In your experience, do you think people find the standard challenging to navigate?
Krigh:
Oh, absolutely. I think it's one of those ones where any time you get into an ISO standard, it starts to get wordy and it starts to get into acronyms. I mean, I've sat down with people and they're all like, do we have an EIR on this project? And you're sitting there going, okay, what is an EIR? And that one was probably batted around the most. And then as they evolved the standard, it started to add an AIR and an OIR and a PIR and all these different acronyms. So from that standpoint, I would sort of say really start with conversations about it and when you understand that sort of philosophy of it and what it's trying to achieve. And there's some things that are a bit more technical in it.
But as an example, a common data environment is one of the things that it mentions, which is, again, known as an acronym of CDE. But if you ignore that and you sort of say, on a project, wouldn't we like to have a central place that we're putting our files, as opposed to emailing them back and forth where somebody might be missed on a correspondence? And most people would say, yes, that makes sense. Well, that's a common data environment. And so if you understand what it's trying to do, I think there's too many people that dive into things and immediately say, oh, you need to know the ISO standard. You need to get into the technical aspect of it. And they just get overwhelmed by all the terms. But if you kind of take a step back and understand it, sort of more of what it's trying to achieve, it does kind of lead to better success on that side of things.
Kirsten:
So, you were talking about having the common information. Is the ISO standard 19650 a necessary step if you're looking to improve your project efficiency, if you want to reduce errors, that kind of thing?
Krigh:
I think that from our standpoint, the specific ISO standard definitely helps in that it helps define that. But again, kind of thinking about what the most critical part about it is being clear about what is it that you're trying to achieve and what is the information that you want done or what are the design processes that you want teams to use? I think a lot of people get overwhelmed and they also think, oh, we need to be asking for everything. And I think a lot of this is from a digital aspect of really starting with, okay, what's the most critical information or what are the best practices that everyone kind of agrees should be there? And I think if you start from that sort of early stage of kind of saying, okay, let's start small and grow, it also isn't that daunting to take on.
So I think that from that standpoint, it can lead to much better projects because everybody's clear on what we're doing. When we sit down with other teams, we like to define up front with, well, this is our standard way of working so that if it's not defined, we've got a way of everyone's clear as to what we will be doing digitally on a project. And I think that the risks that are in our industry and the confusion that can happen is when things aren't defined up front as people just kind of enter it. And in the past, over the last little while, we've said, oh, it's a BIM project. And everyone assumes, well, we know what BIM is, but BIM can be many things to many people. So by having that defined up front, it's that clear understanding of this is what we mean when we say BIM.
Kirsten:
Apart from all the acronyms that these standards typically have, what are some of the common challenges you see that clients are facing when they're trying to understand the ISO-19650 and how they can incorporate it into their digital practices?
Krigh:
I think one of the biggest challenges we have right now is that from a digital standpoint, we think, okay, if this is for a specific project, let's start it at the same time as the project. I've been on large projects before where as the design is starting to roll, they're also trying to define what their digital deliverables are. And really, a lot of those things, because they're actually driven by business objectives, can actually be worked out on a project before you actually have dived into the design process. And so I think definitely starting those conversations earlier in the process is important. From the standpoint of delivery of a project, a lot of that happens with CapEx teams.
But a lot of the information that we can see within the BIM process, which this is really an opportunity for owners and operators to leverage as part of the operations side of things, they can't really draw that out unless they bring their operations team to the table as well. So having your CapEx and your OpEx teams at the table before a project starts and having the two come together to really define your objectives I think is important. But I think the biggest thing about this is really making the time and the space to really do this ahead of a project and be able to define it. I've seen projects where people are very eager to kind of engage in this process. They know that they can leverage it and they can get better outcomes, but they haven't necessarily taken the time. They really want to just copy and paste from a past project or an example somebody has given them.
I like to say to clients, we're not here to just define your requirements for you. You have to ask the question of what do you really want to get out of this process? And I've seen it right up to the point where going back to those information requirements, I've seen people post examples on the Internet. And then they even got to the point where they replaced the PDF with just a PDF of a statement saying too many people were copying and pasting this into their project and using it, not really understanding what it is. So I had to replace this PDF with a blank document. And it starts to really show that I think there's some people that are sort of struggling in how they can engage in that process, but really understanding it's not huge up to the beginning of a journey, but it really has to kind of start with the clients and the teams asking what do they want to get out of that process and what's that first step and sort of moving towards it.
Kirsten:
What do you think are the barriers to people not doing that? Is it because they don't understand how to do it or is it because it takes weeks or months, in their mind, of how they're going to establish what this common framework is before they get into design?
Krigh:
I think that part of it is that it feels a little bit foreign because it is a digital process and not what we've been doing for years and kind of the physical aspect of it. But I think as BIM has been around in our industry for quite a couple of decades now, I think that people are starting to get that awareness of it. I think that there's a little bit of hesitation on the ISO standard side of things and that we've sort of seen mixed opinions about international standards on that side of things. But I think a lot of it is that they really have to kind of start with that idea of how to start small and build on it. So, from that aspect, I think it is something that they could grow with and can expand on, but has to kind of start with them looking at it at really what they want to achieve in the end.
Now, I realized I probably should clarify for users what exactly is a digital deliverable because I've been patting it around a lot in this conversation, but I also feel like some people out there might still asking the question, well, okay, what exactly is a digital deliverable? And I'll give sort of two examples in the sense of there's either something that is required as kind of a deliverable in the end of the project, or there's something where you're trying to make better informed decisions or trying to improve the quality of the projects sort of as affecting the design process. So, if we think about it on the sort of deliverable side of things, we have certain client groups that we work with that they have made the decision that during the operations of their facilities, they've got a business decision. For example, they want to improve the operations side of things. And part of that might be something like proactive maintenance of their facilities. And to do so, they need to keep track of all their maintainable assets, things like HVAC equipment or any sort of plumbing mechanical, electrical equipment, anything that sort of has regular maintenance done on it.
And as part of that, if they're sort of thinking about it from that standpoint of business goal is they want to be proactive on their maintenance, they want to improve it, they want to be more efficient on this, then from that, that makes that informed decision on how they maintain their facilities going forward. And that maintenance of their facilities is, you know, they're going to implement a certain building automation systems and a certain, you know, sort of work order system and everything else, like their integrated technology approach and how they actually run their facilities. And as part of that, there are certain information and data that they can input into there. And a lot of it is, you know, lists of equipment, their location, what's their warranty information, the model numbers, the serial numbers. Now, a lot of that in the BIM process is actually developed. It's during the design process, we know, for example, what types of equipment, where are they located, which buildings are they in?
That sort of preliminary stuff. And then that information during the construction phase can be embellished with what the construction team actually procures. So did they actually buy this unit? And what's the model number? What's the serial number? And so by the time you actually get through the process, if the teams know upfront that that is a deliverable, they can actually start to pass that information down the line so that by the time the project is delivered, there is an information deliverable. And then that information is passed over to the operations team, is actually incorporated into the way the facility will be run, is they can actually feed that information in. But I should be clear, that's also something that doesn't happen automatically in most jobs. We do not collect this information and export it out just on any project. We actually have to know that that's a deliverable. And so as part of this, defining those things up front means that our teams can actually price appropriately for it, that they know it's coming, and that they can actually deliver it. We've been asked for digital deliverables sometimes on projects in the past where they said, oh, you know, we've just figured out that we want to maintain the facility using this software. Can we get this data? And we were like, well, if you had asked us at the beginning of the project, it would have been an easy thing to work out.
But now it's a whole big, we have to go back in and add this into our database and actually manage it and sort of be able to do a lot more. And so like any sort of, you know, design process or deliverable, the earlier we know about this, the better. And that's how we sort of see this is that, again, thinking about that idea of defining things up front, we really want to have that worked out at the beginning.
The other side of things is understanding that there are certain best practices in our industry about how we can design projects. So as an example, what type of, you know, generally which things are being coordinated in 3D. There's systems and software processes like clash detection, finding where there's conflicts in the design models before they get out on site, for example. These are things that improve the quality of the project and clients may actually ask certain teams to actually do this. And they may say, well yes, our minimum expectation is that the following things will be coordinated in 3D. That's kind of, you know, and it may not be a deliverable per se, but it's a process that's being asked for. And maybe the reports out on sort of showing them the resolution or the resolving of the clashes, that might be the deliverable, is to kind of ensure that that's part of it.
The other side of things might be something where, you know, from a standpoint of budgeting, there might be, as we're going through the design process, there's certain groups that want to keep track of, you know, well, how many of these particular units do we have in the facility? Simple exports out into things like Excel can be used for pricing and preliminarily pricing, but that can be used as part of the process to help inform the client team making decisions about where they are. But again, it's something that has to be appropriately known for the teams so that we can actually work it into our processes and make it easier.
And so hopefully these examples kind of give a sense of how, yes, it's definitely something that you can leverage the data for both during the design process and during the operations, but I think it's something that has to be seen as something that has to happen up front in order to really benefit or really get the most out of it and make sure that everybody's aligned on kind of understanding what that deliverable is.
Kirsten:
When you look at existing BIM practices and industry standards and guidelines in Canada, how does ISO-19650 align with those?
Krigh:
I think what we're starting to see is that more people are realizing that it does align with what they want. I think that we haven't really had proper BIM standards in Canada. We're starting to see it show up more on sort of federal government projects, a lot more is kind of awareness. I think a lot of it is that people are starting to really understand, okay, what that framework is for and how it helps them on projects. I think that up until now, a lot of groups have sort of said, oh, like even in the conversations we've had about 19650, it's an international standard and people will look at it and say, oh, well, it's an international standard. How do we make it Canadian then? Yes, there's been groups that have developed Canadian annexes of it, like little sort of pieces that you tack on to make it more Canadian, but at the same time, like when, you know, going back to that original idea of what the philosophy of it is about, if you understand that sort of framework, it's really like defining your objectives of what you want delivered on a project and those are driven by business objectives. That's really something that is international. It is something that all of the projects I've worked on in Canada have had that sort of same desire to do that upfront.
So from that standpoint, I think that we're seeing more adoption of it within Canada, but at the same time, everyone kind of is a little bit hesitant in that I think unlike places like Europe and the UK that I've worked, we're a little bit more hesitant to embrace standards. But at the same time, I think a lot more people are sort of pushing away that barrier and kind of actually looking at what we really want to accomplish in the end, which is we want success on our projects.
Kirsten:
You mentioned government and that leads into something else I wanted to ask you about, and that is whether the ISO 19650 standards are currently being mandated by governments, whether those are provincial or federal, and the role that governments play in promoting the use of the standard.
Krigh:
I think that it's definitely important. I think that in the sense of when I was in the UK and the government mandated on all their large projects, it actually wasn't so much the government projects that it impacted, but the private sector because it really rose this awareness within the private sector that we started seeing all of our private clients going, well, hold on a second. If the government's mandating this, why is that? And they started looking at the standard going, hey, this actually makes sense. And so they started embracing the same terminology. They started embracing the same language.
And going back to my comment, I think where everyone wants to make it their own, I think there's a balance to be struck in that, yes, you can understand the philosophy, but I also don't think people should be reinventing the wheel. So do I think that the government should be mandating it? I think it would help if they did it on their projects because I think that it would sort of solidify and sort of saying to Canadians, yes, this is a standard that we believe can make your projects better and can lead to better success. I think that if they did that, it would, you know, help the rest of the industry embrace it. And I think that that would follow suit then for, you know, how that cascades down to more of the municipalities. I worked with BIM for local governments, for example, in the UK, which was a group that then took the national standards and applied it at more of the local level. And that happened because of that government mandate.
Kirsten:
You were just talking about BIM. How does BIM technology support ISO-19650 in Canada?
Krigh:
So I should clarify that the standard, the ISO-19650 really was written around BIM. It's written around that sort of idea of, because really when you get back to it, a lot of people think of BIM as Revit and 3D models, but really BIM is information management. And so the ISO standard, 19650, was a BIM standard. But at the same time, we've actually worked on projects where a client was interested, for example, on a campus project in looking at implementing more of a digital twin, as sort of a very advanced, holistic technology solution. When they went to do this, there is no digital twin standard yet. So we were actually looking at how we used the 19650 framework, that same idea of defining your business objectives up front, which leads to what you're trying to do. In this case, they wanted to do a digital twin of their campus. And that then could be applied to what the information is that then on future projects, that campus would be asking for anyone that designed a facility for their project or built it on their facility. And so we used the 19650 standard through, as that framework to be able to help them deliver it in the end. So the standard is focused on BIM, but we've seen it being able to leverage it for much more.
Kirsten:
Going back to what you were talking about in terms of people wanting to customize or add sections to the standard to make it more Canadian, are you seeing, or do you know whether there are regional differences between how provinces adopt the standard?
Krigh:
There's definitely differences in how they've adopted it or their rate of adoption. I think a lot of them will try to sort of go in there and change the acronyms a little bit and the terms that they use. But ultimately what we've seen in the end, in the most successful projects, the larger sort of groups within different regions that have adopted it, a lot of it is that they have jumped into it and sort of embrace that philosophy of that. When you boil it down, whether they're giving it a new fancy acronym for their information requirements, as long as everyone kind of can look at it and go, okay, this is the information they're asking for. But behind that we can see, you know, this is their strategy of what the information is going into, like what type of system or why they're, you know, asking for this as part of the design process. And then the business drivers business drivers behind that. If we understand those steps it's effectively the same thing. So from that standpoint we have seen different people use it in different ways and different rates of adoption but effectively a lot of it is heading down the same road of trying to get to the same deliverable in the end.
Kirsten:
What's your take on the impact that the standard's having on improving collaboration between all the different stakeholders - the architects, engineers, contractors and the project owners themselves. Is it starting to have an impact?
Krigh:
I would say yes. From my perspective of I think that us having those conversations up front with different groups and understanding it even if we work on a project for example within HHA that isn't necessarily an ISO certified project or that the clients properly define their information requirements, we within our processes will try to bring that same idea to what we want to as an organization want to achieve on a project.
So if we want to deliver higher quality projects, if we want to make ensure that the information that we need to coordinate our designs is there, we'll define those up front and be able to coordinate that with other consultants. So we still take elements of the standard and apply it on our projects and we've seen more of those conversations between us and other organizations of trying to get to that sort of unified approach and I think that in the end as that grows and as we get more people on I think we'll definitely have it sort of a growing awareness of it and it will lead to better outcomes. But for now it may be a bit more in sort of the conversational aspect of understanding it and I've seen this on projects where it's like as you coordinate if you both understand oh we're defining an information requirement then we both you know can speak that same language and ensure that we're aligned.
Kirsten:
Let me ask you to look in your crystal ball now and tell me what do you see as the future of ISO 19650 in Canada and do you think there's going to be changes to the standard that's going to affect what we do here in Canada, or is it kind of a, you know, ‘this is how we're going to go forward’?
Krigh:
I think as we have more conversations I think a lot of it is people understanding okay what is it really ultimately trying to get to and as I've sort of said even as we get into more advanced things I think we're sort of at this odd point in our industry where yes BIM has been around for quite a while but we're still sort of finding the inconsistency on projects and or inconsistency on deliverables and you know that doesn't lead to the best deliverables in the end you know so from that standpoint I think that it does still have a future in what we're doing. I believe that you know I still in all my time I've ever since getting on board with BIM Level 2 is I even if I push it aside when we get into conversations about it and everyone says oh you know how do we define this project and it's all done in level of detail and this term LODs and or are we delivering big spreadsheets of information and it's kind of like well by having this framework in place you have that up front so I think that as we move forward I think it's definitely got a place but as I sort of said I don't necessarily always I'm a big advocate of it but at the same time I don't necessarily try to tell people oh you must get ISO certified is really take a step back and sort of say okay how do you how do you sort of understand it at that sort of what you're trying to do in the end.
Kirsten:
We've covered a lot of ground here Krigh so let me just perhaps close on a question of, in your new role, how can we help clients understand the ISO 19650 standard or help them on the journey to exploring it?
Krigh:
I think that it really as I've kind of alluded to it starts with a conversation. I am already starting to talk with some of our clients on this side of things and if there's anybody that is interested in kind of understanding it I think it is a great place to start because I think that as I've said it doesn't have to be a big onerous task of kind of taking on a big certification or anything like that but really to start with those conversations of because we used to get in I've had this happen where I sit down it's like okay what would you like to get out of your BIM process and it's what can I get out of my BIM process and you know it's a digital frontier is a new thing to some people and I think from that standpoint it can seem daunting because you get into the situation where it's like well okay well then we'll ask for everything and it's like well no that'll add cost to the project because you're getting you know a digital deliverable is still a deliverable so you ask for too much and you're starting to increase the workload of the teams that are working for you.
So I think it's really more of a building case to sort of start the conversation understand where it is start to build that in-house knowledge within your organization but really we want to have conversations with our clients to help them along their journey to sort of say you know where do they want to start what's that first step and where do they ultimately want to get to in the end because I think if you really get back to it and start to understand that and start to understand the path forward then it you can start by taking a step back and it doesn't have to be when there's a project on the table is that as I said a lot of the better successes we've seen is you know for a group you know that knows that they've got projects coming up start now because really a lot of this stuff can be worked out well before the actual you know design of a facility is started.
Kirsten:
Thank you Krigh. Our guest today has been Krigh Bachman, design technology leader at HH Angus and Associates. To our listeners if you're interested in contacting Krigh about any aspect of ISO 19650 you can reach out to us anytime through our contact page at hhangus.com again that's hhangus.com. I'm Kirsten Nielsen.
Thank you for joining us today on Expanding the Possible. We look forward to connecting with you again on our next podcast. Have a great day.
Hello and welcome to Expanding the Possible, I'm Kirsten Nielsen. In today's conversation, we're exploring how digital requirements can lead to better project outcomes and how industry frameworks like ISO 19650 can support this in the Canadian market. Our guest today is Krigh Bachmann, design technology leader at HH Angus.
Krigh has 20 plus years of design experience and technical expertise. And along the way over those 20 years, he's developed somewhat of a passion and compelling vision for integrating digital technology to successfully design and deliver building infrastructure. Welcome, Krigh.
Krigh Bachmann:
Thank you for having me.
Kirsten:
Before we jump into our topic for today, tell us a little bit about your work as design technology leader. What does that mean and what are you working on?
Krigh:
Well, design technology is kind of an expanding field where many of us, you know, have sort of been in the industry and grown up with CAD, which evolved into BIM. But design technology really kind of looks at things much broader than that, is that the amount of tools and processes that we're looking at as we leverage technology in the process of design is really expanded. And so we're expanding that term to kind of look at things holistically.
I joined HH Angus earlier this year as part of an expanding and awesome team here. And really my focus within the firm is to look at things sort of holistically across the firm at sort of a strategic level to kind of say what processes are we using across the board or what technology can we look at that applies to larger teams or whole disciplines and sort of a step back and sort of look at it at a strategic level so that we can ensure that our teams can deliver what they really need to in the end.
Kirsten:
Thanks for that. So you've worked on a lot of different types of projects, including incorporating into the design process concepts such as, and I'm going to read this so I don't miss any, smart buildings, digital delivery contract language, generative artificial intelligence and digital twins. Tell me about the relevance of the digital requirements in the context of your work.
Krigh:
I think when it comes to the, like, with the tools that we're starting to look at, it's expanded beyond just, you know, producing drawings and trying to document stuff. It's that really what we're looking at in the whole process is the information that we're managing during the process, how we're leveraging data. And that bigger piece of when you start to think about managing larger pieces of information and information through a process, you start to, you know, really have to set out your goals ahead of time to really be able to deliver and successfully sort of deliver them. I think that, you know, traditionally when we think about delivering design, we think about, okay, if you start a project, you know, you have to define the design up front, is that if you want to build a building, you really have to know what is it that we're building. You can't just say, I want a hospital or I want a commercial centre, is you really have to define what those requirements are.
When it comes to digital deliverables, that same sort of philosophy is true, is that we really want to start with kind of defining that up front. And as all of these increasing different processes and tools, and I think, you know, a lot of people get caught up in buzzwords like AI these days, but I think really when it comes to it, these things are increasing our awareness of how important the digital aspect of what's happening in our projects is. And so with that, we are trying to work to sort of better define what those outcomes are up front and so that we can actually deliver them properly on projects.
Kirsten:
Where should people start with defining their requirements? Are there standard documents? Are there templates they can use to kind of begin that process?
Krigh:
I think that it can seem a bit daunting when you first get into looking at this, is because we're so used to kind of understanding the physical aspects of projects, but really the digital realm can be very, you know, unlimited. And at the same time, there's a lot of people that also have that aspect of, oh, well, it's digital, so do we really have to define it up front? It's so easy to just kind of click buttons and suddenly something new happens on a project.
I think when it comes to defining those digital requirements, there are standards and places that can help people. And you can jump right into standards and kind of get caught up in things. And as you mentioned, the ISO-19650 standard, for example, is one example of that. But I also like to sort of express to people to understand the philosophy of them, is that, for example, the ISO-19650 standard is, I consider it as a framework. It kind of explains to you, it doesn't give you, you should deliver exactly this. It sort of says, these are the steps that you need to start with. As an example, in the 19650 standard, the piece that I really took away from it and that I like to express to people is the philosophy of it. It sort of starts by saying, what are your business drivers? What are you trying to achieve on a project? And you start with kind of those high-level organizational objectives. It's how do you want to design this project? How do you want to maintain the project afterwards? And those then will drive how you're actually going to do that, which then will inform what's the pieces of information that you need delivered or what are the processes digitally that you want to work as part of it.
And so, with that in mind, those different steps, if you kind of understand it as a philosophy or a framework, it actually makes quite a bit of sense. And then if you actually dig into it and actually get into the ISO standard, you realize, okay, we've actually got acronyms that we can put to those and everyone can kind of get around standard definitions of how to capture them. But really, it's kind of understanding those first steps that you need to do to engage in it and to start with them. And I think that's why I like the ISO standard so much and why I've been recommending it to others.
Kirsten:
I absolutely love that you're bringing philosophy into ISO standards. I think that really warms it up for a lot of people. What's your sense of how widely ISO-19650 is being adopted across the AEC industry in Canada? Do you think there's a broad awareness of it among AEC professionals?
Krigh:
I think amongst the firms that are designing it and the construction teams, I think a lot of people have heard of it. I don't necessarily think a lot of them are using it fully at this point. And I think that the main driver of that is that on the end client side of things, there are a lot fewer people that understand it and have gone into it. And I think really when I started learning about BIM Level 2, which was its predecessor before it became an ISO standard, I was in the UK when they rolled it out as a government mandate. I think that it was one of those ones that we really started to realize that this is something that needs to be kind of driven on the client side of things. But at the same time, even within our own firm, we can sort of look to use it as a framework for how we want to define things and work with it.
I think that there is a growing awareness within the Canadian market. I think there's a lot more people that have started to realize, as I've sort of said, if you take a step back and you kind of look at it and say, okay, less so as an exact word for word, but if you understand the philosophy of it, who wouldn't want a project where things are defined better up front? It leads to better delivery, leads to better understanding of pricing for your project. If you understand what the digital outcomes are of it, you understand how your team has to be set up for success and be able to deliver exactly what the client wants in the end.
Kirsten:
In your experience, do you think people find the standard challenging to navigate?
Krigh:
Oh, absolutely. I think it's one of those ones where any time you get into an ISO standard, it starts to get wordy and it starts to get into acronyms. I mean, I've sat down with people and they're all like, do we have an EIR on this project? And you're sitting there going, okay, what is an EIR? And that one was probably batted around the most. And then as they evolved the standard, it started to add an AIR and an OIR and a PIR and all these different acronyms. So from that standpoint, I would sort of say really start with conversations about it and when you understand that sort of philosophy of it and what it's trying to achieve. And there's some things that are a bit more technical in it.
But as an example, a common data environment is one of the things that it mentions, which is, again, known as an acronym of CDE. But if you ignore that and you sort of say, on a project, wouldn't we like to have a central place that we're putting our files, as opposed to emailing them back and forth where somebody might be missed on a correspondence? And most people would say, yes, that makes sense. Well, that's a common data environment. And so if you understand what it's trying to do, I think there's too many people that dive into things and immediately say, oh, you need to know the ISO standard. You need to get into the technical aspect of it. And they just get overwhelmed by all the terms. But if you kind of take a step back and understand it, sort of more of what it's trying to achieve, it does kind of lead to better success on that side of things.
Kirsten:
So, you were talking about having the common information. Is the ISO standard 19650 a necessary step if you're looking to improve your project efficiency, if you want to reduce errors, that kind of thing?
Krigh:
I think that from our standpoint, the specific ISO standard definitely helps in that it helps define that. But again, kind of thinking about what the most critical part about it is being clear about what is it that you're trying to achieve and what is the information that you want done or what are the design processes that you want teams to use? I think a lot of people get overwhelmed and they also think, oh, we need to be asking for everything. And I think a lot of this is from a digital aspect of really starting with, okay, what's the most critical information or what are the best practices that everyone kind of agrees should be there? And I think if you start from that sort of early stage of kind of saying, okay, let's start small and grow, it also isn't that daunting to take on.
So I think that from that standpoint, it can lead to much better projects because everybody's clear on what we're doing. When we sit down with other teams, we like to define up front with, well, this is our standard way of working so that if it's not defined, we've got a way of everyone's clear as to what we will be doing digitally on a project. And I think that the risks that are in our industry and the confusion that can happen is when things aren't defined up front as people just kind of enter it. And in the past, over the last little while, we've said, oh, it's a BIM project. And everyone assumes, well, we know what BIM is, but BIM can be many things to many people. So by having that defined up front, it's that clear understanding of this is what we mean when we say BIM.
Kirsten:
Apart from all the acronyms that these standards typically have, what are some of the common challenges you see that clients are facing when they're trying to understand the ISO-19650 and how they can incorporate it into their digital practices?
Krigh:
I think one of the biggest challenges we have right now is that from a digital standpoint, we think, okay, if this is for a specific project, let's start it at the same time as the project. I've been on large projects before where as the design is starting to roll, they're also trying to define what their digital deliverables are. And really, a lot of those things, because they're actually driven by business objectives, can actually be worked out on a project before you actually have dived into the design process. And so I think definitely starting those conversations earlier in the process is important. From the standpoint of delivery of a project, a lot of that happens with CapEx teams.
But a lot of the information that we can see within the BIM process, which this is really an opportunity for owners and operators to leverage as part of the operations side of things, they can't really draw that out unless they bring their operations team to the table as well. So having your CapEx and your OpEx teams at the table before a project starts and having the two come together to really define your objectives I think is important. But I think the biggest thing about this is really making the time and the space to really do this ahead of a project and be able to define it. I've seen projects where people are very eager to kind of engage in this process. They know that they can leverage it and they can get better outcomes, but they haven't necessarily taken the time. They really want to just copy and paste from a past project or an example somebody has given them.
I like to say to clients, we're not here to just define your requirements for you. You have to ask the question of what do you really want to get out of this process? And I've seen it right up to the point where going back to those information requirements, I've seen people post examples on the Internet. And then they even got to the point where they replaced the PDF with just a PDF of a statement saying too many people were copying and pasting this into their project and using it, not really understanding what it is. So I had to replace this PDF with a blank document. And it starts to really show that I think there's some people that are sort of struggling in how they can engage in that process, but really understanding it's not huge up to the beginning of a journey, but it really has to kind of start with the clients and the teams asking what do they want to get out of that process and what's that first step and sort of moving towards it.
Kirsten:
What do you think are the barriers to people not doing that? Is it because they don't understand how to do it or is it because it takes weeks or months, in their mind, of how they're going to establish what this common framework is before they get into design?
Krigh:
I think that part of it is that it feels a little bit foreign because it is a digital process and not what we've been doing for years and kind of the physical aspect of it. But I think as BIM has been around in our industry for quite a couple of decades now, I think that people are starting to get that awareness of it. I think that there's a little bit of hesitation on the ISO standard side of things and that we've sort of seen mixed opinions about international standards on that side of things. But I think a lot of it is that they really have to kind of start with that idea of how to start small and build on it. So, from that aspect, I think it is something that they could grow with and can expand on, but has to kind of start with them looking at it at really what they want to achieve in the end.
Now, I realized I probably should clarify for users what exactly is a digital deliverable because I've been patting it around a lot in this conversation, but I also feel like some people out there might still asking the question, well, okay, what exactly is a digital deliverable? And I'll give sort of two examples in the sense of there's either something that is required as kind of a deliverable in the end of the project, or there's something where you're trying to make better informed decisions or trying to improve the quality of the projects sort of as affecting the design process. So, if we think about it on the sort of deliverable side of things, we have certain client groups that we work with that they have made the decision that during the operations of their facilities, they've got a business decision. For example, they want to improve the operations side of things. And part of that might be something like proactive maintenance of their facilities. And to do so, they need to keep track of all their maintainable assets, things like HVAC equipment or any sort of plumbing mechanical, electrical equipment, anything that sort of has regular maintenance done on it.
And as part of that, if they're sort of thinking about it from that standpoint of business goal is they want to be proactive on their maintenance, they want to improve it, they want to be more efficient on this, then from that, that makes that informed decision on how they maintain their facilities going forward. And that maintenance of their facilities is, you know, they're going to implement a certain building automation systems and a certain, you know, sort of work order system and everything else, like their integrated technology approach and how they actually run their facilities. And as part of that, there are certain information and data that they can input into there. And a lot of it is, you know, lists of equipment, their location, what's their warranty information, the model numbers, the serial numbers. Now, a lot of that in the BIM process is actually developed. It's during the design process, we know, for example, what types of equipment, where are they located, which buildings are they in?
That sort of preliminary stuff. And then that information during the construction phase can be embellished with what the construction team actually procures. So did they actually buy this unit? And what's the model number? What's the serial number? And so by the time you actually get through the process, if the teams know upfront that that is a deliverable, they can actually start to pass that information down the line so that by the time the project is delivered, there is an information deliverable. And then that information is passed over to the operations team, is actually incorporated into the way the facility will be run, is they can actually feed that information in. But I should be clear, that's also something that doesn't happen automatically in most jobs. We do not collect this information and export it out just on any project. We actually have to know that that's a deliverable. And so as part of this, defining those things up front means that our teams can actually price appropriately for it, that they know it's coming, and that they can actually deliver it. We've been asked for digital deliverables sometimes on projects in the past where they said, oh, you know, we've just figured out that we want to maintain the facility using this software. Can we get this data? And we were like, well, if you had asked us at the beginning of the project, it would have been an easy thing to work out.
But now it's a whole big, we have to go back in and add this into our database and actually manage it and sort of be able to do a lot more. And so like any sort of, you know, design process or deliverable, the earlier we know about this, the better. And that's how we sort of see this is that, again, thinking about that idea of defining things up front, we really want to have that worked out at the beginning.
The other side of things is understanding that there are certain best practices in our industry about how we can design projects. So as an example, what type of, you know, generally which things are being coordinated in 3D. There's systems and software processes like clash detection, finding where there's conflicts in the design models before they get out on site, for example. These are things that improve the quality of the project and clients may actually ask certain teams to actually do this. And they may say, well yes, our minimum expectation is that the following things will be coordinated in 3D. That's kind of, you know, and it may not be a deliverable per se, but it's a process that's being asked for. And maybe the reports out on sort of showing them the resolution or the resolving of the clashes, that might be the deliverable, is to kind of ensure that that's part of it.
The other side of things might be something where, you know, from a standpoint of budgeting, there might be, as we're going through the design process, there's certain groups that want to keep track of, you know, well, how many of these particular units do we have in the facility? Simple exports out into things like Excel can be used for pricing and preliminarily pricing, but that can be used as part of the process to help inform the client team making decisions about where they are. But again, it's something that has to be appropriately known for the teams so that we can actually work it into our processes and make it easier.
And so hopefully these examples kind of give a sense of how, yes, it's definitely something that you can leverage the data for both during the design process and during the operations, but I think it's something that has to be seen as something that has to happen up front in order to really benefit or really get the most out of it and make sure that everybody's aligned on kind of understanding what that deliverable is.
Kirsten:
When you look at existing BIM practices and industry standards and guidelines in Canada, how does ISO-19650 align with those?
Krigh:
I think what we're starting to see is that more people are realizing that it does align with what they want. I think that we haven't really had proper BIM standards in Canada. We're starting to see it show up more on sort of federal government projects, a lot more is kind of awareness. I think a lot of it is that people are starting to really understand, okay, what that framework is for and how it helps them on projects. I think that up until now, a lot of groups have sort of said, oh, like even in the conversations we've had about 19650, it's an international standard and people will look at it and say, oh, well, it's an international standard. How do we make it Canadian then? Yes, there's been groups that have developed Canadian annexes of it, like little sort of pieces that you tack on to make it more Canadian, but at the same time, like when, you know, going back to that original idea of what the philosophy of it is about, if you understand that sort of framework, it's really like defining your objectives of what you want delivered on a project and those are driven by business objectives. That's really something that is international. It is something that all of the projects I've worked on in Canada have had that sort of same desire to do that upfront.
So from that standpoint, I think that we're seeing more adoption of it within Canada, but at the same time, everyone kind of is a little bit hesitant in that I think unlike places like Europe and the UK that I've worked, we're a little bit more hesitant to embrace standards. But at the same time, I think a lot more people are sort of pushing away that barrier and kind of actually looking at what we really want to accomplish in the end, which is we want success on our projects.
Kirsten:
You mentioned government and that leads into something else I wanted to ask you about, and that is whether the ISO 19650 standards are currently being mandated by governments, whether those are provincial or federal, and the role that governments play in promoting the use of the standard.
Krigh:
I think that it's definitely important. I think that in the sense of when I was in the UK and the government mandated on all their large projects, it actually wasn't so much the government projects that it impacted, but the private sector because it really rose this awareness within the private sector that we started seeing all of our private clients going, well, hold on a second. If the government's mandating this, why is that? And they started looking at the standard going, hey, this actually makes sense. And so they started embracing the same terminology. They started embracing the same language.
And going back to my comment, I think where everyone wants to make it their own, I think there's a balance to be struck in that, yes, you can understand the philosophy, but I also don't think people should be reinventing the wheel. So do I think that the government should be mandating it? I think it would help if they did it on their projects because I think that it would sort of solidify and sort of saying to Canadians, yes, this is a standard that we believe can make your projects better and can lead to better success. I think that if they did that, it would, you know, help the rest of the industry embrace it. And I think that that would follow suit then for, you know, how that cascades down to more of the municipalities. I worked with BIM for local governments, for example, in the UK, which was a group that then took the national standards and applied it at more of the local level. And that happened because of that government mandate.
Kirsten:
You were just talking about BIM. How does BIM technology support ISO-19650 in Canada?
Krigh:
So I should clarify that the standard, the ISO-19650 really was written around BIM. It's written around that sort of idea of, because really when you get back to it, a lot of people think of BIM as Revit and 3D models, but really BIM is information management. And so the ISO standard, 19650, was a BIM standard. But at the same time, we've actually worked on projects where a client was interested, for example, on a campus project in looking at implementing more of a digital twin, as sort of a very advanced, holistic technology solution. When they went to do this, there is no digital twin standard yet. So we were actually looking at how we used the 19650 framework, that same idea of defining your business objectives up front, which leads to what you're trying to do. In this case, they wanted to do a digital twin of their campus. And that then could be applied to what the information is that then on future projects, that campus would be asking for anyone that designed a facility for their project or built it on their facility. And so we used the 19650 standard through, as that framework to be able to help them deliver it in the end. So the standard is focused on BIM, but we've seen it being able to leverage it for much more.
Kirsten:
Going back to what you were talking about in terms of people wanting to customize or add sections to the standard to make it more Canadian, are you seeing, or do you know whether there are regional differences between how provinces adopt the standard?
Krigh:
There's definitely differences in how they've adopted it or their rate of adoption. I think a lot of them will try to sort of go in there and change the acronyms a little bit and the terms that they use. But ultimately what we've seen in the end, in the most successful projects, the larger sort of groups within different regions that have adopted it, a lot of it is that they have jumped into it and sort of embrace that philosophy of that. When you boil it down, whether they're giving it a new fancy acronym for their information requirements, as long as everyone kind of can look at it and go, okay, this is the information they're asking for. But behind that we can see, you know, this is their strategy of what the information is going into, like what type of system or why they're, you know, asking for this as part of the design process. And then the business drivers business drivers behind that. If we understand those steps it's effectively the same thing. So from that standpoint we have seen different people use it in different ways and different rates of adoption but effectively a lot of it is heading down the same road of trying to get to the same deliverable in the end.
Kirsten:
What's your take on the impact that the standard's having on improving collaboration between all the different stakeholders - the architects, engineers, contractors and the project owners themselves. Is it starting to have an impact?
Krigh:
I would say yes. From my perspective of I think that us having those conversations up front with different groups and understanding it even if we work on a project for example within HHA that isn't necessarily an ISO certified project or that the clients properly define their information requirements, we within our processes will try to bring that same idea to what we want to as an organization want to achieve on a project.
So if we want to deliver higher quality projects, if we want to make ensure that the information that we need to coordinate our designs is there, we'll define those up front and be able to coordinate that with other consultants. So we still take elements of the standard and apply it on our projects and we've seen more of those conversations between us and other organizations of trying to get to that sort of unified approach and I think that in the end as that grows and as we get more people on I think we'll definitely have it sort of a growing awareness of it and it will lead to better outcomes. But for now it may be a bit more in sort of the conversational aspect of understanding it and I've seen this on projects where it's like as you coordinate if you both understand oh we're defining an information requirement then we both you know can speak that same language and ensure that we're aligned.
Kirsten:
Let me ask you to look in your crystal ball now and tell me what do you see as the future of ISO 19650 in Canada and do you think there's going to be changes to the standard that's going to affect what we do here in Canada, or is it kind of a, you know, ‘this is how we're going to go forward’?
Krigh:
I think as we have more conversations I think a lot of it is people understanding okay what is it really ultimately trying to get to and as I've sort of said even as we get into more advanced things I think we're sort of at this odd point in our industry where yes BIM has been around for quite a while but we're still sort of finding the inconsistency on projects and or inconsistency on deliverables and you know that doesn't lead to the best deliverables in the end you know so from that standpoint I think that it does still have a future in what we're doing. I believe that you know I still in all my time I've ever since getting on board with BIM Level 2 is I even if I push it aside when we get into conversations about it and everyone says oh you know how do we define this project and it's all done in level of detail and this term LODs and or are we delivering big spreadsheets of information and it's kind of like well by having this framework in place you have that up front so I think that as we move forward I think it's definitely got a place but as I sort of said I don't necessarily always I'm a big advocate of it but at the same time I don't necessarily try to tell people oh you must get ISO certified is really take a step back and sort of say okay how do you how do you sort of understand it at that sort of what you're trying to do in the end.
Kirsten:
We've covered a lot of ground here Krigh so let me just perhaps close on a question of, in your new role, how can we help clients understand the ISO 19650 standard or help them on the journey to exploring it?
Krigh:
I think that it really as I've kind of alluded to it starts with a conversation. I am already starting to talk with some of our clients on this side of things and if there's anybody that is interested in kind of understanding it I think it is a great place to start because I think that as I've said it doesn't have to be a big onerous task of kind of taking on a big certification or anything like that but really to start with those conversations of because we used to get in I've had this happen where I sit down it's like okay what would you like to get out of your BIM process and it's what can I get out of my BIM process and you know it's a digital frontier is a new thing to some people and I think from that standpoint it can seem daunting because you get into the situation where it's like well okay well then we'll ask for everything and it's like well no that'll add cost to the project because you're getting you know a digital deliverable is still a deliverable so you ask for too much and you're starting to increase the workload of the teams that are working for you.
So I think it's really more of a building case to sort of start the conversation understand where it is start to build that in-house knowledge within your organization but really we want to have conversations with our clients to help them along their journey to sort of say you know where do they want to start what's that first step and where do they ultimately want to get to in the end because I think if you really get back to it and start to understand that and start to understand the path forward then it you can start by taking a step back and it doesn't have to be when there's a project on the table is that as I said a lot of the better successes we've seen is you know for a group you know that knows that they've got projects coming up start now because really a lot of this stuff can be worked out well before the actual you know design of a facility is started.
Kirsten:
Thank you Krigh. Our guest today has been Krigh Bachman, design technology leader at HH Angus and Associates. To our listeners if you're interested in contacting Krigh about any aspect of ISO 19650 you can reach out to us anytime through our contact page at hhangus.com again that's hhangus.com. I'm Kirsten Nielsen.
Thank you for joining us today on Expanding the Possible. We look forward to connecting with you again on our next podcast. Have a great day.