ISO Believe 19650 Can Improve Project Delivery

DAVID SEWELL: So firstly, welcome to ISO Believe 19650 Can Improve Project Delivery. And just in case anyone isn't sure, we'll be talking today about the ISO19650 standard for information management. My name is David Sewell. I work at Perkins&Will in the London office. And this slide is a little bit about me.

I'm part of the Global Digital Practice team, who specialize in using technology and digital tools to provide efficiency, richer content, and develop new capabilities that advance our projects. So I've been working to standards similar to those laid out in the ISO19650 since 2016. And as Perkins&Will London, we are mainly leading the process defined in the ISO standard, which includes assisting our clients.

And what Zuzanna and I decided to submit here today, we're both aligned in our thinking that often there's a disconnect between those BIM people and the delivery team. We're aligned in our hope that we can explain this new-ish standard to you guys in simpler terms. And we're also aligned sometimes with our frustrations that when we sit-in BIM meetings, there's no real useful project outcomes.

ZUZANNA CZAPLA: Hello, everyone. Just to give you a little bit of context, we normally work as a appointed party. In '21, our Danish office got the first ISO project. And personally, it felt a little bit overwhelming and stressful in the beginning. Fortunately, we are the part of the bigger organization, so I was provided with the mentorship and practical experience.

But I know not everybody has this opportunity. So we are here today to share our ISO insights. And we aim to help others navigate this journey more confidently.

DAVID SEWELL: So just before we start, I think we want to make it clear that this deck is our combined experience working on projects that reference the ISO standard. This is not the theoretical process, this is actual, real-life, honest project experience both good and bad. Now, we're aware that our projects do not align perfectly with the standard, but we're working more and more towards this as we gain experience with our project partners.

We do hope that what you see today takes away some of the confusion and hopefully, shows you what you might want to look for whatever your project role is. Now bear in mind, this is a less than glamorous topic, so we've consciously tried to keep it a little bit lighthearted in places and not get into the weeds too much.

So these are today's topics. We will discuss the fundamentals of the ISO standard, the theory versus the reality, roles and responsibilities are really important part, getting started, how you of get up and running, and then we'll talk a little bit at the end about ISO19650 accreditation, how you might go about that.

So first of all, the fundamentals. I think historically, everyone works to a standard. But it's often just their own standard. Now, we all know that large projects can run over budget, meaning horrific delays and costs. And there are many reasons for this, but poor information management can be a factor as projects produce massive amounts of data from many different sources in all sorts of formats.

And it's all shared in many different ways. And really this means unreliable project data and information. But with the need for better information management comes the need for standards to help us streamline. And we think this is where ISO19650 comes in.

So just a warning, we've tried hard not to do this, but here's one of them. The ISO19650 standard is a framework to outline the recommended process for managing information about buildings and assets through the asset lifecycle.

As the industry moves to more ways of digital working, teams need to collaborate in an open and structured manner to control the digital flow of information. The ISO19650 standard offers this approach, aiming to provide the right information to the right person at the right time to make the right decision. So a single way of working for all project stages to enable the delivery of handover information in a common format for use in other business applications and platforms.

So where does 19650 come from? So a brief history. And we can play BIM Bingo with this for the old school BIMers in the room. There's a clue on one of these images that links to the foundations of the ISO19650 standard. It's that one. PAS1192, home to the wedge diagram, this wonderful wedge.

So the ISO was developed from UK's now superseded PAS1192 standard, the tried and tested information standard established way back in 2007. And then from that, BIM level two was mandated by the UK government for all publicly procured projects I think around-- in 2016. ISO, then sought to adapt and elevate this standard to an international level, and that's where we are today.

So we mentioned government projects. Who cares? We don't do government projects. Right, back in the day, that was a kind of fair question, certainly for my office. But private clients started to jump on board.

And they also started requesting BIM Level 2. Even though they didn't really know what it was, they thought that this sounds like a good idea. Let's have some of that. But now that the ISO is recognized internationally, we're seeing it referenced in pretty much all significant RFPs in the UK today.

