Description
Key Learnings
- Learn about implementing a standardized project management framework.
- Learn about using Autodesk Construction Cloud for improved project visualization and planning.
- Learn about overcoming challenges and driving adoption across the organization.
Speakers
- JBJohannes BjarnasonJóhannes Bjarni Bjarnason is a Civil Engineer and Department Manager for the Design & Construction department. With over two decades of experience in the construction industry, Jóhannes Bjarni has become known for his expertise in Building Information Modeling (BIM), having worked on large scale BIM projects for major clients in Norway and Iceland. He started working in the construction industry at the age of 15, gaining experience in carpentry and construction management. Jóhannes Bjarni earned his MSc from Denmark's Technical University in 2012 before starting his career as a BIM specialist in Norway's oil and industry sector. In 2015, he relocated to Iceland to take on the role of BIM Manager at Isavia, where he led the implementation of BIM processes and technical tools. Today, Jóhannes Bjarni is responsible for managing the Delivery team, overseeing all construction projects from design to completion and delivery to operations.
JOHANNES BJARNI BJARNASON: Yes. Good day. My name is Johannes Bjarni Bjarnason. I hold the position as a construction department manager at the KEF Airport in Iceland. I want to show you-- go through a little bit with you how we've been kind of transforming the construction management in our area and at KEF Airport and go a little bit through our journey with ACC and how that has been a great support in getting us where we are today.
So I just want to start quickly off with a safe harbor statement. So it's not generally about around the whole presentation. It's more when we get to the final stages of the presentation where I'm going into a little bit more of a deep dive-- what we want to do for the future and a lot of development things that are happening there, which is really fresh for us, and I just want to make sure that we get the-- clear out there that we are in development in some of these areas. And what works for us doesn't really necessarily work for everyone else.
I want to take you through a little bit of presentation of KEF Airport and who we are and go through the backstory and the start of our journey. And also want to be really honest here today and talk about the constant developments of tools and processes and the challenges that we are facing and where we are kind of-- where our pain points are in general.
And I want to then move on to the Autodesk Construction Cloud, which is the newest platform. We started moving over to ACC in this year. And then I'd like to go into a deep dive into a little bit how we want to be-- how we're going to be decoupling the data from the 3D models and centralizing the data for the whole organization through a case study of contract and progress and cost management that we've been doing for the past months.
So starting with KEF Airport-- a little bit about us. So we're an international airport in Iceland. We have about 8.5 million passengers every year, 190,000 flights passing through our oceanic control area. Average number of 1,400 to 1,500 workers who hold the position here at KEF Airport and 28 airlines with 95 destinations to and from KEF Airport.
We are in a public limited company, or like we're owned by the state. And we handle the operation, maintenance, and development of the Keflavík Airport. That has a lot of requirements to it that we need to tender out commercial areas regularly. Our contracts can only be so and so long, meaning that we are constantly changing, constantly evolving. There are constant projects going on, and the complexity and keeping everything up to date with all the changes that are going on within the terminal can sometimes be really challenging.
Our strategy or vision is to connect the world through Iceland. We want to be a big actor in supporting the airlines to grow and work for the community around us. We want the airport community, customers, and employees all to be more connected. And they're kind of part of our strategic circle. And we want to do so with smart solutions, which is a quite high on our list of aims where we want to do much, much better.
Sustainability is as well in the center of everything we do or surrounds our policies. And we aim for excellence in all of our delivery projects, and we also use a lot of the functions and processes that we are putting in place is based on doing better within sustainability for the company.
So we have 76 destinations to Europe and 18 destinations to North America. And 70% of our travelers are connecting through the airport. 30% are to and from passengers that are visiting Iceland. And these amount of-- these passengers greatly affect our economy in Iceland. So we are highly dependent on travelers as well as the sea industry or fishing, as we were brought up from. But now the tourism is our new like we had when we were fishermen, back in the days.
The passenger development was quite extensive in 2015 to 2018, where we were almost up to 10 million passengers. But then hit COVID, and we are now in 2024 almost back to where we were in 2017. So we're looking into sometime 2025, '26, to have reached the passenger numbers again that we had before COVID. So we've kind of made a quite good return on our passengers flow.
Our forecast for '24 is about-- what was it-- sorry. For '24 is about 8.5 million. Now, our challenge is not necessarily the amount of passengers throughout the year, but everybody wants to come during the summer. So an airport of the size of 80,000 square meters can only handle so many passengers in a month. So June, July, August are kind of quite tricky and challenging months for us while doing the ongoing projects and everything that we are doing in the expansion of the airport.
Now, ahead of us is the biggest development period in the history of KEF Airport. So the airport two years ago was about 75,000 square meters. And currently on the way is the East Wing project, which will end now in '24. We started opening it in stages in '23. Then it will take the airport up to 103,000 square meters. So this is an expansion over 20,000 square meters.
This project is the project that has paved the way for our data strategies and processes and has paved over all that development. So there was a pretty critical decision made some years ago on the road we're going into, and will go a little bit deeper into that in a few slides.
So the North Terminal was constructed in 1987, as well as a corridor-- the South Terminal in 2001. We have the expansion to the North Terminal in 2004 to 2007. We have expansion in 2007 again for the North Terminal. We have 2015 expansion of the North Terminal. We have 2015 expansion of the South Terminal, 2016 expansion to the west of the North Terminal again.
We have 2017 expansion of the South Terminal, and this project right there is the first project that had any BIM requirements set on it. So as you can see, since the terminal was built, or since 2001, we have had constant projects going on, and we're not slowing down.
When we started-- when the terminal was built initially, there was this construction manager running this project. And find this really fascinating that all the way back in 1987, there's an article by him. It's in Icelandic, but it says, if I translate it directly, that computing is the solution. So already back then, people or staff were starting to look at computing as a way forward. At that time, the internet had not made its way to Iceland. So the internet was in 1995 when that was widely available in Iceland at that time.
So our next project is to be finalizing now in '24. We have an SLN21 project of 25,000 square meters estimated in being constructed in 2026 to 2029. it's in the middle of a design period now. Stand 10-- 1,900 square meters opens in 2025. And we have East Piear, 70 to 90,000 square meters, estimated start of design and construction in the period of '26 to '32. So this will more than double the size of the airport in terms of square meters.
So the backstory-- now let's go into the fun stuff. So looking a little bit back on this previous slide here is that we have a lot of square meters coming in-- great expansions. And you can't possibly manage this and the data and the maintenance and everything that you need to do to operate an airport like this with not having a robust strategy and know what you have in your hands.
So when I started working for [INAUDIBLE] or KEF Airport back in 2015, we had a lot of outdated data. So what I like to say is, let's not dwell too much on the past. Let the past be the past, but let the past be known. So we had a lot of outdated data. We had drawings, layouts of a floor of the building, for instance, which had 10 different drawings to it. All of them were correct, but all of them were also wrong. So none of them had the full level correct. They had parts of it correct.
And this was in a 75,000 square meter building, and these were a lot of drawings-- a lot of information and data that was outdated and misaligned. Changes during operation since the airport was constructed initially had not been incorporated into legacy information, as well as delivery projects.
So there was no robust plan to keep everything updated. It was run project by project and delivered as a project-by-project basis-- a lot of misalignment across drawings and models, and we just really quickly found out that wrong data is way worse than no data.
So we decided in 2015 to invest in a smarter future, and the future is close. Already in 2015, when we started investigating, How are we going to get our terminals and our buildings up to date and up to standard in terms of just drawings and models? we decided to go for a 3D scanning and reality capture. We started working on our data strategies for the overall company and started developing our standards and requirements to put out to the designers and just strive for digitalization.
We were not looking at any too complicated solutions. We were just striving to get the absolute minimum requirements of data correct so we could start to build a foundation where we would then build the future of our data strategy on top of.
Now, we just went right ahead in early 2016, started doing a 3D scanning. I'm just going to go a little bit quickly through these because the meat and the bones comes a little bit later. So from 3D scanning, we had a full point cloud of the whole terminal buildings. We had to get some surveyors in. They needed to survey the whole area.
We had to-- from that, we then got kind of a pretty precise 3D model that was modeled in Revit at the time. And we got that up to a standard where we could start to use that as a legacy and a reference model for our future expansions and changes in the terminal. So this was a project that took about a year or so for all of the 80,000 square-- or 75,000 square meters.
Now, a low-hanging fruit from that was also using those scans to update [INAUDIBLE]. And we also started to use it in live construction to identify collisions before they happened on the site. So a lot of good benefits from this process. And what we used for this was mainly ReCap and Navisworks to pull things together.
And when we did these kind of visualizations where you had 360 photo geometry with the models in them, back in 2016, that was kind of a big seller for all the actors. This was something that got people on board, and they thought it was really exciting and had never seen this kind of quality before, at least not in our market where we were operating from.
Local coordinate system is something that we had to create at the time to start to pull everything together. It's both civil and terminals. Because of our geographical location, our local coordinate system is highly important. We do have or had a lot of challenges with coordinating terminal project with Civil 3D project, for instance, because Revit doesn't handle curvature really well, while Civil 3D is much better on that.
And we had to update the system, the local coordinate system, regularly and verify it regularly. And there is a good reason for that. I don't know if all of you watching know, but there's a lot of volcanic activity right next to Keflavík Airport.
This is just a minor challenge of top of everything else. And the reason I call this a minor challenge is that this is-- yes, this is close to us. The photo you can see on the right is actually taken from our offices at Keflavík Airport. You can see airplanes there in the foreground if you look closely-- airplanes. Sorry. So this is 15 kilometers away.
Now, there is no danger to Keflavík Airport. The safety is all good. You can land. You can go-- even though there's volcanic activity going on, you can still come and go as you please. There might be some delays, depending on weather conditions, but in general, the volcanic activity itself does not affect the airport in an operational way.
But what it does-- the earthquakes and all that's happening around us-- is that it is shifting us. So already in the past year, I think we're pretty-- we're a little bit above 1 meter where the whole area has shifted to the Northeast. And that is an issue for surveyors and coordinate systems. Luckily, it has all shifted equally, so it doesn't create a discrepancy between the points. But it kind of shifts us from the origin point of the system.
Another challenge that we are dealing with is the constant development of tools and processes. We started with Glue and Field and then to BIM 360. And I wanted to go a little bit into this because this is one of the big reasons for our current approach, which we'll go into in a couple of slides.
So here what we did was we started with Glue and Field. We did set up all of our processes. The connectivity wasn't really good at the time. It was in 2015. The connectivity between Glue and Field was not the best. The connectivity between Glue, Field, and SharePoint was not the best. We had to do a lot of homemade solutions and programming and optimization to get the connectivity with the organization set up.
So we want to make sure that when a designer updates a drawing, we want to make sure that drawing finds its way into the field on the same day as soon it's been approved. So we did that by programming and creating our own programs to move data around between SharePoint Glue, SharePoint Fields, and vice versa. We created email functionality where I could email into SharePoint and that would push that information into Field as a comment to an issue or as a comment to a drawing or a reviewing process.
So at that time, the project, because of this lack of connectivity, we did not fully move the delivery team or our projects over to Glue and Field. We used Glue and Field as tools, but all the information lived within SharePoint. So the SharePoint was the backbone, while Glue and Field was where the tools that we were connecting to SharePoint.
We did a lot of process maps and identifying which data should be stored where, and this took a lot of work and was a huge investment. But all this was driven by the delivery team, and all we were doing still at that time is always just the delivery team pushing, operation pushing the software to the limit and trying to do more and better. We did not have an organizational strategy at that time, and that was strongly needed, and one of our biggest mistakes, probably, when I look back.
Then Autodesk, as good as they are-- and they are fantastic-- but they came with a new solution, BIM 360. Or not a solution, not a new solution, but a new platform, BIM 360 Next Gen. A lot of the issues that we had in BIM 360 Field and Glue were resolved. finally, we could publish drawings from the model. We could do a lot of-- all of the review process were done in BIM 360, and the connectivity was so much better and the benefits for delivery were amazing when we took this step.
But we took this step just as a-- we just decided one day that we're moving to BIM 360. Everything moved over to BIM 360, and there was a lot of functionality that were still better in better in Field than there was in BIM 360 at the time. We had made a lot of homemade processes that were much better than what BIM 360 had to offer at the time.
So this was a huge learning curve there-- is do your investigation, do your homework before you jump over to the next platform. And this is basically what one of our mistakes at this time. BIM 360 solution is a fantastic tool, fantastic solution, and it became a much better platform when we had to use it for two years and we had gotten all the updates from Autodesk. But at the time, we were such early adapters that we had a lot of challenges with it.
But because of how BIM 360 functioned well and worked well for the delivery team, the need to push the information to SharePoint and to the rest of the organization wasn't there anymore. We got what we needed as a part of the delivery team, and we didn't have the need to create all this connectivity as we did previously.
So the result in that was that the information got siloed. So we had been BIM 360 information, and we had SharePoint information, no connectivity there in between. It worked for us, but did not necessarily work for the organization. And our vision, which was created back in 2015, which was decoupling data and making this huge data strategy across the organization.
So still there-- no organizational strategy done, and we really desperately needed one. But still, we are driving this as a delivery team, and we are gaining a lot of benefits. It was a fantastic tool.
Now, I want to go a little bit then into Construction Cloud now and how we're using ACC. So early '24, this year, we implemented the newest version of the platform. Since we hadn't done as much of our homemade programming as we did early in 2015-- we hadn't done so much our own adaptation of BIM 360-- we decided that we could do the same mistake again and it wouldn't hurt us too much.
So we decided to go ahead and just move over to ACC over the weekend, basically, and just start to use it. So what we did is every new project starts in ACC, and we are pulling all the legacy data from previous projects into ACC as well.
And we are using basically the whole suite. So we are using Docs, Build, Design, Model Collaboration, and a lot of the functionality in there. I'll run through a couple of our favorites and the ones that we are really glad about. And just to mention, the ACC part here is my co-speaker's slides, so I sadly-- he will be with me live in San Diego, but I will try to do my best.
Now, we are able to specify more than one naming standard in the ACC platform, which we did not do in BIM 360. That's a huge platform. We've always had kind of a big need for that. And that has been really beneficial for us.
We generate workflows for everything we do within ACC. It's design review, submittals, and all the processes that we have going on. And that for us works really well and especially for when we're doing the documented data management reviews.
Now, Bridge is a fantastic functionality that is kind of opening up a new world for us. We are now bridging project across models across all of the projects. We are creating projects where we are bringing everything into and creating a project with operations, giving operations more accessibility to the data-- being able to comment, being able to play with the models without mixing up all of their comments and discussions into the live project. So a lot of functionality that we are gaining from the Bridge function.
We are using forms quite a lot, and those we all-- have those all put into our project templates as well. So as soon as we start a new project, all of our forms are ready and ready to go for the QA/QC team for safety inspections or any inspections that needs to be done on the project. So this is a really powerful update from previous platform.
Submittals-- we use-- a fantastic thing about submittals is now all of the communication regarding submittals and approvals goes all through ACC. We are also putting our specifications up there and linking those with the submittals. So this is greatly limiting the time where we need to search or look for the specifications that applies for a submittal or vice versa.
The correspondence is as well within the Build environment, which we are highly dependent on now. We are greatly limiting the emails. The communications that are outside of ACC has been minimized drastically. Most if not all of the decisions taken are taken out within the ACC environment when it's with the designer or the contractors. And so a full transparency, full traceability is something that we're seeing, and we're really, really happy with.
Now I want to go a little bit into the future. So we are looking now into incorporating cost management in Takeoff. We have done some testing. We have done some pilots. It's not necessarily there where we need it to be. So we did start one year ago with our own development, which I have high hopes for. And that's what I want to show you a little bit and what I want to-- yeah, let's start with this.
So we have successfully moved to ACC for delivery projects, and now we want to go in working on the connectivity of crucial data across organization. So that's when I get into the contract progress and cost management part of the presentation.
So like I said, we did look at cost management. We did look at Takeoff. It's not where we need it to be at this point. So I want to go a little bit into how we're doing it, how I see for me that we will be doing it for the next years to come, and how decoupling the data and taking ownership of the data outside of any named platform I believe is our way to move forward until we have a solution or something that can do that for us.
So like I told you earlier in the presentation, when we were back in the BIM 360 environment, we had BIM 360-- that's where we had our drawings, models, coordination, design collaboration and all project-related documents stored. We did not have specifications, contracts, or cost management in BIM 360. That was all in SharePoint. So in SharePoint, we had our specifications, cost management, daily reports, contract claim management, and such.
So you could say that the project manager, he was working in SharePoint, but the designer and PM-- designer and DM, they were working in BIM 360. And there was no connectivity there in between. There probably where-- there are solutions and were tools to help with the connectivity, but that was something that we did not need at the time, and so we never went into that.
And then the organization finance operation are on multiple platforms. This is where our invoice management is-- asset management, operational needs, requirements, legacy information-- the knowledge base of the company. This is something that we also want to connect to.
So we became siloed in terms of data connectivity when working with BIM 360. It's not BIM 360's fault. Of course not. But we had a tool that worked, so we were happy with it. We had SharePoint that worked. We were happy with it. We kind of maybe fell asleep on the guard.
But now looking at ACC and looking to the future and re-looking at our vision back in 2015, we have a new approach. So I want to go through this with you a little bit. So we have our models in Autodesk Construction Cloud. That's where we store our Revit models and specifications.
So from our BOQs, or from our Revit models, we get our BOQs, and then we have our specifications as well. And these codes or the chapters within the specifications and the item in the BOQ are synchronized so they have the same code. So we can easily connect the BOQ together with the specifications.
That gives us a BOQ with specifications and with all the quantities which we then send out to tender, and when we get the offer back from the contractor and we choose the contractor we're going to work with, we go into contract, and then we create the cost estimation or a server or the document where the tender contract is stored.
And it's important this may never change. This is the baseline for that contract. This is also then will be functioning as a progress report tool going forward in the construction. We are looking into then storing this just on ACC and having the contract tool is logging on ACC. But the functionality of this is not optimal right now, so we're not there yet. But now this is on SharePoint, and they're filling in their monthly report on SharePoint.
But this is then stored on a SQL Server, and each contract that you have here will have its own SQL Server. So for this project we are doing the tests in, we have 27 contracts, so 27 SQL servers which have the monthly report document which they are filling in every month.
So after you've assigned the contract, you have made the agreement. You will then still, of course, have design changes. So it will happen that the designer is doing design and he synchronizes and he publishes his model in ACC. Now, what we can do is we can now pull on the data. We could pull on the schedules or the quantities from the Revit model into an SQL Server, and we can compare that to the initial tender, and we can flag any changes going on through Power BI reporting.
This is automating or helping us automate the monitoring of changes within the model. Of course, to be fully transparent, not all of the items in the BOQ are modeled. We are still in the environment or in scenario that some items are not within the model, and that's something we are working on constantly together with the designers.
So then there's a whole design change process that needs to start. So when we see a discrepancy between the model and the contract that is already being managed out in the field, then a big design change process starts. And this is something that we have in house, and we do that through using ACC and the tools that we have.
But for sake of cost management and contoured management, then we have all of these SQL servers. Now, we pull them into Microsoft Fabric. This is kind of a bleeding edge, or I am told that is kind of a bleeding edge technology there. We are kind of really early adopters of this, so we have had a lot of challenges, but we overcome most of them. But within Fabric we can then do Power BI reports and pull out reports like these.
So this is showing the cost or the cash flow initially. It's showing the progress reporting, and it's showing the estimated three months look ahead. It's showing us on a monthly basis down here. You can view this as you like. You can go and you can filter on a specific chapter of the contract and see how that's going and so on.
But another strong suit is that we've also linked this to Power BI with the models. So we have linked Power BI to ACC, pulled the models down, and we're working on synchronizing or being able to select the information in Power BI from the progress reporting to viewing it in the model visually. And that is where we are today. We've done the proof of concept of it. We've made it work, but we haven't automated it yet. And we're almost getting there
Now, next step is when the company [INAUDIBLE] KEF Airport goes into Microsoft Dynamics 365. Then the connectivity really opens up to the organization with connecting all that cost information and the contract management part of it into the financial system and operation.
So we can start to pull down the invoice management and invoice monitoring into our report and into our environment or deliver our information into the finance system, automating the overall presentation or reporting of the project. So this is getting us pretty close to automating the earned value report every month, or even every week if we would like to have a weekly updates.
Now, what we have then in general is we have-- to put it simply, we have an overall project cost-- automation of the cost. It's not fully automated, of course. You always have to have the control to go in, and he needs to identify his quantities or his progress during the month. From there, it's then automated.
But what we are working on as well is using the QR codes and the codes and trying to simplify the logging of his work. But already now, the feedback we're getting from the contractor is that he's saving about 60% of his time doing his progress reporting.
We can select the parts of the contract and see how they stack up in terms of what our estimate was or how the schedule was in the beginning. We can see if they're moving further away from the schedule or closer to it. And we want to be able to filter the view in Power BI to reflect what we have in the Power BI report. And this is something that is being worked on. And hopefully, when I'm at San Diego in two weeks, I will be able to show that straight from the Power BI report.
So what we've done-- we've gone from manual updates of our cost estimation with multiple Excel documentation to weeks just creating that report, as you're looking at there, to an automated or like an almost automated process and live data in delivery by using ACC and Microsoft Fabric and, of course, a little bit of Excel as well.
Our next step is to get into the connectivity across organization and pooling of financial data and pulling a whole organization together. We are starting to develop the strategy for that, and the work has been initiated. And we're hoping to start a pilot and proof of concept in early '25, hopefully February.
So this is what I had to show you. Hopefully this was of interest and not sped through quickly through. My name is Johannes Bjarni from Keflavík airport again. Thank you.