Subscribe
Share
Share
Embed
Reimagining AEC is Dr Sepehr Abrishami's independent podcast on how the built environment handles information. Each episode takes one subject from digital construction, from the ISO 19650 series and the common data environment to the golden thread, soft landings and the arrival of artificial intelligence in design and surveying practice, and tells it as a single argument built on the published standards, guidance and evidence. Sepehr is a researcher and former architect who leads the Centre for AI in Construction and teaches building information modelling at master's level. The episodes are written for postgraduate students and practitioners who want the reasoning behind the rules, not a summary of them.
In information management, a model delivered at a milestone is either accepted or sent back. I present Reimagining AEC under my own name, Dr Sepehr Abrishami, and on the journal editorial boards I serve, submitted papers face a similar choice. This episode follows that choice, and the roles behind it, through ISO 19650-2, the standard for delivering information on projects using building information modelling, or BIM.
Here is a decision that lands on a client's desk at an information delivery milestone. I have put the case together for this episode, so the project and its details are invented, although the chain of appointments behind it comes from the UK guidance. A client has appointed a design and build contractor, and the contractor has appointed a steelwork sub-contractor. At the milestone, the steel frame model arrives for the client's acceptance. Most of it is complete. The connection information for the top two floors is missing. Meanwhile a fit-out designer, appointed directly by the client and leading a team of its own, is waiting to use the steel frame as the reference for its ceiling and services layouts. The contractor proposes a compromise. The client could accept the complete floors now and take the rest at the next milestone. That keeps the fit-out designer working, while rejecting the whole model would cost time on every floor. The client has to choose, and somebody then has to complete the missing connections, and it is not obvious who.
The UK guidance on ISO 19650-2 gives that decision a clear answer, and I will come to it near the end. First comes a wider question, which this episode is built around. For any piece of information on a project, the question is who produces and checks it, who authorises it and who accepts it, and how your own appointment decides which of those jobs is yours. By the end you should be able to place yourself on any project as one of three parties, say which of the eight activities in clause five of ISO 19650-2 you lead and how far you take part in the rest, and follow an information model through authorisation and acceptance at a milestone. My main source is the UK guidance on parties, teams and processes for the delivery phase, edited by David Churcher, Sarah Davidson and Anne Kemp and published in 2020 under the UK BIM Framework. nima, formerly the UK BIM Alliance, has since extended that framework under a new name, the IMI Framework, after the Information Management Initiative.
We will move in five steps. First come the parties and the teams, and the way procurement reshapes them. Then the process as a whole, and how involvement shifts between the parties. Then the three activities that happen before anyone is appointed, then appointment and mobilisation, and finally production, delivery and close-out, where the client's decision gets its answer. The steelwork sub-contractor comes with us the whole way.
Start with the vocabulary, because almost every later activity is defined by which party performs it. ISO 19650 names three parties, and each one is defined by an appointment. The appointing party is the client, or whoever manages information on the client's behalf. A lead appointed party is appointed directly by the client, and its defining duty is to coordinate information between its own delivery team and the client. An appointed party is appointed by a lead appointed party, and it is the party that provides the information. In our project, the client is the appointing party, the design and build contractor is the lead appointed party for construction, and the steelwork sub-contractor is an appointed party. None of these labels names a profession. An architecture practice can be a lead appointed party on one project and an appointed party on the next. The guidance also stresses that design and non-design appointments follow the same ISO 19650-2 processes.
The parties group into three teams, and the teams nest inside one another, from the widest to the narrowest. The project team is the widest. It is the appointing party together with every delivery team on the project. A delivery team forms around each lead appointed party, with the appointed parties it has engaged. Wherever there is a lead appointed party there is a delivery team, even if that team is a single organisation, so most projects have several delivery teams whatever their procurement route. The narrowest is the task team, a person or group of people performing a specific task. Here the standard is flexible. A task team may be one appointed party, one appointed party may hold several task teams, or one task team may span several appointed parties. Our steelwork sub-contractor is a task team inside the contractor's delivery team. The fit-out designer leads a different delivery team, and both sit inside the one project team. That is why information has to be coordinated across delivery teams as well as within them.
The parties keep their names whatever the contract, but the procurement route decides how many lead appointed parties there are. Under a traditional route the client appoints each consultant, the contractor and any specialists directly, so there are many lead appointed parties. A pure design and build route could have just one, for design and construction together. The guidance points out that the more common case sits in between, and it traces that case in three moves, which our project follows. In early design, the client appoints an architect directly, and the architect is the lead appointed party for architecture. Next, the client appoints the design and build contractor as lead appointed party for construction. Then the architect's appointment is novated to the contractor. From that point the architect is an appointed party inside the contractor's delivery team, and the lead appointed party function for architecture ceases. The practice is the same firm, yet its duties under ISO 19650-2 have changed. So before you plan any information work, confirm which role your appointment gives you at that point in the project.
Each appointment also carries a set of information management resources, and the useful question is who prepares each one. The answer splits in two. Three resources are set once for the whole project. They are the information standard, the information production methods and procedures, and the information protocol. The appointing party prepares all three, and they flow into every appointment on the project, with any agreed amendments. The other resources change with the appointment, and here the contractor sits on both sides. In its own appointment, the contractor receives exchange information requirements, the EIR, written by the client. In the steelwork sub-contractor's appointment, the contractor writes the EIR itself, acting as lead appointed party. The BIM execution plan, or BEP, belongs to the delivery team, so the contractor prepares it in both appointments. The delivery plans follow the same split. The contractor's appointment includes the master information delivery plan, the MIDP, and the sub-contractor's includes its own task information delivery plan, the TIDP. A lead appointed party that also produces information has a TIDP of its own as well. The guidance adds that preparing a resource includes delegating its preparation. That settles the first step. Your role comes from your appointment, and your appointment tells you which resources you write and which you receive.
With the people in place, the second step looks at the process as a whole. The edition in force is BS EN ISO 19650-2 of 2018, with its UK National Annex revised in 2021. Revised drafts of Parts 1 and 2 went out for public comment in the spring of 2026, as nima reported that March, but until a new edition is published this is the process that applies. Clause five sets out eight activities, and they sit at two levels. The first and the last happen once, for the project as a whole. Clause five point one, assessment and need, opens the project, and clause five point eight, project close-out, ends it. The six activities in between happen at appointment level, and they repeat for every piece of work the client tenders, whether for a consultant, a contractor or a specialist. The guidance groups those six into three pairs. Procurement pairs the invitation to tender with the tender response. Planning pairs appointment with mobilisation. Production pairs the collaborative production of information with information model delivery. Production also loops inside each appointment, because model delivery repeats at every information delivery milestone. On a project with several lead appointed parties, several of these middle cycles run in parallel or one after another. In our project, one cycle runs for the architect's direct appointment, another for the contractor and another for the fit-out designer. That loop is why the process is better understood as a cycle than as a straight line.
The guidance also rates how involved each party is in each activity, on a scale from nil to high, and the ratings carry two findings. Leadership passes from the client to the lead appointed party once tenders are issued, and the heaviest production load sits with the task teams. The contrast between the three parties shows both. The client is high at the start, while it sets up the project and prepares tenders, and high again at close-out. In between it drops to low or medium, rising when it reviews and accepts information at model delivery. The lead appointed party has no part in the set-up, and from the tender response onwards it is high, easing only to medium at close-out. The appointed party is high only when information is produced and delivered, which in our project means the steelwork sub-contractor.
The third step takes the activities in order, starting before anyone is appointed. Here the appointing party builds the project's information framework and prepares each tender, and this is where weak information management is easiest to prevent. Assessment and need has eight sub-clauses, and all of them should be complete before the first lead appointed party is tendered. They come down to two jobs. The first is settling people, requirements and timing. The client appoints individuals to undertake the information management function, and the guidance advises keeping them separate from any lead appointed party's own information management function. The client sets its project information requirements, meaning the information it needs at its key decision points, and it sets the information delivery milestones. The guidance suggests placing milestones within or at the end of project stages, and on a UK building project those could be the stages of the Royal Institute of British Architects, or RIBA, Plan of Work 2020. The second job is setting the rules and the infrastructure. The rules are the information standard, the production methods and procedures and the information protocol. The infrastructure is the reference information and the common data environment, or CDE. The CDE has to be working before any tender information is shared, so the guidance says it is not practical to delegate it to a prospective lead appointed party, although hosting can pass to a lead appointed party after appointment once the CDE is working. Requirements and the CDE each have an episode of their own, so here we note only who owns them.
One of those sub-clauses, five point one point six, carries a commercial argument. Reference information is anything the client already holds that a tenderer will need, such as Ordnance Survey mapping, information about adjacent assets and utilities, or selected information from the existing asset information model. Shared resources include document templates, object libraries and line styles. The guidance gives one practical case, a client-provided BIM execution plan template, so that every tender response is structured the same way and can be evaluated consistently. Then it states the cost of withholding this material. In its words, not providing reference information means that prospective lead appointed parties are likely to either include costs to generate it themselves, or include a risk allowance in their pricing, or both. A tenderer may also proceed on incomplete information and deliver a weaker product through no fault of its own. Those are the avoidable costs that information management under ISO 19650 is meant to remove. In our project, it would mean the contractor finds the client's mapping and object library in the CDE on the day the tender arrives, and has no reason to price for creating them.
With the framework in place, the client invites tenders. The invitation to tender is still led by the appointing party, but it now works at appointment level, so it repeats for every lead appointed party the client procures, the architect, the contractor and the fit-out designer alike. The client first establishes its exchange information requirements, its EIR, for this appointment. Each EIR is derived from the project information requirements and the asset information requirements, broken down to this lead appointed party's scope. It carries a level of information need for each requirement and exchange dates tied to the delivery milestones. The method for specifying the level of information need now sits in ISO 7817-1 of 2024, which the episode on information requirements covers. Second, the client places reference information and shared resources in the CDE and controls tenderers' access, so that each sees only what it should, and it revokes access for unsuccessful tenderers. Third, the client sets the minimum requirements for the tender response and decides how it will evaluate them. Fourth, it compiles all of this into the tender package, alongside the technical specifications for the works. The episode on tendering and appointments takes evaluation further. At this point the work passes to the tenderer.
The tender response is the first activity led by the prospective lead appointed party, our contractor, with the prospective task teams contributing. Its sub-clauses answer three things the client needs to know about any tenderer: who will manage the information, whether the team can deliver it, and how the team will get ready. On the first, the contractor nominates the people who will undertake its information management function. If the same organisation already performs part of the client's information management function, different individuals should do the work, to avoid a conflict of interest. It then develops the pre-appointment BIM execution plan with the team members it already knows, so that the plan reflects what the whole delivery team will do. On capability, each task team, including our steelwork sub-contractor, assesses its capability and capacity to manage information and to produce it, and the availability of information technology. The contractor then establishes the capability and capacity of the delivery team as a whole. On readiness, the contractor sets out a mobilisation plan and a risk register for information delivery. The guidance recommends one integrated register that holds information management risks alongside the team's other appointment risks. Everything is then compiled into one tender response, which the client evaluates before it selects a lead appointed party. So, before anyone is appointed, the client sets the framework and the tenderer shows that it can work within it.
Our contractor has won, and the fourth step follows it into appointment and mobilisation. This is where proposals become contractual commitments and the delivery team is made ready to produce information. The contractor leads both activities, apart from two steps inside appointment. Appointment converts the tender into binding documents, in a clear order. The contractor first confirms the BEP with each appointed party. The guidance notes a change of language at this point. The pre-appointment clause lists matters to consider, while this clause lists what the lead appointed party shall do. Because the BEP is now an appointment document, later changes go through formal change control, and the guidance recommends keeping it simple and concise. Next, the high-level responsibility matrix from the tender becomes a detailed one, stating what information is produced, when it is exchanged and which task team produces it. The contractor then writes its own EIR for each appointed party, the steelwork sub-contractor included. Each task team, and not the contractor, establishes its own task information delivery plan, its TIDP, and only then does the contractor compile those plans into the master information delivery plan, the MIDP. Finally, the client completes the contractor's appointment documents, and the contractor then completes the documents for each of its appointed parties.
The requirements behind those documents travel down the supply chain as a cascade, and it helps to follow it from the top. At the top are the client's own needs, its project information requirements and asset information requirements. The client breaks these down into an EIR for each lead appointed party, scoped to that appointment and expressed against a level of information need. One layer down, the lead appointed party writes an EIR for each of its appointed parties, carrying the relevant client requirements and adding its own needs. The guidance gives an example. A tier one contractor manages programme and cost, so it may need specific information from certain sub-contractors for its own purposes. If the client also needs asset information for maintenance that only certain sub-contractors can supply, that requirement passes down in the same EIR. From the steelwork sub-contractor's side, the guidance says it does not matter which requirements originate with whom, because all of them must be addressed in its TIDP. At the bottom, the contractor collates every TIDP into the MIDP and checks that the sequence of deliverables works. The episode on information delivery planning takes those plans further.
Mobilisation is about readiness, and it follows a documented process, the mobilisation plan submitted with the tender. Readiness has three dimensions: people, technology and method. For people, the contractor confirms that every individual named in the TIDPs is available, including the less visible staff who administer systems such as the CDE. Anyone who has left is replaced by someone with equivalent or better skills. Education then builds knowledge of the information management resources and obligations, and training builds competence. For technology, software, hardware and infrastructure are procured, configured and tested, the project CDE is tested with the client's cooperation, and information exchanges and deliveries are trialled. For method, the production methods and procedures are tested, for example the federation strategy and the information container breakdown structure, refined where needed and then cascaded to every task team. Any risks found go into the risk register, and mobilisation repeats whenever new members join. That is where the fourth step resolves. By the time the steelwork sub-contractor starts modelling, its people, its systems and its methods have been tested, and its obligations are written into a contract.
The final step covers production, delivery and close-out, and it is where the client's decision is settled. Collaborative production is led by the task teams, so follow the steelwork sub-contractor through it. Before modelling starts, it checks that the reference information and shared resources it needs are in the CDE, and reports any shortfall to the contractor straight away. It then generates information as its TIDP sets out, following the information standard and the production methods and procedures. Clause five point six point two also says what not to produce. Information that exceeds the level of information need, or duplicates another task team's work, is waste. The guidance's example is an architectural task team referencing the structural engineer's information containers rather than recreating structural elements in its own models. In our project, the same logic means the sub-contractor references the novated architect's containers and does not remodel the building envelope.
Next come two checks that are often blurred, and the guidance keeps them apart. The first is the quality assurance check, which the guidance describes as an outside check of the container. The task team confirms that the information container carries the correct unique identifier, status, revision and classification, as the information standard requires, and that it was produced following the production methods and procedures. Some of these checks can be automated in the CDE workflow, and the activity may be aligned with an ISO 9001 quality management system where that has been agreed. A container that fails goes back to its author. Only once the container passes does the second check begin, the review of its contents. Here the team checks that the information inside meets the lead appointed party's EIR and its own TIDP. If it does, the container is approved and given a status code suitable for sharing, using the codes in the UK National Annex. If it fails, the reasons and the amendments needed are recorded. Shared information feeds the next round of work, and finally the team reviews the delivery team's information model as a whole, as often as needed, until it is ready for authorisation. How containers move between states is covered in the episode on the common data environment.
Then the milestone arrives, and the information model passes through four steps, two submissions each followed by a review. First, each task team submits its information containers to the lead appointed party for authorisation, following the production methods and procedures. Second, the lead appointed party reviews the model. It checks that the model addresses both sets of exchange information requirements, the client's and its own, that it contains the deliverables listed in the MIDP, that it meets the acceptance criteria and that it meets the level of information need. If it passes, the model is authorised. Third, the task teams submit the authorised model through the project's CDE for the appointing party's acceptance. Fourth, the appointing party reviews it against its EIR, the MIDP dates and the level of information need, and checks that it was delivered by the agreed procedures, including security procedures. Acceptance moves the information into the published state. That gives the wider question its answer for our chain. The steelwork sub-contractor checks and submits, the contractor authorises, and the client accepts.
Return now to the client with its steel frame model and the missing connections. The guidance adds four rules that make the delivery sequence work in practice, and the first one settles the decision. Partial acceptance should be avoided, by the lead appointed party and by the client alike. The guidance's reason matches the fit-out designer's position exactly. If an incomplete model were accepted and then used as reference information by another delivery team, that team would be relying on unreliable information, and disputes would follow. So the client rejects the model as a whole. Strictly, the contractor should never have authorised it, because the rule binds the lead appointed party too. The second rule says who does the work. ISO 19650-2 says the client instructs the lead appointed party to amend and resubmit, and the guidance explains that the relevant appointed party carries out the amendment under the lead appointed party's direction. The client instructs the contractor, and the contractor directs the steelwork sub-contractor to complete the connections. The third rule is that not every exchange goes to the client. An exchange purely within a delivery team is complete once the lead appointed party has authorised it. The fourth rule is that accepted information is published and becomes reference information for other delivery teams, which may trigger a new appointment process. Once the corrected model is accepted, the fit-out designer can rely on it. That fourth rule is why the process works as a cycle.
The last activity, project close-out, returns the lead to the appointing party, and it has two parts. The first is archiving. Individual containers move to the archive throughout production, but close-out archives the whole project information model, so that a definitive final version exists if the client needs it after completion. The second is lessons learned. The lead appointed party contributes alongside the client, which is why its involvement at close-out is rated medium. The guidance recommends capturing lessons throughout the project and each appointment rather than only at the end, and writing the obligation to take part into each appointment. Typical criteria include whether the information management process delivered its required outcomes, whether budget and programme were met, and whether the operational asset performs as designed. The 2020 guidance links this to soft landings in the BS 8536 series. The current code is BS 8536 of 2022, which superseded the earlier two-part standard. The missing connections at our milestone are the kind of failure worth recording as a lesson while the people involved can still explain it. The episodes on Government Soft Landings and on information management in the operational phase pick up from here.
That brings the argument together. The question was who produces and checks information, who authorises it and who accepts it, and how your appointment decides which of those jobs is yours. The answer follows the chain of appointments from the bottom up. The steelwork sub-contractor, as appointed party and task team, produces and checks. The contractor, as lead appointed party, authorises. The client, as appointing party, accepts, and it accepts whole models only. Which job falls to you depends on the appointment you hold at that moment, whatever your profession, as the novated architect showed.
Three points are worth carrying into your own work. Read your appointment and name your role in it before you plan any information work, because the same firm can hold different roles on one project as procurement moves on. Keep the two levels of the process apart. Assessment and need, and close-out, happen once, while everything from the invitation to tender to model delivery repeats for each appointment, so a project with several lead appointed parties runs several cycles at once. And put the effort in early, because the client's work before tender on requirements, reference information and the CDE is what lets every later step run, and withholding it only moves the cost into tender prices. For reading, take the 2020 guidance on parties, teams and processes, free from the IMI Framework website, and read its clause by clause analysis alongside your own copy of ISO 19650-2. The episode on the information management function takes the people behind this process further.
If a part-finished model ever reaches you for acceptance, in practice or in a research case, the guidance's reasoning against partial acceptance is worth having to hand. Dr Sepehr Abrishami is my name, and if Reimagining AEC kept one passage of that guidance, it would be this one.