So another far from pretty slide, but sometimes, it just is what it is. Here they are, all five, soon to be six parts of the standard in all their glory. We're going to concentrate on part one, which is the concepts, and then part two, which is delivery phase of the assets.

But the other ones are there for your reference. Next slide, please. Let's get off of this one.

OK, a few more hard-to-read boxes, but this slide is super useful. Now, this is guidance to understand the fundamental principles of information management. The guidance is structured as indicated by the diagram tiers. And each has a clickable link giving some incredible information, including worked examples, templates, and real-world scenarios.

So you've got links there. You can scan the code. Go and give that a look.

So it all sounds great, doesn't it? We have a standard framework even beautifully worked up examples of how to implement. So why don't we all just crack on? Well, often, this is what actually happens.

To deliver quality project information, we really need to ensure that all five of these steps are addressed. Typically, designers and constructors deliver the minimum. This is because the requirement steps 1 and 2 are not clear. And they need to provide a competitive tender as a response to win the project. And then nobody with the required detail knowledge is really checking the information being delivered, step 5, here.

They're not checking it for quality, consistency, and reusability. So often, unfortunately, the reality doesn't really match the expectation. And clients are left underwhelmed at handover in relation to the BIM promise world.

So why are there these gaps? For anyone that's been to London, it's curved platforms. Excuse the wordy slide here, but these gaps come because generally a RFP stage, and even when we've started designing, things aren't clear. So one sentence of we want ISO19650 is meaningless. To understand the client deliverables, we need to find BIM requirements.

For most clients, it's difficult to provide. And here are some real-world examples. And me and Zuza have laughed about some of these. I think her favorite is the pink one. Whereas, mine's the blue one. It feels like it references so many BIM buzzwords and terms-- 3D, 6D, LOD 500, COBie, Revit it's like-- if we ask all this stuff in one very small paragraph, we're going to get something excellent at the end that we can reuse in operation. It doesn't work like that.

So the ISO standard has identified specific responsibilities and assign them to roles. Now in the screenshot here, I've picked out the activities that the client responsibilities-- the client must provide. So the very first activity in that red box shows a client activity needing to have the information management function fulfilled.

So instead of asking for something like this as a requirement, the ISO is asking our clients to provide this at RFP stage as part of their tender suite of documents. It's such a big contrast, a very small paragraph of crazy words to this very organized requirements. But we've not worked on one project where we've received this actual level of detail requirements.

So OIRs, Organization Requirements, we've never received. PIR, Project Information Requirements, these are quite rare. Asset Information Requirements, the AIR, these start getting talked about typically when the project is underway. And EIRs, we sometimes get these. And when we do, it's kind of nice because we know what we're up against and know what we need to respond to.

And this contrast makes it really difficult when we're tendering, because we obviously don't want to include added fees that might not be recognized. So we include a couple of options in the RFP returns. We typically deliver-- we typically price or deliver for anything that's part of our typical designer fee, so 3D geometry, model coordination, classification objects. That's just part of simple what we deliver.

But then we offer a number of options. And we offer to talk through these should we be successful. And one of these includes offering the services of information management.

So just skipping back to that blue arrow diagram, an information manager can assist with those missing steps 1, 2, and 5, sort of highlighted in the diagram below. An information manager is needed client side to understand and define the requirements. And an information manager is also needed delivery side to oversee that good information is delivered. Then we need somebody at the end to check that it's all been delivered correctly.

But this is a new function in an emerging standard tasked with checking things like digital workflows that can't be physically seen. And because of this, there's little appetite from design and construction teams when we're asked to provide information again properly. I've delivered it. We're not doing it again. We aren't because you haven't done it properly.

One project, we know of, it's already been in use for nine months. The people in the building working, but the supply chain still haven't delivered accurate data as defined in the requirements. So those delivering digital requirements need to be accountable if they fail to do so. And the information managers monitoring all of this need the authority to challenge those that don't.

And if you think about, right? If you bought a piece of furniture that had a missing leg, you'd return it, right? But when we have missing digital information, it's often overlooked because nobody can see it. So when you fill the information management functions as required, you're able to address all five of the required steps. And this works even better when the client information management role stays constant throughout the project.

ZUZANNA CZAPLA: Thanks, Dave. Just before we deep dive into how to handle the ISO project, we need to understand the organizations and roles that are defined by it. So appointing, appointed, and appointed.

And you see this word three times. And it gets a little bit confusing. And in my opinion, only British people could come up with this. Anyway, we have those three organizations defined.

So we have appointing party. This is usually the client. Then we have a lead appointed party, which is a company that is responsible for managing the information and the deliveries. And then in the end, we have the appointed party, which are other consultants, design teams, and entities that are involved in the project that are responsible to provide the deliverables to before-mentioned parties.

Now, the reason why I introduced this organization is because sometimes you might receive a preappointment execution plan that will have the organization chart like this one, which is not exactly as clear as what the standard describes. So to decode the diagrams like this, I normally ask myself questions. What if my review doesn't go through, do I know who should I call? If I can answer those questions, then that's perfect. Otherwise, I probably need to call someone from the appointed party and have a meeting with them just to understand who is who on that project.

So who in this organization we should have on board to ensure that the project like this runs smoothly? Now, you can see a few overlaps over here, but it's because each party should have a dedicated person who is responsible for the overall process from a different organization's perspective. We have this guy, that Dave already mentioned, the information manager. They make sure that the process is best fitted for a project and that all parties know what is required from them.

Then we have a document controllers. This is a really essential person in the team. They make sure that the information is provided on time in the right place and in the right format. For the appointed parties, we don't probably need someone that is full time on this process, but we need someone that knows how to name the files and where to upload them when it's necessary.

Then we have the model coordinators. It might be a single person. It might be a few people. These guys just make sure that the models that the delivery teams develop are coordinated and are of a good quality for a certain project stage.

The project team is mainly focused on the production. And now, I will pass it on to Dave. And let's get started with some real ISO stuff.

DAVID SEWELL: Thank you, Zuza. So now, you all know you're appointed from your appointing parties, right? It's simple. Simple. So let's get into getting started with ISO and some of the things that you should think about whatever role you are being contracted to do.

So this slide, this first slide, is for all parties. Don't worry about your appointing, your appointed, your appointed. This is all parties.

I want to stress that the ISO19650 series should be applied in a way that is both proportionate and appropriate to the scale and size of your projects. So it is a standard for all built assets from office refurbs to huge infrastructure projects. Applying it in a way that is suitable and beneficial to your projects and its size, that's what you've got to think about.

Some of the elements contained in the series may be beyond the needs of your project. We've both sat in meetings challenging deliverables or contradicting requirements that we've been told that we must work to. So a couple of real-world examples here. The design team must provide COBie at design stages when there is no requirement for maintainable asset information. Why would you do that?

We've also had the client clinical team, they want to carry on sharing with email rather than use the CDE when it was the client BIM team that had written the CDE brief we must all work to. And then we also get-- we ask maybe, what elements may need to be maintained in operation? And we get told, we're not sure.

Just give us what you think. So you can do everything, but you've got to be careful, make sure does it benefit the project and meet what the client actually values. And I think the overall thing here is when we think about this stuff, is the juice worth the squeeze?

This is also a great resource for all parties-- the good old information management function assignment RACI matrix. Just rolls off the tongue, right? And this is compiled to provide clarity of responsibility of tasks outlined in the standard. So we list all of the required activities, and then we assign them to the relevant party. Now once the activity has been assigned, the relevant party must provide the appropriate resource or function for that activity.

And this is not a one size fits. Make sure your project completes one of these RACI matrices. It really helps conversation around who is doing, providing, and leading what.

So that was all parties. We're going to move on to the client, the appointing party, the client responsibilities. And these are the key ones, really-- establishing clear documented requirements, confirming delivery plans, and accepting the information data at the end.

So this often comes as a surprise to our clients. And they're financiers. They're real estaters. They're medical people.

They unsurprisingly do not have this knowledge. But the standard states that they can pass on the role of information manager to somebody else, which is often a really sensible idea. And there are many BIM consultants and information managers out there. But the key is to find one that focuses on what you need, rather than we must do this stuff, because it's in the ISO.

So client information manager heroes. Come on, you all knew this one was coming, right? The easiest ever hero graphic.

If you were a client looking to employ an external consultant, then make sure they have some of these key skills. If the project wants to reuse the information operation, then you really need your consultant to have knowledge of handover information. Perhaps a consultant attached to a design firm, they may not have any experience in handover need. So it's something you might need to question.

And also, do they talk human rather than computer language? Instead of asking, what are your LOIs? It should be, do you need to meet any energy targets? Do you have any sustainability targets?

Are there any assets that you know you're going to replace rather than maintain because of cost purposes? So talk. You need to be talked to in a human way, not in a BIM-acronym way.

So every hero becomes a villain. So there are these people also that aren't so productive. But you can read the bullet points there. But I think what's most important really is that the entire team is engaged on this journey.

So in the early days, I attended a project meeting of about 25 people. We had design teamers, clients, project managers, cost guys, and then these two BIM consultants. And then they started the meeting, and they started talking in BIM acronym for about an hour.

And nobody understood what was going on or what was being said. But nobody even called them out on it. And an awful lot of time was wasted in the end delivering something that ultimately wasn't needed.

So once the requirements are confirmed, then this really is a starting point for the delivery team to determine how they will respond. So it's worth noting that these are project specific, and they don't need to be chapter and verse. This is an example of a really big project with lots and lots of requirements. But there's no reason why smaller projects can't be captured in just a few pages.

OK, so that's the client, the appointed party. We now moving on to lead appointed party. The leader of the pack, if you like, for those older members of the audience here. So if you're responsible for the coordinating information between the delivery team, you are fulfilling the role of the lead appointed party in the context of the ISO19650 series. And you can see the bullet points, what you're responsible for here.

So first thing I'd say is begin with getting to know your delivery team, send them a supplier resource or capability assessment. Now, do this even after appointment just to know where you are. These enable us to understand the experience or any training needs that your delivery partners may need. And this really gives you a-- it really gives you a feeling of how competent the delivery team are going to be.

So we've worked with delivery partners that have needed project support in BIM software basics, even though they provided us with a list of BIM experts in their capability assessments that doesn't really tie up. And then things like this really help justify any added time allowance that is needed to support them. Someone's got to pay for it, right?

Moving on from that. So we get to know our team. It's great. We're now going to develop the BIM Execution Plan, the BEP, we all know what one of those are. But there's a kind of way we go about framing these now.

I've kind of labeled steps 1, 2, and 3 here. Now, step one is trying to say that when we write our BIM Execution Plan, we direct reference an EIR clause on it, so you can literally see one or the other. So step 1 shows 2.3 in the BEP relates to 2.3 in the EIR. We can exactly see what we're answering. And that's really what the BEP is. It's answering how we're going to deliver the requirements.

We move to step 2, the BEP is then-- it's cloud shared. This is a live document. It sits on a SharePoint environment. And we invite delivery team to comment in the live document. Now, this really encourages buy in and also provides that audit trail. So you can see a list of comments-- that might be a little bit small-- but a list of comments to and fro between the different members of the team.

And then finally, step 3 here, we then ask our partners to sign off on the BEP Suite at each milestone. We want to know you've read it. You're happy with it. And you're happy to put your name and a date next to it as well. So this is really also encouraging more engagement, but also sharing the responsibility as well.

The reason for this is kind of-- I think in the good old days, there was-- well, not good old days-- in the old days, there was a number of times where I've been asked to issue the BEP simply as a tick box exercise. Have you issued the BP? Yeah, I've done that, yeah.

OK, brilliant. And I often wondered, did anyone ever read it? And you also think if I send out a blank BEP, who would have noticed, right? So this is what we're trying to avoid.

Moving on again. So the Information Management Risk Register, a very underrated document this one. So we have Risk Register for so many other things-- health and safety, design, things that are visible if they're not complete. Now, with digital deliverables, things that are not physical outputs, it's very easy to get missed, or overlooked, or deemed not important. So if you're leading the process, then recalled any issues that may pose a project risk or a delay to the program, and then reviewing this document with your BIM partners at BIM meetings is almost a project must.

Moving on through. So the Detailed Responsibility Matrix. And these are all terms that come out of the ISO DRM, if you like. Let's call it that. This takes the BIM requirements and then specifies at a very granular level exactly who needs to deliver what and when.

So the matrix essentially defines the rules for all parties to live in geometry and data, detailing what information is required at each project stage. Now very, very quickly, the rows here, they're identifying the building elements being delivered for the project and the columns denote the required geometry and data. And the cells that go in the-- information that goes in the cells is alphanumeric. And we use a coding system to define the project stage and the responsible party. So if you zoom in and look at one of those cells, it might say 4A, which means this information is required at stage 4 by the architect.

And this is an example of our data validation. So those requirements in the DRM are validated against and marked green or red to ensure that data is present, it's missing, or it's duplicated. So again, very, very granular validation. But the image in the top right here, this is a simple dashboard that's shared with everybody on the team, so we can highlight when task is complete, or if they're incomplete, or if parties are not actually performing as they should be.

Next up is the Task Information Delivery Plan, the TIDP. This outlines the specific information requirements associated with individual party deliverables in accordance with the project timeline. So we're trying to tie them up deliverables and program.

And the highlights here, what the preferred format is. Is it PDF? Is it IFC? Is it RBT? Is it CSV? That'll be in here as well. And also, what information deliverable is expected to be provided throughout the project's timeline. And also, document control procedures, including how we version control, what our naming conventions are, and documents related to each task.

So this is a template that as lead appointed party, we would supply and share to our delivery team members. We send it out. We ask them to fill it in. And essentially, it's kind of like a drawing list if you like, but on steroids. It's not just drawings, it's information.

It's schedules. It's specifications. It's models. It's everything. We send these out.

We then ask the guys to fill them in, and then send them back to us. We receive all of these TIDPs back from all the different parties, and then we sort of review them and consolidate them into a Master Information Delivery Plan. So this is the MIDP.

Now, the purpose of the MIDP, when it's compiled, it should highlight any potential issues that may affect delivery, kind of very simple example. This would be perhaps architecture layouts not being frozen in time for the MIDP design to develop. That would be a potential risk.

And you should be able to see this. And when something like that happens as a risk, we then put it back into the risk register. So lots of these documents tie up together.

Mobilization plan, the ISO asked for mobilization plan, which is, again, a very useful idea. How many times in the past have we all thought everyone under understands the exchange methods, these are really clear, only for issues to happen on project deadlines? So essentially, this mobilization plan allows us to test technology-- the tools, security access, CDE, and the project exchange information protocol.

So this is an extract from a working mobilization plan where we're asking for confirmation from the delivery team that things have been tested and that they work. So yes, yes, yes, green means off we go. It's great. But any findings during mobilization that add risk to the project would again be entered back into that risk register that we can all discuss and work out a resolution for.

This is the last one from me. The common data environment, they're super important. This is how we exchange all of our information in one particular place.

So a CDE, this consists of two distinct entities that when combined form the basis for managing information. Those two entities are a CDE solution, i.e. a digital system which supports the workflow processes in the exchange of information, and then the CDE workflow itself, so varying states at which information can be generated, stored, relied upon through project delivery, i.e. WIP, shared, published, and archive. These are all gateways.

Now also, we'd expect to see metadata typically added to the information to show what information can be relied upon. And we have to draw a very strong view that all project information must be shared through the CDE. No we transfers. No email. It all must go through this way in a very controlled manner.

ZUZANNA CZAPLA: OK, so now, we need-- now, we know everything about the client and the lead appointed party, but let's talk about getting started when you are actually a design team. So at the very beginning, you will get a lot of reading, all of those documents that Dave just mentioned. And you need to have someone in your organization that will go through all those documents and have a good understanding of deliverables that we normally submit. That's why I think project manager and information management responsible is the match made in heaven. They both read through the project documentation and are able to plan against the resources and technology that we have available in our organization.

So what docs do we need to go over in the beginning? There is this task team assessment. Don't be afraid of it. The successful teams might not be the ones that have the most experience, but the ones that are committed to ensure that they can meet the requirements. It also gives the lead appointed party an idea how much in terms of training they need to do.

On top of the task team assessment, we also get the precontract BIM Execution Plan. And it's important to review it, comment on it, discuss it with the lead appointed party, and address any issues that you might see in it. Personally, I also recommend to read it along the EIR to just make sure that the BIM Execution Plan fulfills all the requirements that the client is asking for.

So the reason why I recommend this is because I was working on the projects when the lead appointed party had sent us a template BIM Execution Plan that was essentially a little bit empty and didn't really reflect the majority of the client requirements. So we didn't actually know what we were signing up for. Now when you receive the BIM Execution Plan from the lead appointed party, it should give you a high level of understanding of what, who, how, where, and when.

And a good one in my opinion goes from very general to more granular. And if you don't have much experience with it and you don't know if it is of the appropriate quality, I recommend to ask yourself a question as what project team would ask you. So for instance, let's take the BIM deliverables. This section generally should inform you what are you producing, and most importantly, what is the purpose of what you're producing.

So the team might ask you, why do we need to have materials defined in schematic design? And that's because we agreed to run a life cycle assessment on every design stage. And this is important from the project planning perspective. If there are any deliverables that vary from our usual package, we will have to spend more resources on it.

So when it comes to the project team, this is a setup that we are all kind of used to if we are working in the design offices. We have the lead for the project, then the project architect, technical lead, project manager, and a bunch of designers working with them. On the ISO projects, the truth is that not much of it changes. This is how we structure our project teams that work towards the ISO.

So I usually perform the role of the information manager. And I'm mostly present in the early phases of the project. And I try to collaborate a lot with the lead appointed party just to understand the requirements for the project. Internally, on the other side, I work with the project manager to make sure that all the BIM digital deliverable activities match with the design activities that they had planned.

We also have someone who is a designer that takes a bit of the BIM responsibilities. And we really want this person to be immersed into the project just to understand the project well. So they collaborate with the model coordinators and are also in the close contact with the document controllers just to make sure that we submit our drawings and documents in the correct way.

So in terms of technology, we have those four focus areas. And I just want to give you some tips in relation to them. CDE, when we get into the project, we often get offered a CDE training that is just a guide to the digital platform. This is useful. But I can also call some kind of Autodesk supporters, consultants, and they will tell me kind of the same thing.

But the biggest challenge is the understanding of process of how the information is going to be shared in the certain context of the project. So this is really important thing to understand this. Because when you get to the milestone, you need to know where to upload your files.

And when it comes to the information production software, in general, there should be a freedom of choosing the design software. Just keep in mind the interoperability, because you don't want to waste a lot of time trying to consume the models that your collaborators are producing. When it comes to the coordination, in my experience, issues get resolved much faster if the designers are given the chance to also participate in the coordination. And resolve issues more on the fly basis, for instance, through the model coordination module instead of going through a super long issue reports that are produced every month.

Then there is also the fourth pillar, which is hidden requirements. And this is the task that are resource consuming, but can't really be seen at the first glance. So for example, it could be requirements to exchange IFC files weekly. If we all work on the collaborative platform, where we link our models together, it's just a waste of time to do it.

What is also worth mentioning is that lead appointed party is not obliged to give us any kind of training in producing the deliverables. However, we all care to produce the information that is meaningful for the project. So my good tip is just to be in the dialogue with the lead appointed party and get a step closer to actually finding a good solution for your project.

What do we need to do, produce in top of delivery material when it comes to the ISO project? This is this drawing list on steroids, TIDP. This is what it's our responsibility to produce.

So basically, we capture in this document all the deliverables that we are producing, then QA material for majority of the companies. It's kind of a standard that you have to have some kind of quality assurance of the drawings, documents, and models that you're doing. But this is also something that the client might ask for.

And then the third one is risk register. So we don't need to do anything about it. We don't have to produce it. But it's really nice to know where it is and feed into it when needed. So an example situation of when it becomes useful is, for instance, if we are working on the transformation project, we're working for a few months, and we still didn't receive a detailed survey of the existing conditions.

Then we can just-- if nobody responds to us, nobody wants to give us the survey, we can just put it into the risk register and say, OK, we didn't receive it. If we continue working, the quality of our work and its [INAUDIBLE] is at risk. Do you want us to continue? So this is really useful document to keep in mind.

Now, moving on to the accreditation. How can we prove that we can actually do ISO? So there are two different accreditations. There is a personal and the business one. Let's focus on the personal first.

So depending on the company that is providing the certification, it might be several levels, courses, and exams. But generally, the first level is the information practitioner. It's not the formal certification. But I would say it's useful for people that work with a project that should comply with the standard, but it's just the basics.

Then there is the BIM project information professional. It might require a professional training. It's ideal for people that have higher level of responsibility, for instance, the document controllers. And then the final one, final boss is the BIM certified professional and is a formal recognition it requires us to go through this entire process and pass an assessment demonstrating the experience from the projects. And this is appropriate for leadership positions if we want to be, for instance, the information manager.

Now, the accreditation for business starts with submitting the application, then the auditor goes through the ISO-related templates that we have within the company. They file a report, and we have a chance to answer to it. We actually have to do this before we can move on to the next step, which is on-site assessment. On-site assessment is where auditor checks the information management process on a percentage of value of ISO projects that your organization have been involved with.

And this person also-- the cycle continues again. There is a report. And we have to address the issues. Once we get the certification, it has to be renewed annually, so we just make sure that we keep the same quality of the projects that we are executing.

And on top of all the benefits, accreditation basically brings us closer to winning projects and also allows our company to prequalify for some. So just a shortcut to win some of the projects. And now, Dave will talk more about our accreditation process.

DAVID SEWELL: Hey, thanks, Zuza. That's great. So very, very briefly then, so while we were being accredited for lead appointed party and the accreditors leave the way you present very, very open. It's kind of do what you want, right?

So we decided to split our assessment into two distinct parts. And we agreed this with the assessor during the introduction of day one. So part one day one was going to be all about process, and then part two day two would be all about proving that process by using live projects.

So I'm just going to talk to you about part one process. And what we decided to do was map out all of the clauses from the ISO. And we organized it under these purple buckets you can see on the screen here. These are the main sections from the ISO. We then drilled down through each bucket identifying how we used the process to meet each clause.

And the assessor really liked this approach. It's very graphical rather than super wordy. So you can see there we've got the buckets here. We've got all the clauses in the blue, the green, the oranges. And the actual colors refer to who was the responsible party.

So just to close off, the next slide is a quick example of bucket 5.6, the collaborative production of information bucket. So you can see here, on the left hand side, we're going from gray to blue, compile MIDP, generate information, and the slide itself explained how we went about that, so more generating information, spatial coordination, how do we go about that.

More on raising issues during coordination. Have we done our quality assurance checks and that kind of thing. And then finally, what was our review and approved process as well? So that's how we went about explaining.

So with that, we'd just like to say a big thank you for sticking with us. And we're happy to take any questions from the floor. Thanks very much.